diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-abnormally-large-dns-response.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-abnormally-large-dns-response.asciidoc new file mode 100644 index 0000000000..97829f86ac --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-abnormally-large-dns-response.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-25-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* + +*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: PAN-OS +* Data Source: Network Traffic + +*Version*: 111 + +*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 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. + + +*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)) + 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 +) + +---------------------------------- + +*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-25/prebuilt-rule-8-19-25-accepted-default-telnet-port-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-accepted-default-telnet-port-connection.asciidoc new file mode 100644 index 0000000000..31981a7119 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-accepted-default-telnet-port-connection.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-25-accepted-default-telnet-port-connection]] +=== Accepted Default Telnet Port Connection + +This rule detects network events that may indicate the use of Telnet traffic. Telnet is commonly used by system administrators to remotely control older or embedded systems using the command line shell. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. As a plain-text protocol, it may also expose usernames and passwords to anyone capable of observing the traffic. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.panos* +* logs-fortinet_fortigate.log-* +* logs-sonicwall_firewall.log-* +* logs-suricata.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Lateral Movement +* Tactic: Initial Access +* Data Source: PAN-OS +* Data Source: Fortinet +* Data Source: SonicWall +* Data Source: Suricata +* Resources: Investigation Guide + +*Version*: 114 + +*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 sonicwall_firewall.log or suricata.eve or panw.panos) + or event.category:(network or network_traffic)) + and event.type:(connection and not end) + and not event.action:(flow_dropped or flow_denied or denied or deny or + flow_terminated or timeout or Reject or network_flow or connection-denied or + connection-end or server-rst or client-rst) + and not (event.action:netflow_flow and not network.packets > 1) + and not network.application:(traceroute or stretchoid-scanning) + 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-25/prebuilt-rule-8-19-25-attempt-to-clear-kernel-ring-buffer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-attempt-to-clear-kernel-ring-buffer.asciidoc new file mode 100644 index 0000000000..aa2ecb9c47 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-attempt-to-clear-kernel-ring-buffer.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-25-attempt-to-clear-kernel-ring-buffer]] +=== Attempt to Clear Kernel Ring Buffer + +Monitors for the deletion of the kernel ring buffer events through dmesg. Attackers may clear kernel ring buffer events to evade detection after installing a Linux kernel module (LKM). This activity is commonly observed by intrusions that leverage kernel-level rootkits to maintain persistence on a compromised host. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*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 +* 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 + +*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 Attempt to Clear Kernel Ring Buffer* + + +The kernel ring buffer logs system messages, crucial for diagnosing issues. Adversaries may clear these logs using the `dmesg -c` command to hide traces of malicious activities, such as installing unauthorized kernel modules. The detection rule identifies this behavior by monitoring the execution of `dmesg` with specific arguments, flagging potential evasion attempts for further investigation. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the `dmesg -c` command, focusing on the process name and arguments to ensure the alert is valid. +- Investigate the user account associated with the execution of the `dmesg -c` command to determine if it is a known and authorized user or potentially compromised. +- Check for any recent installations or modifications of Linux kernel modules (LKMs) on the host to identify unauthorized changes that may coincide with the log clearing attempt. +- Examine other system logs and security alerts around the same timeframe to identify any suspicious activities or patterns that may indicate a broader attack or compromise. +- Assess the host's network activity for any unusual outbound connections or data exfiltration attempts that could suggest further malicious intent. + + +*False positive analysis* + + +- Routine system maintenance activities may trigger the rule if administrators use the dmesg -c command to clear logs for legitimate purposes. To handle this, create exceptions for known maintenance scripts or processes that regularly execute this command. +- Automated scripts or monitoring tools that include dmesg -c as part of their log management routine can cause false positives. Identify these scripts and exclude them from the rule by specifying their process IDs or user accounts. +- Development and testing environments where kernel modules are frequently installed and removed might generate alerts. Consider excluding these environments from the rule or adjusting the risk score to reflect the lower threat level in these contexts. +- System administrators may use dmesg -c during troubleshooting to clear logs and view new messages. Document these activities and create exceptions for specific user accounts or roles that perform this task regularly. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Conduct a thorough review of the system to identify any unauthorized kernel modules or other suspicious changes, and remove them if found. +- Restore the system from a known good backup if unauthorized changes are detected and cannot be easily reversed. +- Review and update access controls and permissions to ensure that only authorized users have the ability to execute commands like `dmesg -c`. +- Implement enhanced monitoring and logging for the affected system to detect any future attempts to clear the kernel ring buffer or similar evasion tactics. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures to prevent recurrence. + +==== 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 == "dmesg" and process.args in ("-c", "-C", "--clear", "--read-clear") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Linux or Mac System Logs +** ID: T1070.002 +** Reference URL: https://attack.mitre.org/techniques/T1070/002/ +* 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-25/prebuilt-rule-8-19-25-aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc new file mode 100644 index 0000000000..e5c289e991 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-25-aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn]] +=== AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* 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/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html +* https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html + +*Tags*: + +* 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 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN* + + +IRSA maps a Kubernetes service account to an IAM role via OIDC. CloudTrail records `AssumeRoleWithWebIdentity` with +`user.name` like `system:serviceaccount::`. If geolocation/ASN enrichment shows a non-Amazon source +organization while the identity is still a cluster service account, validate whether the token could have been used +outside the cluster (exfiltrated JWT, misrouted traffic, or operator tooling). + + +*Possible investigation steps* + + +- Confirm `event.action`, `event.provider`, and `event.outcome` for a successful STS assume. +- Review `user.name`, `aws.cloudtrail.user_identity.arn`, role trust (`aws.cloudtrail.resources`, request parameters for + `roleArn` / `roleSessionName`), and OIDC `sub` / `aud` if present in CloudTrail. +- Compare `source.ip`, `source.geo.*`, and `source.as.organization.name` to known cluster egress, NAT gateways, and + approved operator networks. +- In Kubernetes: map the service account to workloads and audit activity around the event time (exec, secret access, + new deployments). + + +*False positive analysis* + + +- Egress through third-party security stacks or multi-cloud connectors can change how ASN organization is attributed. +- Expand exclusions for known `source.as.organization.name` values used by your egress path. + + +*Response and remediation* + + +- If unauthorized: revoke the role session, rotate IRSA trust where appropriate, investigate token exposure, and reduce + service account and role permissions. + + +*Additional information* + + +- https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html[AssumeRoleWithWebIdentity] +- https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html[EKS IAM roles for service accounts] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and + event.provider:sts.amazonaws.com and + event.action:AssumeRoleWithWebIdentity and + event.outcome:success and user.name:(system\:serviceaccount\:* and not system\:serviceaccount\:kube-system\:aws-load-balancer-controller) and + source.as.organization.name:(* and not (Amazon* or AMAZON*)) + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-aws-s3-credential-file-retrieved-from-bucket.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-aws-s3-credential-file-retrieved-from-bucket.asciidoc new file mode 100644 index 0000000000..f8412c5296 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-aws-s3-credential-file-retrieved-from-bucket.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-25-aws-s3-credential-file-retrieved-from-bucket]] +=== AWS S3 Credential File Retrieved from Bucket + +Detects successful S3 GetObject calls targeting high-value credential and secret files commonly stored in S3 buckets: AWS credentials files (".aws/credentials", ".aws/config"), SSH private keys ("id_rsa", "id_ed25519", "id_ecdsa", "id_dsa"), environment files (".env"), PEM and PuTTY key files, and other private key patterns. These file types are high-yield targets for credential harvesting from S3. The rule excludes AWSService identity type to suppress S3 replication, Glacier restore, and other AWS-internal data movement that legitimately reads these files. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* 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/AmazonS3/latest/API/API_GetObject.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Credential File Retrieved from Bucket* + + +S3 is frequently used to store configuration files, scripts, and secrets. When files with credential-like +names are accessed, it warrants investigation to ensure that the retrieval was authorized. + + +*Possible investigation steps* + + +- **Identify the accessed file**: Review `aws.cloudtrail.request_parameters` for the bucket name and key. + Determine whether the bucket is intended to store secrets. +- **Verify the caller**: Inspect `aws.cloudtrail.user_identity.arn` and `source.ip`. If the caller is not + an approved automation role, escalate immediately. +- **Check bucket permissions**: Determine if the bucket is publicly accessible or if the key naming + pattern was intentionally exposed. +- **Look for downstream actions**: Search for subsequent IAM, STS, or console actions from the same + identity shortly after the object retrieval, which may indicate successful credential use. + + +*False positive analysis* + + +- Legitimate backup or restore processes may access credential files stored in S3 as part of their + workflow. Validate the calling identity and user agent against known automation accounts. +- CI/CD pipelines that retrieve secrets from S3 during deployment may trigger this rule. Verify the + source IP and ARN match expected automation infrastructure. + + +*Response and remediation* + + +- Immediately disable the access key identified in `aws.cloudtrail.user_identity.access_key_id` if + the retrieval is determined to be unauthorized. +- Audit the S3 bucket for overly permissive policies or public access configurations. +- Rotate any credentials stored in the accessed object — treat them as compromised. +- Review all CloudTrail events from the same identity in the preceding 30 minutes for signs of + lateral movement, IAM changes, or resource creation. +- Implement S3 bucket policies or IAM conditions restricting access to credential files to only + authorized identities and source IPs. + + +==== Setup + + +S3 data event logging is required for this rule. This rule detects S3 GetObject events, +which are data plane events not logged by default. To enable: CloudTrail console → Trails → +[trail name] → Data events → Add S3 → select the buckets to monitor (or all buckets with a wildcard). +Without this configuration, the rule produces no alerts. + +Refer to the AWS documentation on +https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html[logging data events] +for detailed steps. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "s3.amazonaws.com" and + event.action: "GetObject" and + event.outcome: "success" and + aws.cloudtrail.flattened.request_parameters.key: ( + */.aws/credentials or + */.aws/config or + */id_rsa or + */id_ed25519 or + */id_ecdsa or + */id_dsa or + */.env or + */.env.* or + *.ppk or + *.pem or + *.key or + *private_key* or + */.ssh/authorized_keys + ) and + not aws.cloudtrail.user_identity.type: "AWSService" + +---------------------------------- + +*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: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* 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-25/prebuilt-rule-8-19-25-aws-ssm-session-manager-child-process-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-aws-ssm-session-manager-child-process-execution.asciidoc new file mode 100644 index 0000000000..0ac40a805f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-aws-ssm-session-manager-child-process-execution.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-25-aws-ssm-session-manager-child-process-execution]] +=== AWS SSM Session Manager Child Process Execution + +Identifies process start events where the parent process is the AWS Systems Manager (SSM) Session Manager worker. Session Manager provides interactive shell access to EC2 instances and hybrid nodes without bastion hosts or open inbound ports. Adversaries abuse it for remote execution and lateral movement using legitimate AWS credentials and IAM permissions. This rule surfaces endpoint execution occurring under that worker for visibility and hunting. Expect noise from authorized administrative sessions. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.events.process* +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* 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://www.mitiga.io/blog/abusing-the-amazon-web-services-ssm-agent-as-a-remote-access-trojan +* https://hackingthe.cloud/aws/post_exploitation/run_shell_commands_on_ec2/ +* https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SSM Session Manager Child Process Execution* + + +AWS Systems Manager Session Manager starts a session worker process on the endpoint; commands and shells you run in the +session appear as child processes of that worker. The same mechanism is used for authorized administration and for +adversary activity when IAM credentials or instance roles allow `ssm:StartSession` (or related) abuse. + + +*Possible investigation steps* + + +- Confirm whether the host is an EC2 instance or managed node that legitimately uses Session Manager. +- Review `process.command_line`, `process.executable`, `process.user.name`, and `user.name` for the child process to + judge intent (reconnaissance, download, credential access, persistence, etc.). +- Correlate timing with AWS CloudTrail for `StartSession`, `ResumeSession`, or related SSM API calls and the IAM + principal that initiated the session. +- Pivot on the same `host.id` or instance identifier for other alerts or SSM activity in the same window. + + +*False positive analysis* + + +- Routine interactive or automated administration via Session Manager is expected to match this rule by design. +- Prefer exclusions tied to stable attributes (approved IAM roles, automation service accounts, known script paths) + rather than broad process-name allowlists unless validated. + + +*Response and remediation* + + +- If activity is unauthorized: revoke or rotate exposed IAM credentials, review SSM and VPC endpoints policies, and + terminate suspicious sessions from the AWS console or API. +- Isolate the instance if compromise is suspected and perform endpoint forensics following your incident response + playbook. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category: "process" and event.action : ("exec" or "exec_event" or "start" or "ProcessRollup2" or "executed" or "process_started") and +( + process.parent.name:("ssm-session-worker.exe" or "ssm-session-worker" or "ssm-document-worker.exe" or "ssm-document-worker") or + (process.name : "powershell.exe" and process.args : *awsrunPowerShellScript*) or + (process.name : ("dash" or "sh" or "bash") and process.args : *awsrunShellScript*) or + (process.parent.name : "powershell.exe" and process.parent.args : *awsrunPowerShellScript*) or + (process.parent.name : ("dash" or "sh" or "bash") and process.parent.args : *awsrunShellScript*) + ) and + not (process.name : "powershell.exe" and process.args :("$str.Substring($str.length" or *Convert-GuidToCompressedGuid* or get-wmiobject* or $wmi_proc* or *win32_quickfixengineering* or Get-wmiobject* or *Get-Service* or *Get-WmiObject* or *System32\\ntoskrnl.exe* or *GET-WMIOBJECT*)) and + not process.executable : ("/usr/bin/lscpu" or "/usr/bin/snap" or "/usr/bin/rpm" or "/usr/bin/dpkg-query" or /snap/snapd/*/usr/bin/snap or "/usr/bin/id" or "C:\\Program Files\\Amazon\\SSM\\Plugins\\SessionManagerShell\\winpty-agent.exe" or /var/lib/amazon/ssm/update/amazon-ssm-agent-updater/*/updater or C\:\\ProgramData\\Amazon\\SSM\\Update\\amazon-ssm-agent-updater\\*\\updater.exe) and + not (process.name : (dash or bash or sh or _script.sh) and process.args : /var/lib/amazon/ssm/*/document/orchestration/*/_script.sh) and + process.command_line :(* and not (*ssm-user or */invokeInspectorSsmPluginLinux/_script.sh or */checkExclusionPreference/_script.sh or *\\createUpdateFolder\\_script.ps1 or */checkProvisioningEligibility/_script.sh or */install/_script.sh or */uninstall/_script.sh)) + +---------------------------------- + +*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/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* 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-25/prebuilt-rule-8-19-25-azure-run-command-correlated-with-process-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-azure-run-command-correlated-with-process-execution.asciidoc new file mode 100644 index 0000000000..5d8c2e6195 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-azure-run-command-correlated-with-process-execution.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-25-azure-run-command-correlated-with-process-execution]] +=== Azure Run Command Correlated with Process Execution + +Correlates successful Azure Virtual Machine Run Command operations with endpoint process execution on the same host within minutes. Adversaries abuse Run Command to run scripts remotely as SYSTEM or root while activity logs only record the control-plane action; Elastic Defend process telemetry reveals the on-guest payload. + +*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://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-contributor +* https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a +* https://adsecurity.org/?p=4277 + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* OS: Windows +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Azure +* Data Source: Microsoft Azure +* Data Source: Azure Activity Logs +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Run Command Correlated with Process Execution* + + +This ES|QL rule correlates Azure Activity Log `MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION` events with +endpoint process starts, joined on host name within a two-minute bucket and a 0–120 second delay between Run Command and process start. + +Pivot into raw `logs-azure.activitylogs-*` and `logs-endpoint.events.process-*` events for full command lines and +resource identifiers. + + +*Possible investigation steps* + + +- Review `user.email` and `azure.activitylogs.identity.authorization.evidence.principal_id` for who invoked Run Command. +- Inspect `Esql.process_command_line_values` for script paths and arguments beyond the matched pattern. +- Confirm `Esql.host_name` maps to the intended VM and whether Run Command timing aligns with change windows. +- Hunt for additional Run Command or PowerShell activity from the same principal or subscription. + + +*Response and remediation* + + +- If unauthorized, isolate the VM, revoke credentials used for Run Command, and review role assignments on the VM and + subscription. +- Collect endpoint artifacts and Azure activity logs for incident reporting. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-azure.activitylogs-*, logs-endpoint.events.process-* METADATA _id, _version, _index +| WHERE + ( + event.category == "process" AND KQL("event.action:start") + AND process.parent.name == "powershell.exe" + AND process.parent.command_line LIKE "powershell -ExecutionPolicy Unrestricted -File script?.ps1" + AND process.name != "conhost.exe" + ) OR + ( + KQL("event.category:process and event.action:exec and process.parent.name:(dash or bash or sh) and process.parent.args:/var/lib/waagent/run-command/download/*/script.sh") + ) OR + ( + event.module == "azure" + AND event.action == "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION" + AND NOT KQL("event.outcome:failure") + ) + +// Azure hostname comes as upper-case while Endpoint event comes as lowercase +| EVAL Esql.host_name = COALESCE( + TO_LOWER(host.name), + TO_LOWER(azure.resource.name) + ) +| EVAL ts_runcommand = CASE(event.module == "azure", @timestamp, null) +| EVAL ts_endpoint = CASE(event.category == "process", @timestamp, null) +| EVAL is_runcommand = CASE(event.module == "azure", 1, null) +| EVAL is_endpoint = CASE(event.category == "process", 1, null) +| EVAL Esql.time_bucket = DATE_TRUNC(2 minutes, @timestamp) +| STATS + runcommand_count = COUNT(is_runcommand), + endpoint_count = COUNT(is_endpoint), + user.email = VALUES(user.email), + azure.activitylogs.identity.authorization.evidence.principal_id = VALUES(azure.activitylogs.identity.authorization.evidence.principal_id), + azure.activitylogs.tenant_id = VALUES(azure.activitylogs.tenant_id), + azure.subscription_id = VALUES(azure.subscription_id), + source.ip = VALUES(source.ip), + source.geo.country_name = VALUES(source.geo.country_name), + source.as.number = VALUES(source.as.number), + Esql.process_command_line_values = VALUES(process.command_line), + first_runcommand = MIN(ts_runcommand), + first_ps_exec = MIN(ts_endpoint), + outcome = VALUES(event.outcome) + BY Esql.host_name, Esql.time_bucket +| WHERE runcommand_count >= 1 AND endpoint_count >= 1 +| EVAL delta_ms = TO_LONG(first_ps_exec) - TO_LONG(first_runcommand) +| EVAL delta_sec = delta_ms / 1000 +| WHERE delta_sec >= 0 AND delta_sec <= 120 +| KEEP + user.email, + azure.activitylogs.identity.authorization.evidence.principal_id, + source.ip, + source.as.number, + source.geo.country_name, + azure.activitylogs.tenant_id, + azure.subscription_id, + Esql.* + +---------------------------------- + +*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: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* 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-25/prebuilt-rule-8-19-25-azure-run-command-script-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-azure-run-command-script-child-process.asciidoc new file mode 100644 index 0000000000..6014b89338 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-azure-run-command-script-child-process.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-25-azure-run-command-script-child-process]] +=== Azure Run Command Script Child Process + +Identifies process start events whose parent matches Azure Virtual Machine Run Command execution patterns on Windows or Linux. On Windows, Run Command often launches PowerShell with `-ExecutionPolicy Unrestricted` and a `script?.ps1` file; on Linux, the Azure Linux Agent (waagent) runs downloaded script.sh under "/var/lib/waagent/run-command/". Child process telemetry exposes the on-guest payload that cloud activity logs do not fully describe. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-windows.sysmon_operational-* + +*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://docs.microsoft.com/en-us/azure/virtual-machines/run-command +* https://hackingthe.cloud/azure/run-command-abuse/ + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* OS: Linux +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Azure +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Run Command Script Child Process* + + +Azure VM Run Command executes scripts on guests without interactive RDP or SSH. On Windows, a parent PowerShell +process with `-ExecutionPolicy Unrestricted -File script?.ps1` often precedes child utilities; on Linux, `waagent` +invokes `/var/lib/waagent/run-command/download/*/script.sh` via `bash`, `sh`, or `dash`. + +Correlate with `logs-azure.activitylogs-*` for `MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION` when available. + + +*Possible investigation steps* + + +- Review `process.command_line`, `process.name`, and `process.parent.command_line` or `process.parent.args`. +- Confirm whether the host is an Azure VM and whether Run Command was expected for that asset. +- Pivot on `host.name` or `host.id` for other suspicious process or network activity in the same window. + + +*False positive analysis* + + +- Extension handlers, guest configuration, and patch orchestration may use the same parent patterns. +- Exclude known automation hosts or script paths after validating with platform teams. + + +*Response and remediation* + + +- If unauthorized, review Azure RBAC on the VM and subscription, revoke compromised credentials, and isolate the guest. +- Collect endpoint artifacts and Azure activity logs for incident reporting. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type in ("start", "process_started") and + ( + (process.parent.name == "powershell.exe" and + process.parent.command_line like "powershell -ExecutionPolicy Unrestricted -File script?.ps1") or + (process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh", "busybox") and + process.parent.args like "/var/lib/waagent/run-command/download/*/script.sh") + ) + +---------------------------------- + +*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: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* 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-25/prebuilt-rule-8-19-25-azure-vm-extension-deployment-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-azure-vm-extension-deployment-by-user.asciidoc new file mode 100644 index 0000000000..c7ed75b533 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-azure-vm-extension-deployment-by-user.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-25-azure-vm-extension-deployment-by-user]] +=== Azure VM Extension Deployment by User + +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. + +*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://docs.microsoft.com/en-us/azure/virtual-machines/extensions/overview + +*Tags*: + +* 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 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure VM Extension Deployment by User* + + +This rule flags successful `MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/WRITE` operations performed by a user principal +where the extension resource ID matches high-risk extension families (VMAccess, Custom Script, Run Command, DSC, +Microsoft Monitoring Agent). + + +*Triage checklist* + + +- Is the caller UPN a known admin or automation account? +- Is the source IP or ASN consistent with corporate infrastructure or a known VPN? +- Was this extension deployment preceded by a Run Command invocation on the same VM? +- Did the extension deployment coincide with new local account creation on the endpoint? +- Check `azure.activitylogs.identity.claims.authnmethodsreferences` — was MFA present? +- Correlate with endpoint telemetry: process events parented by `WaAppAgent.exe` or `walinuxagent` within 120 seconds of + the extension write timestamp on the same host. + + +*Possible investigation steps* + + +- Review `azure.activitylogs.identity.authorization.evidence.principal_id` and Entra sign-in logs for the caller. +- Examine `azure.resource.id` and `azure.resource.name` to identify the VM and extension type deployed. +- Pivot on the VM for `MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION` and endpoint Run Command or `waagent` activity. +- Review role assignments for the principal on the subscription or resource group. + + +*Response and remediation* + + +- If unauthorized, remove the extension, rotate credentials, and review RBAC on the affected VM and scope. +- 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.COMPUTE/VIRTUALMACHINES/EXTENSIONS/WRITE" and +azure.activitylogs.identity.authorization.evidence.principal_type:User and +event.outcome:(success or Success) and +azure.resource.id:( + *VMACCESSAGENT* or + *CUSTOMSCRIPTEXTENSION* or + *RUNCOMMANDWINDOWS* or + *RUNCOMMANDLINUX* or + */DSC/* or + *MICROSOFTMONITORINGAGENT* +) + +---------------------------------- + +*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: 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: 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: Create Cloud Instance +** ID: T1578.002 +** Reference URL: https://attack.mitre.org/techniques/T1578/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-cloud-instance-metadata-credential-path-http-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-cloud-instance-metadata-credential-path-http-request.asciidoc new file mode 100644 index 0000000000..164026c1b8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-cloud-instance-metadata-credential-path-http-request.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-25-cloud-instance-metadata-credential-path-http-request]] +=== Cloud Instance Metadata Credential Path HTTP Request + +Detects HTTP GET requests to the link-local instance metadata service (169.254.169.254) for cloud credential or token paths on AWS, GCP, or Azure. Adversaries and vulnerable workloads use scripts, shells, or application runtimes to read IAM role credentials or OAuth tokens from the metadata API. Requires the Network Packet Capture integration with HTTP decoding on ports 80 and 443 and process enrichment enabled so "process.*" fields are present. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.http* +* packetbeat-* + +*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.elastic.co/docs/reference/integrations/network_traffic +* https://hackingthe.cloud/aws/general-knowledge/intro_metadata_service/ + +*Tags*: + +* Domain: Cloud +* Domain: Network +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential 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 Cloud Instance Metadata Credential Path HTTP Request* + + +This rule matches outbound HTTP GETs to `169.254.169.254` where the URL path requests IAM credentials or cloud OAuth +tokens, filtered to common scripting runtimes, suspicious executable paths, or tool-like user agents. + + +*Investigation steps* + + +- Confirm `url.path` (AWS `security-credentials`, GCP `oauth2/access_token`, Azure `metadata/identity/oauth2/token`). +- Review `process.name`, `process.executable`, and `user_agent.original` — scripted tools and temp-path binaries are higher risk. +- Check `host.name` or `host.hostname` and whether the workload should run on a cloud VM with an instance profile or managed identity. +- Correlate with cloud audit or sign-in logs for role assumption or token use shortly after the request. +- If credentials may have been exposed, rotate the instance role or managed identity and review API activity from that principal. + + +*False positives* + + +- Platform agents and bootstrap scripts on new instances; allowlist by user agent or host group where validated. + + +*Response* + + +- Restrict IMDS access (IMDSv2 hop limit, network policy) and remove unnecessary instance permissions. +- Investigate the host for follow-on credential use or lateral movement. + +Deploy the https://www.elastic.co/docs/reference/integrations/network_traffic[Network Packet Capture] integration via Fleet on cloud workloads. + +- Enable **Capture HTTP Traffic** and include ports **80** and **443**. +- Enable **Monitor Processes** so network events include the process that initiated the connection. +- Prefer ECS field remapping (`map_to_ecs`) on integration data streams. + +==== Setup + + +Deploy the Network Packet Capture integration via Fleet on cloud workloads. + +Enable Capture HTTP Traffic and include ports 80 and 443.Enable Monitor Processes so network events include the process that initiated the connection.Prefer ECS field remapping (`map_to_ecs`) on integration data streams. + +==== Rule query + + +[source, js] +---------------------------------- +network where event.module == "network_traffic" and destination.ip == "169.254.169.254" and destination.port == 80 and +http.request.method == "GET" and url.path : ( + "/latest/meta-data/iam/security-credentials/*", + "*computeMetadata/v1/instance/service-accounts/*/oauth2/access_token*", + "*metadata/identity/oauth2/token*" +) and ( + ?process.name : ( + "curl", "wget", "python*", "node", "bun", "php*", "ruby", "perl", "bash", "dash", "sh", "tcsh", "tclsh", "wish", + "csh", "zsh", "ksh", "fish", "mksh", "busybox", + "bun.exe", "node.exe", "powershell.exe", "cmd.exe", "curl.exe", "wget.exe", "rundll32.exe", "w3wp.exe", "java*", + "go", "nc", "netcat", "nginx", "apache*", "httpd", "tomcat*", "catalina", "spring*", "dotnet", "gunicorn", "uwsgi", + ".*", "osascript" + ) or ?process.executable : ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/home/*/*", "/var/run/*", "/run/*", "/boot/*", "/.*", "C:\\Users\\*", "?:\\ProgramData\\*" + ) or user_agent.original : ( + "curl*", "wget*", "python*", "ruby*", "Go-http-client*", "node*", "axios*", "undici*", "java*", "php*", "Bun*", + "Apache-HttpClient*", "okhttp*", "RestTemplate*", "*WindowsPowerShell*", "*roadtools*", "*fasthttp*", "*azurehound*", "*bloodhound*", "*aiohttp*" + ) +) + +---------------------------------- + +*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: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-deprecated-uncommon-destination-port-connection-by-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-deprecated-uncommon-destination-port-connection-by-web-server.asciidoc new file mode 100644 index 0000000000..7628f14658 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-deprecated-uncommon-destination-port-connection-by-web-server.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-25-deprecated-uncommon-destination-port-connection-by-web-server]] +=== Deprecated - Uncommon Destination Port Connection by Web Server + +This rule identifies unusual destination port network activity originating from a web server process. The rule is designed to detect potential web shell activity or unauthorized communication from a web server process to external systems. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* + +*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: Persistence +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 7 + +*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 Deprecated - Uncommon Destination Port Connection by Web Server* + + +Web servers, crucial for hosting applications, typically communicate over standard ports like 80 and 443. Adversaries may exploit web server processes to establish unauthorized connections to unusual ports, potentially indicating web shell activity or data exfiltration. This detection rule identifies such anomalies by monitoring egress connections from web server processes to non-standard ports, excluding common local IP ranges, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the process name and user associated with the alert to determine if the connection attempt was made by a legitimate web server process or user, as specified in the query fields (e.g., process.name or user.name). +- Examine the destination IP address to assess whether it is known or suspicious, and check if it falls outside the excluded local IP ranges. +- Investigate the destination port to understand why the connection was attempted on a non-standard port, and determine if this port is associated with any known services or threats. +- Check historical logs for any previous connection attempts from the same process or user to the same or similar destination IPs and ports to identify patterns or repeated behavior. +- Analyze any related network traffic or logs to identify additional context or anomalies that may indicate unauthorized activity or data exfiltration. +- Correlate the alert with other security events or alerts to determine if it is part of a larger attack pattern or campaign. + + +*False positive analysis* + + +- Routine administrative tasks or maintenance scripts may trigger alerts if they involve web server processes connecting to non-standard ports. To manage this, identify and document these tasks, then create exceptions for the specific processes and ports involved. +- Internal monitoring or management tools that use non-standard ports for legitimate purposes can cause false positives. Review the tools in use and exclude their known IP addresses and ports from the rule. +- Development or testing environments often use non-standard ports for web server processes. Ensure these environments are well-documented and consider excluding their IP ranges or specific ports from the rule. +- Load balancers or reverse proxies might redirect traffic to non-standard ports as part of their normal operation. Verify the configuration of these devices and exclude their IP addresses and ports if necessary. +- Custom applications running on web servers may require communication over non-standard ports. Work with application owners to understand these requirements and adjust the rule to exclude these specific cases. + + +*Response and remediation* + + +- Immediately isolate the affected web server from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of the web server's logs and processes to identify any unauthorized changes or suspicious activities, focusing on the processes and user accounts mentioned in the detection rule. +- Terminate any suspicious processes identified during the investigation that are not part of the standard operation of the web server. +- Change passwords and review permissions for the user accounts associated with the web server processes to ensure they have not been compromised. +- Restore the web server from a known good backup if any unauthorized changes or malware are detected, ensuring that the backup is free from compromise. +- Implement network segmentation to limit the web server's access to critical systems and data, reducing the potential impact of future incidents. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected, ensuring comprehensive threat containment and remediation. + + +==== 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] +---------------------------------- +network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and ( + process.name like ( + "apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "mongrel_rails", "gunicorn", + "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn", + "daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel", "php-fpm*", "php-cgi", + "php-fcgi", "php-cgi.cagefs", "catalina.sh", "hiawatha", "lswsctrl" + ) or + user.name in ("apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9") or + user.id in ("33", "498", "48") +) and +network.direction == "egress" and destination.ip != null and +not destination.port in (80, 443, 8080, 8443, 8000, 8888, 3128, 3306, 5432, 8220, 8082) and +not cidrmatch(destination.ip, "127.0.0.0/8", "::1","FE80::/10", "FF00::/8", "10.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", +"192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", +"224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "224.0.0.0/4", "240.0.0.0/4") + +---------------------------------- + +*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/ +* Technique: +** Name: Non-Standard Port +** ID: T1571 +** Reference URL: https://attack.mitre.org/techniques/T1571/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-deprecated-unusual-command-execution-from-web-server-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-deprecated-unusual-command-execution-from-web-server-parent.asciidoc new file mode 100644 index 0000000000..b65a14947d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-deprecated-unusual-command-execution-from-web-server-parent.asciidoc @@ -0,0 +1,253 @@ +[[prebuilt-rule-8-19-25-deprecated-unusual-command-execution-from-web-server-parent]] +=== Deprecated - Unusual Command Execution from Web Server Parent + +This rule detects potential command execution from a web server parent process on a Linux host. Adversaries may attempt to execute commands from a web server parent process to blend in with normal web server activity and evade detection. This behavior is commonly observed in web shell attacks where adversaries exploit web server vulnerabilities to execute arbitrary commands on the host. The detection rule identifies unusual command execution from web server parent processes, which may indicate a compromised host or an ongoing attack. 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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({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: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 14 + +*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 Deprecated - Unusual Command Execution from Web Server Parent* + + +Web servers, such as Apache or Nginx, are crucial for hosting web applications, often running on Linux systems. Adversaries exploit vulnerabilities in these servers to execute arbitrary commands, typically through web shells, blending malicious activity with legitimate server processes. The detection rule identifies suspicious command executions originating from web server processes, focusing on unusual patterns and contexts, such as unexpected working directories or command structures, to flag potential compromises. + + +*Possible investigation steps* + + +- Review the process.command_line field to understand the specific command executed and assess its legitimacy or potential malicious intent. +- Examine the process.working_directory to determine if the command was executed from an unusual or suspicious directory, which could indicate a compromise. +- Check the process.parent.executable and process.parent.name fields to identify the parent process and verify if it is a known web server or related service that could be exploited. +- Investigate the user.name and user.id fields to confirm if the command was executed by a legitimate user or service account, or if it was potentially executed by an unauthorized user. +- Correlate the @timestamp with other logs and events to identify any related activities or anomalies occurring around the same time, which could provide additional context or evidence of an attack. +- Assess the agent.id to determine if the alert is isolated to a single host or if similar activities are observed across multiple hosts, indicating a broader issue. + + +*False positive analysis* + + +- Web development or testing environments may frequently execute commands from web server processes. To handle this, exclude specific working directories like /var/www/dev or /var/www/test from the rule. +- Automated scripts or cron jobs running under web server user accounts can trigger alerts. Identify these scripts and add exceptions for their specific command lines or user IDs. +- Legitimate administrative tasks performed by web server administrators might appear suspicious. Document these tasks and exclude their associated command lines or parent executables. +- Continuous integration or deployment processes that involve web server interactions can be mistaken for threats. Exclude known CI/CD tool command lines or working directories from the rule. +- Monitoring or logging tools that interact with web server processes may generate false positives. Identify these tools and exclude their specific process names or parent executables. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further malicious activity and lateral movement within the network. This can be done by removing the host from the network or applying network segmentation. + +- Terminate any suspicious processes identified by the detection rule, especially those originating from web server parent processes executing shell commands. Use process IDs and command lines from the alert to target specific processes. + +- Conduct a thorough review of the web server logs and application logs to identify any unauthorized access or modifications. Look for patterns that match the command execution detected and any other anomalies. + +- Patch the web server and any associated applications to address known vulnerabilities that may have been exploited. Ensure that all software is up to date with the latest security patches. + +- Restore the affected system from a known good backup if any unauthorized changes or persistent threats are detected. Ensure that the backup is free from compromise before restoration. + +- Implement additional monitoring and alerting for similar activities, focusing on unusual command executions and web server behavior. Enhance logging and alerting to capture more detailed information about process executions and network connections. + +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the attack is part of a larger campaign. Provide them with all relevant data and findings from the initial containment and remediation steps. + + +==== 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] +---------------------------------- +from logs-endpoint.events.process-* metadata _id, _index, _version +| mv_expand event.action +| where + host.os.type == "linux" and + event.type == "start" and + event.action == "exec" and ( + ( + process.parent.name in ( + "apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "mongrel_rails", "gunicorn", + "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn", + "daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel", "php-cgi", + "php-fcgi", "php-cgi.cagefs", "catalina.sh", "hiawatha", "lswsctrl" + ) or + process.parent.name like "php-fpm*" or + user.name in ("apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9") or + user.id in ("33", "498", "48") or + (process.parent.name == "java" and process.parent.working_directory like "/u0?/*") or + process.parent.working_directory like "/var/www/*" + ) + ) and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + process.command_line like "* -c *" and not ( + process.working_directory like "/home/*" or + process.working_directory == "/" or + process.working_directory like "/vscode/vscode-server/*" or + process.parent.executable like "/vscode/vscode-server/*" or + process.parent.executable == "/usr/bin/xfce4-terminal" + ) + +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + process.parent.name, + user.name, + user.id, + process.working_directory, + process.parent.working_directory, + process.name, + process.executable, + process.command_line, + process.parent.executable, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by process.command_line, process.working_directory, process.parent.executable + +| where + Esql.agent_id_count_distinct == 1 and + Esql.event_count < 5 +| sort Esql.event_count asc + +// Extract unique values to ECS fields for alerts exclusion +| eval agent.id = mv_min(Esql.agent_id_values), + host.name = mv_min(Esql.host_name_values) + +| keep agent.id, host.name, process.command_line, process.working_directory, process.parent.executable, Esql.* + +---------------------------------- + +*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-25/prebuilt-rule-8-19-25-deprecated-unusual-process-spawned-from-web-server-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-deprecated-unusual-process-spawned-from-web-server-parent.asciidoc new file mode 100644 index 0000000000..5628e6e313 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-deprecated-unusual-process-spawned-from-web-server-parent.asciidoc @@ -0,0 +1,281 @@ +[[prebuilt-rule-8-19-25-deprecated-unusual-process-spawned-from-web-server-parent]] +=== Deprecated - Unusual Process Spawned from Web Server Parent + +This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish persistence, execute malicious commands, or establish command and control channels on the host system. 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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({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: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 14 + +*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 Deprecated - Unusual Process Spawned from Web Server Parent* + + +Web servers like Apache, Nginx, and others are crucial for hosting applications and services. Adversaries exploit these servers by spawning unauthorized processes to maintain persistence or execute malicious commands. The detection rule identifies anomalies by monitoring low-frequency process spawns from web server parents, focusing on unusual user IDs, directories, and process counts, which may indicate potential threats. + + +*Possible investigation steps* + + +- Review the process.executable and process.command_line fields to understand the nature of the process that was spawned and assess if it aligns with expected behavior for the web server environment. +- Examine the process.working_directory to determine if the directory is a legitimate location for web server operations or if it appears suspicious, such as being outside typical web server directories. +- Check the user.name and user.id fields to verify if the process was executed by a legitimate web server user or if it was initiated by an unexpected or unauthorized user account. +- Investigate the process.parent.executable to confirm whether the parent process is a known and trusted web server executable or if it has been tampered with or replaced. +- Correlate the event with other logs or alerts from the same agent.id to identify any additional suspicious activities or patterns that may indicate a broader compromise. +- Assess the host.os.type to ensure the alert pertains to a Linux system, as specified in the query, and verify if there are any known vulnerabilities or misconfigurations on the host that could have been exploited. + + +*False positive analysis* + + +- Processes related to legitimate web server maintenance tasks may trigger alerts. Review scheduled tasks or cron jobs that align with the alert timing and consider excluding these specific processes if they are verified as non-threatening. +- Development environments often spawn processes that mimic attack patterns. Identify and exclude processes originating from known development directories or executed by development user accounts. +- Automated scripts or monitoring tools running under web server user accounts can be mistaken for malicious activity. Verify these scripts and add exceptions for their specific process names or working directories. +- Frequent updates or deployments in web applications can lead to unusual process spawns. Document these activities and exclude related processes if they consistently match the alert criteria during known update windows. +- Custom web server modules or plugins may execute processes that appear suspicious. Validate these modules and exclude their associated processes if they are part of normal operations. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement. +- Terminate any suspicious processes identified by the alert that are not part of legitimate web server operations. +- Conduct a thorough review of the process command lines and executables flagged by the alert to identify any malicious scripts or binaries. Remove or quarantine these files as necessary. +- Check for unauthorized changes in web server configurations or files within the working directories flagged by the alert. Restore any altered files from a known good backup. +- Review user accounts and permissions associated with the web server processes to ensure no unauthorized accounts or privilege escalations have occurred. Reset passwords and revoke unnecessary access. +- Monitor network traffic from the affected host for any signs of command and control communication, and block any identified malicious IP addresses or domains. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are 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 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] +---------------------------------- +from logs-endpoint.events.process-* metadata _id, _index, _version +| mv_expand event.action +| where + host.os.type == "linux" and + event.type == "start" and + event.action == "exec" and ( + ( + process.parent.name in ( + "apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "mongrel_rails", "gunicorn", + "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn", + "daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel", "php-cgi", + "php-fcgi", "php-cgi.cagefs", "catalina.sh", "hiawatha", "lswsctrl" + ) or + process.parent.name like "php-fpm*" or + user.name in ("apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9") or + user.id in ("33", "498", "48") or + (process.parent.name == "java" and process.parent.working_directory like "/u0?/*") or + process.parent.working_directory like "/var/www/*" + ) + ) and ( + process.name in ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "socat", "openssl", "busybox", + "nc", "ncat", "netcat", "nc.openbsd", "nc.traditional", "nohup", "setsid", "mkfifo", "mknod", + "node", "socket" + ) or + process.name like "python*" or + process.name like "php*" or + process.name like "perl" or + process.name like "ruby*" or + process.name like "lua*" or + process.executable like "/tmp/*" or + process.executable like "/var/tmp/*" or + process.executable like "/dev/shm/*" or + process.executable like "/var/log/*" or + process.executable like "/sys/*" or + process.executable like "/media/*" or + process.executable like "/proc/*" or + process.executable like "/var/backups/*" or + process.executable like "/var/mail/*" or + process.executable like "/var/spool/*" or + process.executable like "/var/www/*" or + process.executable like "./*" or + process.name like ".*" + ) and + not ( + process.working_directory like "/home/*" or + process.working_directory == "/" or + process.working_directory like "/var/www/*.ch" or + process.parent.executable like "/vscode/vscode-server/*" + ) + +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + process.parent.name, + user.name, + user.id, + process.working_directory, + process.parent.working_directory, + process.name, + process.executable, + process.command_line, + process.parent.executable, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by process.executable, process.working_directory, process.parent.executable + +| where + Esql.agent_id_count_distinct == 1 and + Esql.event_count < 5 +| sort Esql.event_count asc + +// Extract unique values to ECS fields for alerts exclusion +| eval agent.id = mv_min(Esql.agent_id_values), + host.name = mv_min(Esql.host_name_values) + +| keep agent.id, host.name, process.executable, process.working_directory, process.parent.executable, Esql.* + +---------------------------------- + +*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/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Sub-technique: +** Name: Lua +** ID: T1059.011 +** Reference URL: https://attack.mitre.org/techniques/T1059/011/ +* 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-25/prebuilt-rule-8-19-25-dumping-account-hashes-via-built-in-commands.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-dumping-account-hashes-via-built-in-commands.asciidoc new file mode 100644 index 0000000000..7319a7f5f8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-dumping-account-hashes-via-built-in-commands.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-25-dumping-account-hashes-via-built-in-commands]] +=== Dumping Account Hashes via Built-In Commands + +Identifies the execution of macOS built-in commands used to dump user account hashes. Adversaries may attempt to dump credentials to obtain account login information in the form of a hash. These hashes can be cracked or leveraged for lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*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://apple.stackexchange.com/questions/186893/os-x-10-9-where-are-password-hashes-stored +* https://www.unix.com/man-page/osx/8/mkpassdb/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* 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 Dumping Account Hashes via Built-In Commands* + + +In macOS environments, built-in commands like `defaults` and `mkpassdb` can be exploited by adversaries to extract user account hashes, which are crucial for credential access. These hashes, once obtained, can be cracked to reveal passwords or used for lateral movement within a network. The detection rule identifies suspicious process executions involving these commands and specific arguments, signaling potential credential dumping activities. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the `defaults` or `mkpassdb` commands with arguments like `ShadowHashData` or `-dump`, as these are indicative of credential dumping attempts. +- Identify the user account associated with the process execution to determine if the activity aligns with expected behavior for that user or if it appears suspicious. +- Check the historical activity of the involved user account and the host to identify any patterns or anomalies that could suggest unauthorized access or lateral movement. +- Investigate any network connections or subsequent processes initiated by the suspicious process to assess potential data exfiltration or further malicious actions. +- Correlate the event with other security alerts or logs from the same host or user account to build a comprehensive timeline of the activity and assess the scope of the potential compromise. + + +*False positive analysis* + + +- System administrators or security tools may legitimately use the `defaults` or `mkpassdb` commands for system maintenance or auditing purposes. To manage these, create exceptions for known administrative accounts or tools that regularly execute these commands. +- Automated scripts or management software might invoke these commands as part of routine operations. Identify and whitelist these scripts or software to prevent unnecessary alerts. +- Developers or IT personnel might use these commands during testing or development phases. Establish a process to temporarily exclude these activities by setting up time-bound exceptions for specific user accounts or devices. +- Security assessments or penetration tests could trigger this rule. Coordinate with security teams to schedule and document these activities, allowing for temporary rule adjustments during the testing period. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further lateral movement or data exfiltration. +- Terminate any suspicious processes identified as using the `defaults` or `mkpassdb` commands with the specified arguments to halt ongoing credential dumping activities. +- Conduct a thorough review of user accounts on the affected system to identify any unauthorized access or changes, focusing on accounts with elevated privileges. +- Reset passwords for all potentially compromised accounts, especially those with administrative access, and enforce strong password policies. +- Analyze system logs and network traffic to identify any additional systems that may have been accessed using the compromised credentials, and apply similar containment measures. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach. +- Implement enhanced monitoring and alerting for similar suspicious activities across the network to detect and respond to future 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 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 == "defaults" and process.args like~ "ShadowHashData") or + (process.name == "mkpassdb" and process.args == "-dump") or + (process.name == "dscl" and process.args like~ "ShadowHashData") or + ( + process.name in ("plutil","cat","strings","xxd","head") and + process.args like "/var/db/dslocal/nodes/Default/users/*.plist" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: /etc/passwd and /etc/shadow +** ID: T1003.008 +** Reference URL: https://attack.mitre.org/techniques/T1003/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-entra-id-device-registration-with-roadtools-default-os-build.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-entra-id-device-registration-with-roadtools-default-os-build.asciidoc new file mode 100644 index 0000000000..0b73ab8f55 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-entra-id-device-registration-with-roadtools-default-os-build.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-25-entra-id-device-registration-with-roadtools-default-os-build]] +=== Entra ID Device Registration with ROADtools Default OS Build + +Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19041.928" and the device display name follows the default "DESKTOP-" pattern. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and it is uncommon for the OS build to match the hardcoded value across an environment of otherwise patched hosts. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved provisioning tooling and device naming conventions before relying on it. + +*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://unit42.paloaltonetworks.com/roadtools-cloud-attacks/ +* https://github.com/dirkjanm/ROADtools +* https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/ + +*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 +* 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 Entra ID Device Registration with ROADtools Default OS Build* + + +ROADtools (roadtx) registers a device in Entra ID with a default cloud device OS build of `10.0.19041.928` and a default +display name of `DESKTOP-<8 random characters>`. This OS build is the current default value roadtx uses and +differs from the OS version of legitimate hosts, making the build a useful indicator of ROADtools device registration. +Rogue device registration is typically a precursor to Primary Refresh Token (PRT) acquisition, MFA/Conditional Access +bypass, and persistent token-based access. + +The matching Entra ID audit event is an `Add device` operation initiated by the `Device Registration Service`, where the +modified properties record the registered device characteristics: + +- `azure.auditlogs.properties.target_resources.0.modified_properties.3` (`CloudDeviceOSVersion`) = `10.0.19041.928` +- `azure.auditlogs.properties.target_resources.0.modified_properties.4` (`CloudDisplayName`) = `DESKTOP-*` + + +*Possible investigation steps* + + +- Confirm the registering identity via `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and determine +whether that user is expected to register a new device. +- Review `azure.auditlogs.identity` to confirm the `Device Registration Service` initiated the request, and use +`azure.correlation_id` to pivot across the full registration flow (`Add device`, `Add registered users to device`, +`Add registered owner to device`). +- Inspect the device name in `azure.auditlogs.properties.target_resources.0.display_name`; default `DESKTOP-` names that +do not match your naming convention are suspicious. +- Pivot to `azure.signinlogs` for the same user and timeframe and look for follow-on sign-ins where the incoming token +type is a `primaryRefreshToken`, or for risky/AiTM sign-ins immediately preceding the registration. +- Review `azure.auditlogs.properties.initiated_by.user.ipAddress` and geolocation for the registration source. Flag +unexpected IPs, hosting/VPS ASNs, or impossible-travel relative to the user's normal activity. +- Correlate with the user-agent-based device registration rules (e.g., `Dsreg/*`, `DeviceRegistrationClient`, +`Microsoft.OData.Client/*`) for the same user or correlation ID to strengthen attribution to ROADtools. + + +*False positive analysis* + + +- Unmanaged or imaged Windows 10 20H1 hosts may legitimately present the `10.0.19041.928` build with a default +`DESKTOP-` hostname. Validate against device inventory and known provisioning programs. +- Authorized security assessments using ROADtools will match. Document the engagement and add scoped exceptions. + + +*Response and remediation* + + +- If confirmed malicious, remove the registered device from Entra ID and revoke the user's refresh tokens and primary +refresh tokens. +- Disable the account or reset credentials per policy and review for additional persistence (added owners, app +registrations, or service principal credentials). +- Conduct historical analysis using `azure.correlation_id` and the registering user to determine scope of access. +- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices and +require MFA for registration). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.auditlogs" and event.action:"Add device" and + azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value:*10.0.19041.928* and + azure.auditlogs.properties.target_resources.0.modified_properties.4.new_value:*DESKTOP-* + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-entra-id-device-with-roadtools-default-os-build-entity-analytics.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-entra-id-device-with-roadtools-default-os-build-entity-analytics.asciidoc new file mode 100644 index 0000000000..9e8d030cb7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-entra-id-device-with-roadtools-default-os-build-entity-analytics.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-25-entra-id-device-with-roadtools-default-os-build-entity-analytics]] +=== Entra ID Device with ROADtools Default OS Build (Entity Analytics) + +Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is `10.0.19041.928`. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and the OS build typically differs from the patched OS versions of legitimate hosts in the environment. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved device builds and naming conventions before relying on it. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-entityanalytics_entra_id.device-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-6h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/roadtools-cloud-attacks/ +* https://github.com/dirkjanm/ROADtools +* https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Entity Analytics +* Use Case: Asset Visibility +* 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 Entra ID Device with ROADtools Default OS Build (Entity Analytics)* + + +ROADtools (roadtx) registers a device in Entra ID with a default OS build of `10.0.19041.928` and a default name of +`DESKTOP-<8 random characters>`. This OS build is the current default value roadtx uses and differs from +the OS version of legitimate hosts, making the build a useful indicator of ROADtools device registration. This rule runs +against the Entra ID Entity Analytics device inventory and fires the first time a device matching this fingerprint +appears, so an alert generally represents a newly observed rogue device rather than a real-time registration event. +Rogue device registration is typically a precursor to Primary Refresh Token (PRT) acquisition, MFA/Conditional Access +bypass, and persistent token-based access. + + +*Possible investigation steps* + + +- Confirm the device identity via `host.name`, `host.os.version`, `entityanalytics_entra_id.device.display_name`, and +`entityanalytics_entra_id.device.id` (or `device.id`). Default `DESKTOP-` names that do not match your naming convention +are suspicious. +- Review `entityanalytics_entra_id.device.registration_date_time` and `entityanalytics_entra_id.device.trust_type` to +establish when and how the device was registered (e.g., Azure AD registered vs. joined). +- Identify the registered owner via `entityanalytics_entra_id.device.registered_owners.user_principal_name` and determine +whether that user is expected to register a new device. +- Check `entityanalytics_entra_id.device.is_managed` and `entityanalytics_entra_id.device.is_compliant`; ROADtools +devices are typically unmanaged and non-compliant. +- Pivot to `logs-azure.auditlogs-*` for the corresponding `Add device` event (initiated by the `Device Registration +Service`) and to `logs-azure.signinlogs-*` for sign-ins by the device owner where the incoming token type is a +`primaryRefreshToken`. +- Correlate with the companion audit-log rule "Entra ID Device Registration with ROADtools Default OS Build" +for the same device name to confirm registration-time activity. + + +*False positive analysis* + + +- Unmanaged or imaged Windows 10 20H1 hosts may legitimately report the `10.0.19041.928` build with a default +`DESKTOP-` host name. Validate against device inventory and patch baseline. +- Authorized security assessments using ROADtools will appear in inventory. Document the engagement and add scoped +exceptions. + + +*Response and remediation* + + +- If confirmed malicious, remove the device from Entra ID and revoke the owner's refresh tokens and primary refresh +tokens. +- Disable the account or reset credentials per policy and review for additional persistence (added owners, app +registrations, or service principal credentials). +- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices and +require MFA for registration). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"entityanalytics_entra_id.device" and + event.provider:"Microsoft Entra ID" and + host.name:DESKTOP-* and host.os.version:"10.0.19041.928" + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-entra-id-kali365-default-user-agent-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-entra-id-kali365-default-user-agent-detected.asciidoc new file mode 100644 index 0000000000..db314a3f27 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-entra-id-kali365-default-user-agent-detected.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-25-entra-id-kali365-default-user-agent-detected]] +=== Entra ID Kali365 Default User-Agent Detected + +Identifies the default user agent string associated with Kali365 (also referred to as Kali365 Live), a phishing-as-a-service (PhaaS) platform that automates OAuth 2.0 device code phishing and adversary-in-the-middle (AiTM) session capture against Microsoft 365 and Microsoft Entra ID. The Kali365 Electron desktop client identifies itself with the user agent `kali365-live/1.0.0` when polling for and replaying captured OAuth tokens, so its appearance in Entra ID sign-in logs, Entra ID audit logs, or the Microsoft 365 unified audit log indicates that an attacker-controlled Kali365 client is interacting with the tenant using stolen tokens. Unlike dual-use offensive tooling, Kali365 is a criminal service with no legitimate enterprise use, making this user agent a high-fidelity indicator of active account compromise. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* +* logs-azure.signinlogs-* +* 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://www.ic3.gov/PSA/2026/PSA260521 + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Data Source: Microsoft Entra ID Audit Logs +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Threat: Kali365 +* Tactic: Initial Access +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Kali365 Default User-Agent Detected* + + +Kali365 (Kali365 Live) is a phishing-as-a-service platform distributed via Telegram that provides affiliates with +AI-generated lures, automated device code phishing campaigns, target-tracking dashboards, and OAuth token capture. The +typical flow is: a lure delivers a Microsoft device code, the victim enters it on the legitimate Microsoft verification +page and unknowingly authorizes the attacker, Kali365 captures the resulting OAuth access and refresh tokens, and the +attacker uses those tokens for persistent, MFA-free access to Microsoft 365 (Outlook, Teams, OneDrive). + +The Kali365 desktop client presents the user agent `kali365-live/1.0.0`. This rule fires when that user agent is observed +in Entra ID sign-in logs, Entra ID audit logs, or the Microsoft 365 unified audit log. Because the user agent maps to a +criminal service with no legitimate use, an alert generally indicates that stolen tokens are already being replayed +against the tenant. + + +*Possible investigation steps* + + +- Confirm the tool and identify the affected identity. + - `user_agent.original` matches `kali365-live/*`. + - Pivot on `user.name`, `azure.signinlogs.properties.user_principal_name`, or the M365 audit `user.id`. +- Review the origin and compare against the user's normal sign-in behavior. + - `source.ip`, `source.geo.*`, and `source.as.organization.name`; flag hosting/VPS ASNs and unexpected geographies. + - Cross-reference published Kali365 infrastructure (`216.203.20.95`, `162.243.166.119`, `199.91.220.111`). +- Confirm the device code grant in sign-in logs. + - `azure.signinlogs.properties.authentication_protocol` is `deviceCode`. + - Review `app_id`/`app_display_name` and `resource_display_name` for the brokered mail or collaboration API. +- Scope follow-on access in the Microsoft 365 unified audit log for the same user and timeframe. + - Look for mailbox access, inbox rule creation, OneDrive/SharePoint downloads, or Teams activity from the same session or IP. +- Check the Entra ID audit log for a device registration by the same identity around the alert window. + - A `Register device` event by the identity paired (via `azure.correlation_id`) with an `Add device` event from the `Device Registration Service` indicates a Primary Refresh Token (PRT) was issued for persistence that survives password resets. + + +*False positive analysis* + + +- This user agent has no legitimate enterprise use. + - The only expected matches are authorized security research or red team exercises running the Kali365 client; validate and document before dismissing. + + +*Response and remediation* + + +- Remove rogue device registrations created by the user BEFORE revoking sessions. + - Device-bound PRTs survive `revokeSignInSessions`, so a device left in place re-establishes access. + - `GET /v1.0/users/{id}/registeredDevices` and `/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}` for unrecognized devices. +- Revoke refresh tokens and sessions, then reset credentials and re-register MFA. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the account if you need to halt activity during investigation. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Remove other attacker persistence: malicious inbox/forwarding rules, OAuth consents, and app passwords. +- Block or monitor Kali365 source IPs and infrastructure, and hunt for the user agent across other users and tenants. +- Apply Conditional Access to the device code grant. + - Require a managed/compliant device, or block the device-code flow outside approved app and user populations. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : ("azure.signinlogs" or "azure.auditlogs" or "o365.audit") and user_agent.original: kali365-live/* + +---------------------------------- + +*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: 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: 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-25/prebuilt-rule-8-19-25-entra-id-microsoft-authentication-broker-sign-in-with-non-standard-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-entra-id-microsoft-authentication-broker-sign-in-with-non-standard-user-agent.asciidoc new file mode 100644 index 0000000000..0858842dc5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-entra-id-microsoft-authentication-broker-sign-in-with-non-standard-user-agent.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-25-entra-id-microsoft-authentication-broker-sign-in-with-non-standard-user-agent]] +=== Entra ID Microsoft Authentication Broker Sign-In with Non-Standard User Agent + +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. + +*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/ +* https://any.run/malware-trends/tycoon/ + +*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: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Microsoft Authentication Broker Sign-In with Non-Standard User Agent* + + +Review `azure.signinlogs.properties.user_principal_name`, `user_agent.original`, +`azure.signinlogs.properties.resource_display_name`, `azure.signinlogs.properties.session_id`, `source.ip`, and +`source.as.organization.name`. + +Confirm whether the user or application intentionally used a non-browser client against the requested resource. + + +*Possible investigation steps* + + +- Inspect `user_agent.original` for automation libraries (for example `node`, `axios`, `python-requests`, `curl`). +- Correlate `azure.signinlogs.properties.session_id` with other sign-ins, device registration audit events, or Graph + activity in the same time window. +- Review conditional access outcomes and identity protection signals for the user. +- Compare `source.ip` and ASN against expected VPN, MDM, and developer egress. + + +*False positive analysis* + + +- Microsoft platform and mobile clients using Mozilla-, Dalvik-, CFNetwork-, or Windows-AzureAD-Authentication-Provider- + style user agents are excluded by design. +- First-party CLI tools and test harnesses that legitimately broker tokens may still match if they use uncommon user + agent strings. + + +*Response and remediation* + + +- If malicious, revoke refresh tokens for the user, review newly registered devices, and reset credentials per policy. +- Escalate when paired with suspicious ASN sign-ins, multi-IP OAuth flows, or follow-on Graph data access. + + +==== Setup + + +Microsoft Entra ID sign-in logs (`logs-azure.signinlogs-*`) must populate `user_agent.original`, +`azure.signinlogs.properties.app_display_name`, and `azure.signinlogs.properties.resource_display_name`. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.signinlogs" and event.action:"Sign-in activity" and event.outcome:(success or Success) and +(azure.signinlogs.properties.app_display_name:"Microsoft Authentication Broker" or azure.signinlogs.properties.app_id:"29d9ed98-a469-4536-ade2-f981bc1d605e") and +user_agent.original:(* and not (Mozilla* or Dalvik* or *CFNetwork* or Windows-AzureAD-Authentication-Provider* or Java*ThinkPad*)) and +azure.signinlogs.properties.resource_display_name:* + +---------------------------------- + +*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 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: 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: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc new file mode 100644 index 0000000000..62f64b860e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc @@ -0,0 +1,250 @@ +[[prebuilt-rule-8-19-25-entra-id-oauth-user-impersonation-to-microsoft-graph]] +=== Entra ID OAuth User Impersonation to Microsoft Graph + +Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 30m + +*Searches indices from*: now-31m ({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://github.com/dirkjanm/ROADtools +* https://attack.mitre.org/techniques/T1078/004/ +* https://pushsecurity.com/blog/consentfix + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Domain: API +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Data Source: Microsoft Graph +* Data Source: Microsoft Graph Activity Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Defense Evasion +* Tactic: Initial Access + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth User Impersonation to Microsoft Graph* + + +Identifies potential phishing, session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID and client application. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location. + +This rule uses ESQL aggregations and thus has dynamically generated fields. Correlation of the values in the alert document may need to be +performed to the original sign-in and Graph events for further context. + + +*Possible investigation steps* + + +- This rule relies on an aggregation-based ESQL query, therefore the alert document will contain dynamically generated fields. + - To pivot into the original events, it is recommended to use the values captured to filter in timeline or discovery for the original sign-in and Graph events. +- Review the session ID and user ID to identify the user account involved in the suspicious activity. +- Check the source addresses involved in the sign-in and Graph access to determine if they are known or expected locations for the user. + - The sign-in source addresses should be two, one for the initial phishing sign-in and the other when exchanging the auth code for a token by the adversary. + - The Graph API source address should identify the IP address used by the adversary to access Microsoft Graph. +- Review the user agent strings for the sign-in and Graph access events to identify any anomalies or indicators of compromise. +- Analyze the Graph permission scopes to identify what resources were accessed and whether they align with the user's expected behavior. +- Check the timestamp difference between the sign-in and Graph access events to determine if they occurred within a reasonable time frame that would suggest successful phishing to token issuance and then Graph access. +- Identify the original sign-in event to investigation if conditional access policies were applied, such as requiring multi-factor authentication or blocking access from risky locations. In phishing scenarios, these policies likely were applied as the victim user would have been prompted to authenticate. + + +*False positive analysis* + +- This pattern may occur during legitimate device switching or roaming between networks (e.g., corporate to mobile). +- Developers or power users leveraging multiple environments may also trigger this detection if session persistence spans IP ranges. Still, this behavior is rare and warrants investigation when rapid IP switching and Graph access are involved. + + +*Response and remediation* + + +- If confirmed malicious, revoke all refresh/access tokens for the user principal. +- Block the source IP(s) involved in the Graph access. +- Notify the user and reset credentials. +- Review session control policies and conditional access enforcement. +- Monitor for follow-on activity, such as lateral movement or privilege escalation. +- Review conditional access policies to ensure they are enforced correctly. + + +==== Setup + + + +*Required Microsoft Entra ID Sign-In and Graph Activity Logs* + +This rule requires the Microsoft Entra ID Sign-In Logs and Microsoft Graph Activity Logs integration to be enabled and configured to collect audit and activity logs via Azure Event Hub. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-*, logs-azure.graphactivitylogs-* metadata _id, _version, _index +| where + (data_stream.dataset == "azure.signinlogs" + and source.`as`.organization.name != "MICROSOFT-CORP-MSN-AS-BLOCK" + and azure.signinlogs.properties.session_id is not null) + or + (data_stream.dataset == "azure.graphactivitylogs" + and source.`as`.organization.name != "MICROSOFT-CORP-MSN-AS-BLOCK" + and azure.graphactivitylogs.properties.c_sid is not null) + +| eval + Esql.azure_signinlogs_properties_session_id_coalesce = coalesce(azure.signinlogs.properties.session_id, azure.graphactivitylogs.properties.c_sid), + Esql.azure_signinlogs_properties_user_id_coalesce = coalesce(azure.signinlogs.properties.user_id, azure.graphactivitylogs.properties.user_principal_object_id), + Esql.azure_signinlogs_properties_app_id_coalesce = coalesce(azure.signinlogs.properties.app_id, azure.graphactivitylogs.properties.app_id), + Esql.source_ip = source.ip, + Esql.@timestamp = @timestamp, + Esql.event_type_case = case( + data_stream.dataset == "azure.signinlogs", "signin", + data_stream.dataset == "azure.graphactivitylogs", "graph", + "other" + ), + Esql.signin_source_asn = case(data_stream.dataset == "azure.signinlogs", source.`as`.organization.name), + Esql.graph_source_asn = case(data_stream.dataset == "azure.graphactivitylogs", source.`as`.organization.name) + +| where Esql.azure_signinlogs_properties_app_id_coalesce not in ( + "4354e225-50c9-4423-9ece-2d5afd904870", // Augmentation Loop + "cc15fd57-2c6c-4117-a88c-83b1d56b4bbe", // Microsoft Teams Services + "ecd6b820-32c2-49b6-98a6-444530e5a77a", // Microsoft Edge [Community Contributed] + "e8be65d6-d430-4289-a665-51bf2a194bda", // Microsoft 365 App Catalog Services + "ab9b8c07-8f02-4f72-87fa-80105867a763", // OneDrive SyncEngine + "394866fc-eedb-4f01-8536-3ff84b16be2a", // Microsoft People Cards Service + "66a88757-258c-4c72-893c-3e8bed4d6899", // Office 365 Search Service + "9ea1ad79-fdb6-4f9a-8bc3-2b70f96e34c7", // Bing + "d7b530a4-7680-4c23-a8bf-c52c121d2e87", // Microsoft Edge Enterprise New Tab Page [Community Contributed] + "6f7e0f60-9401-4f5b-98e2-cf15bd5fd5e3", // Microsoft Application Command Service [Community Contributed] + "52c2e0b5-c7b6-4d11-a89c-21e42bcec444", // Graph Files Manager + "27922004-5251-4030-b22d-91ecd9a37ea4", // Outlook Mobile + "bb893c22-978d-4cd4-a6f7-bb6cc0d6e6ce", // Olympus [Community Contributed] + "26a7ee05-5602-4d76-a7ba-eae8b7b67941", // Windows Search + "00000007-0000-0000-c000-000000000000", // Dataverse + "6bc3b958-689b-49f5-9006-36d165f30e00", // Teams CMD Services Artifacts + "0ec893e0-5785-4de6-99da-4ed124e5296c", // Office UWP PWA [Community Contributed] + "fc108d3f-543d-4374-bbff-c7c51f651fe5", // Zoom + "01fc33a7-78ba-4d2f-a4b7-768e336e890e", // MS PIM + "7ab7862c-4c57-491e-8a45-d52a7e023983" // Power Automate / Logic Apps Graph Connector + ) and Esql.signin_source_asn IS NOT NULL and Esql.graph_source_asn IS NOT NULL + +| keep + Esql.azure_signinlogs_properties_session_id_coalesce, + Esql.source_ip, + Esql.@timestamp, + Esql.event_type_case, + Esql.azure_signinlogs_properties_user_id_coalesce, + Esql.azure_signinlogs_properties_app_id_coalesce, + Esql.signin_source_asn, + Esql.graph_source_asn, + source.`as`.organization.name, + user_agent.original, + url.original, + azure.graphactivitylogs.properties.scopes, + azure.signinlogs.properties.user_principal_name + +| stats + Esql.azure_signinlogs_properties_user_id_coalesce_values = values(Esql.azure_signinlogs_properties_user_id_coalesce), + Esql.azure_signinlogs_properties_session_id_coalesce_values = values(Esql.azure_signinlogs_properties_session_id_coalesce), + Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name), + Esql.source_ip_values = values(Esql.source_ip), + Esql.source_ip_count_distinct = count_distinct(Esql.source_ip), + Esql.source_as_organization_name_values = values(source.`as`.organization.name), + Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name), + Esql.signin_source_asn_values = values(Esql.signin_source_asn), + Esql.signin_source_asn_count_distinct = count_distinct(Esql.signin_source_asn), + Esql.graph_source_asn_values = values(Esql.graph_source_asn), + Esql.graph_source_asn_count_distinct = count_distinct(Esql.graph_source_asn), + Esql.user_agent_original_values = values(user_agent.original), + Esql.azure_signinlogs_properties_app_id_coalesce_values = values(Esql.azure_signinlogs_properties_app_id_coalesce), + Esql.azure_signinlogs_properties_app_id_coalesce_count_distinct = count_distinct(Esql.azure_signinlogs_properties_app_id_coalesce), + Esql.event_type_case_values = values(Esql.event_type_case), + Esql.event_type_case_count_distinct = count_distinct(Esql.event_type_case), + Esql.signin_time_min = min(case(Esql.event_type_case == "signin", Esql.@timestamp)), + Esql.graph_time_min = min(case(Esql.event_type_case == "graph", Esql.@timestamp)), + Esql.url_original_values = values(url.original), + Esql.azure_graphactivitylogs_properties_scopes_values = values(azure.graphactivitylogs.properties.scopes), + Esql.event_count = count() + by + Esql.azure_signinlogs_properties_session_id_coalesce, + Esql.azure_signinlogs_properties_app_id_coalesce, + Esql.azure_signinlogs_properties_user_id_coalesce + +| eval + Esql.event_signin_to_graph_delay_minutes_date_diff = date_diff("minutes", Esql.signin_time_min, Esql.graph_time_min), + Esql.event_signin_to_graph_delay_days_date_diff = date_diff("days", Esql.signin_time_min, Esql.graph_time_min) + +| where + Esql.event_type_case_count_distinct > 1 and + Esql.source_ip_count_distinct > 1 and + Esql.source_as_organization_name_count_distinct > 1 and + Esql.azure_signinlogs_properties_app_id_coalesce_count_distinct == 1 and + Esql.signin_time_min is not null and + Esql.graph_time_min is not null and + Esql.event_signin_to_graph_delay_minutes_date_diff > 0 and + Esql.event_signin_to_graph_delay_days_date_diff == 0 and + (Esql.signin_source_asn_count_distinct + Esql.graph_source_asn_count_distinct) == Esql.source_as_organization_name_count_distinct + +---------------------------------- + +*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: 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/ +* Sub-technique: +** Name: Web Session Cookie +** ID: T1550.004 +** Reference URL: https://attack.mitre.org/techniques/T1550/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-external-user-added-to-google-workspace-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-external-user-added-to-google-workspace-group.asciidoc new file mode 100644 index 0000000000..0cd5b3fae8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-external-user-added-to-google-workspace-group.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-25-external-user-added-to-google-workspace-group]] +=== External User Added to Google Workspace Group + +Detects an external Google Workspace user account being added to an existing group. Adversaries may add external user accounts as a means to intercept shared files or emails with that specific group. + +*Rule type*: eql + +*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/33329 +* 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: Initial Access +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating External User Added to Google Workspace Group* + + +Google Workspace groups allow organizations to assign specific users to a group that can share resources. Application specific roles can be manually set for each group, but if not inherit permissions from the top-level organizational unit. + +Threat actors may use phishing techniques and container-bound scripts to add external Google accounts to an organization's groups with editorial privileges. As a result, the user account is unable to manually access the organization's resources, settings and files, but will receive anything shared to the group. As a result, confidential information could be leaked or perhaps documents shared with editorial privileges be weaponized for further intrusion. + +This rule identifies when an external user account is added to an organization's groups where the domain name of the target does not match the Google Workspace domain. + + +*Possible investigation steps* + +- Identify user account(s) associated by reviewing `user.name` or `user.email` in the alert + - The `user.target.email` field contains the user added to the groups + - The `group.name` field contains the group the target user was added to +- Identify specific application settings given to the group which may indicate motive for the external user joining a particular group +- With the user identified, verify administrative privileges are scoped properly to add external users to the group + - Unauthorized actions may indicate the `user.email` account has been compromised or leveraged to add an external user +- To identify other users in this group, search for `event.action: "ADD_GROUP_MEMBER"` + - It is important to understand if external users with `@gmail.com` are expected to be added to this group based on historical references +- Review Gmail logs where emails were sent to and from the `group.name` value + - This may indicate potential internal spearphishing + + +*False positive analysis* + +- With the user account whom added the new user, verify this action was intentional +- Verify that the target whom was added to the group is expected to have access to the organization's resources and data +- If other members have been added to groups that are external, this may indicate historically that this action is expected + + +*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 multi-factor authentication for the user. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security defaults https://cloud.google.com/security-command-center/docs/how-to-investigate-threats[provided 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] +---------------------------------- +iam where data_stream.dataset == "google_workspace.admin" and event.action == "ADD_GROUP_MEMBER" and + not endsWith(user.target.domain, user.target.group.domain) + +---------------------------------- + +*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: 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-25/prebuilt-rule-8-19-25-forwarded-google-workspace-security-alert.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-forwarded-google-workspace-security-alert.asciidoc new file mode 100644 index 0000000000..06b531430a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-forwarded-google-workspace-security-alert.asciidoc @@ -0,0 +1,67 @@ +[[prebuilt-rule-8-19-25-forwarded-google-workspace-security-alert]] +=== Forwarded Google Workspace Security Alert + +Identifies the occurrence of a security alert from the Google Workspace alerts center. Google Workspace's security alert center provides an overview of actionable alerts that may be affecting an organization's domain. An alert is a warning of a potential security issue that Google has detected. + +*Rule type*: query + +*Rule indices*: + +* logs-google_workspace.alert-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://workspace.google.com/products/admin/alert-center/ +* 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: Log Auditing +* Use Case: Threat Detection +* Resources: Investigation Guide + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This is a promotion rule for Google Workspace security events, which are alertable events per the vendor. +Consult vendor documentation on interpreting specific events. + +==== Setup + + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: google_workspace.alert + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-google-workspace-device-registration-burst-for-single-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-google-workspace-device-registration-burst-for-single-user.asciidoc new file mode 100644 index 0000000000..9aa100a291 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-google-workspace-device-registration-burst-for-single-user.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-25-google-workspace-device-registration-burst-for-single-user]] +=== Google Workspace Device Registration Burst for Single User + +Detects bursts of Google Workspace device registration events for the same user, where three or more distinct "google_workspace.device.id" values are emitted in a one-minute window. Although "DEVICE_REGISTER_UNREGISTER_EVENT" fires routinely on session/sync registration and is not a true physical device enrollment, legitimate user activity typically produces fewer than three distinct device IDs in a single minute. A high-cardinality burst is the fingerprint behavior of AiTM phishing-kit relays (Tycoon2FA Google variant, EvilGinx phishlets) and stolen-OAuth-token replay tooling, both of which mint a new session attestation per relay or replay attempt. + +*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://developers.google.com/workspace/admin/reports/v1/appendix/activity/mobile +* https://any.run/malware-trends/tycoon/ +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Google Workspace +* Data Source: Google Workspace Device Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Tactic: Initial Access +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Device Registration Burst for Single User* + + +`DEVICE_REGISTER_UNREGISTER_EVENT` from the Google Workspace `mobile` provider does not represent a one-time physical device enrollment. The Reports API emits a fresh `google_workspace.device.id` on every session/sync registration, and a single physical device can produce multiple events per day as Workspace-aware apps independently attest. Legitimate activity, however, very rarely concentrates three or more distinct device IDs into a one-minute window for a single user. A burst of that shape is the fingerprint of either: + +- An AiTM phishing-kit relay session: the kit completes the victim's sign-in against Google, then attests one or more device contexts of its own, all from the same kit infrastructure within seconds. +- Token-replay tooling driving multiple sessions in quick succession against a stolen OAuth refresh token. + +In both cases the device fingerprint (OS, model) typically converges on a single value distinct from the victim's baseline (e.g., all "Windows" attestations for a known macOS user), and the burst events fire within a few seconds of each other rather than spread across minutes. + + +*Possible investigation steps* + + +- Identify the user (`user.email`, `user.id`) and inspect `Esql.host_os_version_values`, `Esql.device_type_values`, `Esql.device_model_values`. A homogeneous fingerprint (single OS, single model) across multiple device IDs in the burst window is highly suspicious. +- Cross-reference `logs-google_workspace.login` for `event.action: "login_success"` events from the same `user.email` in the 30 minutes preceding the burst. The kit-relay sign-ins should appear there. Inspect each sign-in's `source.geo.country_name`, `source.as.organization.name`, and `user_agent.original` for divergence from the user's baseline. Hosting-provider ASNs (Clouvider, Host Telecom, OVH, Alibaba, Vultr, DigitalOcean, M247) for interactive sign-ins are high-fidelity suspicious. +- Cross-reference `logs-google_workspace.token` for `event.action: "authorize"` events for the same user near the burst window. Each kit relay normally fires a corresponding OAuth grant within seconds, often to Google Chrome (`77185425430.apps.googleusercontent.com`) or another long-lived first-party client. +- Pull all `logs-google_workspace.device` events for the user across the 24 hours preceding the burst to characterize the user's normal device-event rate. A user who typically produces less than 1 event per hour suddenly emitting 3+ in a minute is a strong anomaly even before considering device fingerprints. +- Confirm with the user whether they were performing a new device setup, OS upgrade, or onboarding activity during the burst window. + + +*False positive analysis* + + +- New device setup where a user simultaneously enrolls multiple Workspace-aware apps (Gmail, Drive, Calendar, Meet) on first boot can produce a burst. Validate by checking whether the burst coincides with a known device refresh or onboarding event. +- Major OS upgrades that re-attest several apps concurrently can also produce a burst. The host OS version values will reflect the upgrade transition. +- Bulk MDM rollouts or fleet refreshes may produce bursts across many users at the same time. Consider rule suppression during planned rollouts. + + +*Response and remediation* + + +- Treat as likely AiTM compromise or token-replay activity until proven otherwise. Suspend the user, revoke all OAuth tokens (`DELETE /admin/directory/v1/users//tokens/`), reset the password, clear recovery email/phone, sign out all sessions. +- Audit `logs-google_workspace.token: authorize` events for kit-issued or replay-issued OAuth grants. Each grant maps to an independently replayable refresh token; revoking via the consent removes them all at once. +- Audit the device IDs surfaced in the burst via the Admin SDK Directory API and remove any that are confirmed adversary-controlled. +- If the tenant exposes GCP resources to the user, cross-check `logs-gcp.audit-*` for `authenticationInfo.principalEmail` matching the user from a non-baseline `callerIp` in the same window; token theft frequently extends to cross-cloud access. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-google_workspace.device-* +| where event.dataset == "google_workspace.device" + and event.action == "DEVICE_REGISTER_UNREGISTER_EVENT" + and google_workspace.device.account_state == "REGISTERED" + and user.email is not null + and google_workspace.device.id is not null + +| eval Esql.bucket_minute = date_trunc(1 minute, @timestamp) + +| stats + Esql.count_distinct_device_id = count_distinct(google_workspace.device.id), + Esql.device_id_values = values(google_workspace.device.id), + Esql.device_resource_id_values = values(google_workspace.device.resource.id), + Esql.device_type_values = values(google_workspace.device.type), + Esql.device_model_values = values(google_workspace.device.model), + Esql.device_account_state_values = values(google_workspace.device.account_state), + Esql.host_os_version_values = values(host.os.version), + Esql.event_provider_values = values(event.provider), + Esql.event_id_values = values(event.id), + Esql.google_workspace_actor_type_values = values(google_workspace.actor.type), + Esql.google_workspace_event_type_values = values(google_workspace.event.type), + Esql.organization_id_values = values(organization.id), + Esql.user_domain_values = values(user.domain), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp), + Esql.event_count = count(*) + by user.id, user.email, user.name, Esql.bucket_minute + +| where Esql.count_distinct_device_id >= 3 + +| keep user.id, + user.email, + user.name, + Esql.bucket_minute, + Esql.timestamp_first_seen, + Esql.timestamp_last_seen, + Esql.count_distinct_device_id, + Esql.event_count, + Esql.device_id_values, + Esql.device_resource_id_values, + Esql.device_type_values, + Esql.device_model_values, + Esql.device_account_state_values, + Esql.host_os_version_values, + Esql.event_provider_values, + Esql.event_id_values, + Esql.google_workspace_actor_type_values, + Esql.google_workspace_event_type_values, + Esql.organization_id_values, + Esql.user_domain_values + +---------------------------------- + +*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: 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: 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-google-workspace-drive-data-transfer-or-takeout-export-initiated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-google-workspace-drive-data-transfer-or-takeout-export-initiated.asciidoc new file mode 100644 index 0000000000..1872a62152 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-google-workspace-drive-data-transfer-or-takeout-export-initiated.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-25-google-workspace-drive-data-transfer-or-takeout-export-initiated]] +=== Google Workspace Drive Data Transfer or Takeout Export Initiated + +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. + +*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/1247799?hl=en +* https://support.google.com/a/answer/10276199 +* 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 +* Tactic: Exfiltration +* Resources: Investigation Guide + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Drive Data Transfer or Takeout Export Initiated* + + +Google Drive is a cloud storage service available to Google Workspace users. Administrators can bulk-transfer a +departing user's Drive files to another in-domain account, or create Customer Takeout exports that package user or +organizational data for download or transfer to an external destination (for example, another cloud provider). + +Adversaries with compromised administrator credentials may abuse these workflows to collect sensitive files without +relying on per-file sharing changes. This rule detects two related admin audit actions: + +- `CREATE_DATA_TRANSFER_REQUEST` with Drive application scope — ownership or bulk transfer to another user. +- `CUSTOMER_TAKEOUT_CREATED` — initiation of a Customer Takeout export job. + + +*Possible investigation steps* + + +- Review admin logs for involved user accounts. +- For data transfer requests, confirm the request initiator, source and destination users in `user.email`, `user.target.email`, and `google_workspace.admin.new_value`. +- For Customer Takeout events (`CUSTOMER_TAKEOUT_CREATED`): + - In Elasticsearch, pivot on `google_workspace.admin.OBFUSCATED_CUSTOMER_TAKEOUT_REQUEST_ID` to find related admin events for the same export job (for example completion or failure). The Admin console Data export UI does not expose or accept this ID for search. + - In the Admin console, go to Data > Data import & export > Data export and identify the export by correlating `@timestamp`, Set up by (`user.email`), and Last start date / Status. The export Name shown in the console is not present in Workspace admin logs. + - Open the matching row and select View archive to review exported data scope and where the archive is stored (Google-provided bucket or customer-owned Cloud Storage). +- Determine if involved user accounts are active. +- Check if involved user accounts were recently disabled, suspended, or scheduled for deletion. +- Review involved user accounts for potentially misconfigured permissions or roles. +- Review the involved shared drives, My Drive files, or export scope to determine if this action was expected. +- Triage potentially related alerts based on the users involved. + + +*False positive analysis* + + +- Drive data transfers require Google Workspace administration permissions. Confirm the transfer was planned during offboarding or role change and targets the correct receiver. +- Customer Takeout exports are common for compliance, migration, and departures. Validate the initiator is authorized and the export scope matches policy. + + +*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:"CREATE_DATA_TRANSFER_REQUEST" and google_workspace.admin.application.name:Drive*) or + event.action:"CUSTOMER_TAKEOUT_CREATED" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* 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: Remote Data Staging +** ID: T1074.002 +** Reference URL: https://attack.mitre.org/techniques/T1074/002/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-google-workspace-suspended-user-account-renewed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-google-workspace-suspended-user-account-renewed.asciidoc new file mode 100644 index 0000000000..840dd09e61 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-google-workspace-suspended-user-account-renewed.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-25-google-workspace-suspended-user-account-renewed]] +=== Google Workspace Suspended User Account Renewed + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: low + +*Risk score*: 21 + +*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/1110339 +* 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: Initial Access +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 9 + +*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 Google Workspace Suspended User Account Renewed* + + +Google Workspace manages user identities and access, crucial for organizational security. Adversaries may exploit the renewal of suspended accounts to regain unauthorized access, bypassing security measures. The detection rule identifies such events by monitoring specific administrative actions, helping analysts spot potential misuse and maintain secure access controls. + + +*Possible investigation steps* + + +- Review the event logs for the specific action `UNSUSPEND_USER` to identify the user account that was renewed and gather details about the timing and context of the action. +- Check the identity of the administrator or service account that performed the `UNSUSPEND_USER` action to determine if the action was authorized or if there are signs of account compromise. +- Investigate the history of the suspended user account to understand why it was initially suspended and assess any potential risks associated with its renewal. +- Examine recent activity logs for the renewed user account to identify any suspicious behavior or unauthorized access attempts following the account's reactivation. +- Cross-reference the event with other security alerts or incidents to determine if the renewal is part of a broader pattern of suspicious activity within the organization. + + +*False positive analysis* + + +- Routine administrative actions may trigger the rule when IT staff unsuspend accounts for legitimate reasons, such as resolving a temporary issue. To manage this, create exceptions for known IT personnel or specific administrative actions that are part of regular account maintenance. +- Automated processes or scripts that unsuspend accounts as part of a workflow can also lead to false positives. Identify and document these processes, then exclude them from triggering alerts by using specific identifiers or tags associated with the automation. +- User accounts that are temporarily suspended due to policy violations or inactivity and later reinstated can cause false positives. Implement a review process to verify the legitimacy of these reinstatements and adjust the rule to exclude such cases when they are part of a documented policy. + + +*Response and remediation* + + +- Immediately review the user account activity logs to determine if any unauthorized actions were taken after the account was unsuspended. Focus on sensitive data access and changes to security settings. +- Temporarily suspend the user account again to prevent further unauthorized access while the investigation is ongoing. +- Notify the security team and relevant stakeholders about the potential security incident to ensure coordinated response efforts. +- Conduct a thorough review of the account's permissions and access levels to ensure they align with the user's current role and responsibilities. Adjust as necessary to follow the principle of least privilege. +- If malicious activity is confirmed, initiate a password reset for the affected account and any other accounts that may have been compromised. +- Implement additional monitoring on the affected account and similar accounts to detect any further suspicious activity. +- Review and update security policies and procedures related to account suspension and reactivation to prevent similar incidents in the future. + + + + +*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 google_workspace.event.type: "USER_SETTINGS" and event.action: "UNSUSPEND_USER" + +---------------------------------- + +*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: 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/ +* 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-25/prebuilt-rule-8-19-25-google-workspace-user-login-with-unusual-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-google-workspace-user-login-with-unusual-asn.asciidoc new file mode 100644 index 0000000000..d593716dae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-google-workspace-user-login-with-unusual-asn.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-25-google-workspace-user-login-with-unusual-asn]] +=== Google Workspace User Login with Unusual ASN + +Detects the first time a Google Workspace user successfully signs in from a given source ASN within a 14-day historical window. Most users have a stable set of egress ASNs (home ISP, corporate VPN, mobile carrier). A new ASN for a user is a meaningful anomaly as it surfaces ISP changes and travel, but also catches AiTM phishing-kit relays whose egress ASN was never previously associated with the user. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-google_workspace.login* +* logs-google_workspace.token* + +*Severity*: low + +*Risk score*: 21 + +*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://any.run/malware-trends/tycoon/ +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one + +*Tags*: + +* 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 +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace User Login with Unusual ASN* + + +This rule emits when a user signs in successfully from an ASN that has not been observed for that user in the prior 14 days. Most legitimate users cluster around a small number of egress ASNs (corporate VPN, home ISP, primary mobile carrier). New ASNs are not all malicious, but new ASNs that match hosting providers, anonymization networks, or geographies inconsistent with the user's profile are high-fidelity suspicious. + + +*Possible investigation steps* + + +- Inspect `source.as.organization.name` and `source.as.number`. Categorize: residential ISP (low concern absent other indicators), corporate VPN (validate against tenant baseline), mobile carrier (validate by region), hosting provider / VPS (Clouvider, Host Telecom, Alibaba, OVH, M247, DigitalOcean, Vultr) - high concern for interactive sign-ins. +- Inspect `source.geo.country_name` and `source.geo.region_name`. New geo + known travel is fine. New geo + unexpected travel needs user confirmation. +- Pull the user's full `google_workspace.login` history across the lookback. Is this a one-off sign-in or sustained activity from the new ASN? +- Cross-reference `logs-google_workspace.token` for any `event.action: "authorize"` events from the same `user.email` immediately following the sign-in. An OAuth grant minted from the new ASN within seconds of sign-in is the AiTM kit signature. +- Cross-reference `logs-google_workspace.device` for any `DEVICE_REGISTER_UNREGISTER_EVENT` with `account_state: "REGISTERED"` from the same user near the same time. New device + new ASN is a stronger compromise signal than either alone. +- Confirm with the user whether they signed in from a new network intentionally. + + +*False positive analysis* + + +- Users on rotating VPN exits, hotspot sharing, or coffee-shop Wi-Fi will produce new ASNs legitimately. +- Mobile users in unfamiliar regions (travel, conference attendance) will geo-resolve to new ASNs. +- Engineering teams using cloud workstations (Cloud Workstations, Codespaces, etc.) will egress through hosting ASNs even for legitimate sign-ins. Tune by allowlisting your tenant's known cloud-workstation egress. +- For high-noise tenants, expand `history_window_start` to 14 days to reduce false-positive rate at the cost of slower-to-fire detection for genuinely new ASNs. + + +*Response and remediation* + + +- If the new ASN is a hosting provider and the user has not knowingly used such a network: treat as likely AiTM. Suspend user, revoke OAuth tokens, reset password, clear recovery info, sign out all sessions. +- If the new ASN is benign (verified ISP change, travel, new VPN): add to the user's baseline. Consider broader hardening (require MFA re-verification on new-network sign-in via Workspace Context-Aware Access). + + +==== Setup + + + +*Setup* + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- Google Workspace Reports API ingestion lag commonly runs in the 30-minute to 3-hour range. This rule's 130-minute lookback gives partial coverage but will miss events delayed beyond that envelope. +- See https://support.google.com/a/answer/7061566 for Google's published guidance on event availability. +- Check your integration's Login lag time to ensure it is configured to meet the needs of this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: ("google_workspace.login" or "google_workspace.token") and + event.action: ("login_success" or "authorize") and + source.as.number: * and + user.email: * + +---------------------------------- + +*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: 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/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-google-workspace-user-organizational-unit-changed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-google-workspace-user-organizational-unit-changed.asciidoc new file mode 100644 index 0000000000..e051971c9f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-google-workspace-user-organizational-unit-changed.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-25-google-workspace-user-organizational-unit-changed]] +=== Google Workspace User Organizational Unit Changed + +Users in Google Workspace are typically assigned a specific organizational unit that grants them permissions to certain services and roles that are inherited from this organizational unit. Adversaries may compromise a valid account and change which organizational account the user belongs to which then could allow them to inherit permissions to applications and resources inaccessible prior to. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: low + +*Risk score*: 21 + +*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 +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace User Organizational Unit Changed* + + +An organizational unit is a group that an administrator can create in the Google Admin console to apply settings to a specific set of users for Google Workspace. By default, all users are placed in the top-level (parent) organizational unit. Child organizational units inherit the settings from the parent but can be changed to fit the needs of the child organizational unit. + +Permissions and privileges for users are often inherited from the organizational unit they are placed in. Therefore, if a user is changed to a separate organizational unit, they will inherit all privileges and permissions. User accounts may have unexpected privileges when switching organizational units that would allow a threat actor to gain a stronger foothold within the organization. The principle of least privileged (PoLP) should be followed when users are switched to different groups in Google Workspace. + +This rule identifies when a user has been moved to a different organizational unit. + + +*Possible investigation steps* + + +- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. + - The `user.target.email` field contains the user that had their assigned organizational unit switched. +- Identify the user's previously assigned unit and new organizational unit by checking the `google_workspace.admin.org_unit.name` and `google_workspace.admin.new_value` fields. +- Identify Google Workspace applications whose settings were explicitly set for this organizational unit. + - Search for `event.action` is `CREATE_APPLICATION_SETTING` where `google_workspace.admin.org_unit.name` is the new organizational unit. +- After identifying the involved user, verify administrative privileges are scoped properly to allow changing user organizational units. +- Identify if the user account was recently created by searching for `event.action: CREATE_USER`. + - Add `user.email` with the target user account that recently had their organizational unit changed. +- Filter on `user.name` or `user.target.email` of the user who took this action and review the last 48 hours of activity for anything that may indicate a compromise. + + +*False positive analysis* + + +- After identifying the user account that changed another user's organizational unit, verify the action was intentional. +- Verify whether the target user who received this update is expected to inherit privileges from the new organizational unit. +- Review potential maintenance notes or organizational changes. They might explain why a user's organization was changed. + + +*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 google_workspace.event.type:"USER_SETTINGS" and event.action:"MOVE_USER_TO_ORG_UNIT" + +---------------------------------- + +*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-25/prebuilt-rule-8-19-25-google-workspace-user-sign-in-from-atypical-device-type.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-google-workspace-user-sign-in-from-atypical-device-type.asciidoc new file mode 100644 index 0000000000..5cb1ec4b56 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-google-workspace-user-sign-in-from-atypical-device-type.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-25-google-workspace-user-sign-in-from-atypical-device-type]] +=== Google Workspace User Sign-in from Atypical Device Type + +Detects the first time a Google Workspace user is observed authenticating from a device of a given type (e.g., WINDOWS, MAC, ANDROID, IOS, LINUX) within a historical window. Note that "DEVICE_REGISTER_UNREGISTER_EVENT" events do not represent one-time physical device enrollments; the Google Reports API emits a fresh "google_workspace.device.id" on each event, and the same physical device may produce multiple events per day as sessions/sync renewals occur. The rule therefore surfaces a user authenticating from a new device type, not a new physical device. This is still high-fidelity because adversaries who compromise a Workspace identity via AiTM kits or stolen OAuth refresh tokens frequently relay sessions from device types that diverge from the legitimate user's baseline (e.g., a WINDOWS session appearing for a known macOS user, or simultaneous WINDOWS+MAC sessions within minutes), which is the canonical kit fingerprint. Because the underlying token retains access after password rotation, treat unexpected device-type divergence as a compromise indicator and revoke tokens, not just credentials. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-google_workspace.device* + +*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://developers.google.com/workspace/admin/reports/v1/appendix/activity/mobile +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://any.run/malware-trends/tycoon/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Google Workspace +* Data Source: Google Workspace Device Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace User Sign-in from Atypical Device Type* + + +This rule emits when a user authenticates from a device whose type (`google_workspace.device.type`) has not been observed for that user in the prior 14 days. + +**Important: this is not a true "device enrollment" event.** Google's Reports API emits `DEVICE_REGISTER_UNREGISTER_EVENT` from the `mobile` provider on every session/sync registration, with a fresh `google_workspace.device.id` each time. A single physical device can produce many such events per day. The rule therefore identifies a *device-type-per-user* anomaly: a session originating from a class of device the user has not been seen on in the prior 14 days, not a one-time physical device join. + +The detection value remains high because adversaries who relay sessions via AiTM kits (Tycoon2FA Google variant, EvilGinx phishlets) or who replay stolen OAuth refresh tokens typically egress from device fingerprints that diverge from the victim's baseline. Two patterns are especially diagnostic: + +- A device type appearing for a user that does not match the user's known OS (e.g., WINDOWS sessions for a user whose corporate laptop is macOS). +- Simultaneous WINDOWS+MAC (or similar cross-type) sessions for the same user within a short window, indicating the kit and the victim are active at the same time. + +Because the underlying OAuth refresh token continues to grant access after a password reset, password rotation alone does not remediate this; only token revocation does. + + +*Possible investigation steps* + + +- Identify the user (`user.email`), the device type (`google_workspace.device.type`), and the device model and OS (`google_workspace.device.model`, `host.os.version`). +- Compare the registered device type to the user's known device baseline. A WINDOWS device for a known macOS user, or an ANDROID device for a known iOS user, is a high-confidence adversary signal. +- Pull all `logs-google_workspace.login` events for the same `user.email` in the 24 hours leading up to the device registration. Inspect `source.geo.country_name`, `source.as.organization.name`, and `user_agent.original` for each sign-in. A device registration immediately following a sign-in from a non-baseline ASN (hosting providers, cheap VPS, AiTM kit egress like Clouvider or Host Telecom) is the kit-driven persistence signature. +- Cross-reference `logs-google_workspace.token` for `event.action: "authorize"` events from the same user near the same time. OAuth grants minted around the device registration window indicate the kit has minted additional tokens for the attacker-controlled device. +- Inspect `google_workspace.device.id` and `google_workspace.device.resource.id` for the registered device. Capture both, since `device.id` is required for the device removal API call during remediation. +- Confirm with the user whether the device registration is theirs (new hardware, BYOD enrollment) or unexpected. + + +*False positive analysis* + + +- Legitimate first-time device enrollment for new hardware, BYOD onboarding, or device refresh cycles. Validate by checking IT hardware tickets, onboarding records, or HR. +- Planned MDM rollouts that register many users' devices in a short window. Consider a temporary rule suppression during scheduled rollouts. +- Users who legitimately use multiple device types and happened to first enroll a given type outside the lookback window (e.g., always had a personal Android but only just enrolled it in Workspace). + + +*Response and remediation* + + +- If the device registration is unexpected: treat as compromise. Immediately suspend the user, revoke all OAuth tokens (`DELETE /admin/directory/v1/users//tokens/`), reset the password, and clear recovery email/phone. +- Remove the attacker-controlled device via the Admin SDK Directory API: `POST /admin/directory/v1/customer//devices/chromeos//action` (or the mobile device variant) to wipe / remove the device. +- Audit any post-registration mailbox, Drive, and Calendar activity for adversary data access or exfiltration. +- Cross-check `logs-gcp.audit-*` if the tenant exposes GCP resources to the user: look for `authenticationInfo.principalEmail` matching the user from a non-baseline `callerIp` in the same window, since token theft frequently extends to cross-cloud access. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "google_workspace.device" and +event.action: "DEVICE_REGISTER_UNREGISTER_EVENT" and +google_workspace.device.account_state: "REGISTERED" and +google_workspace.device.type: * and +user.email: * + +---------------------------------- + +*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: 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-25/prebuilt-rule-8-19-25-kubernetes-admission-webhook-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-kubernetes-admission-webhook-created-or-modified.asciidoc new file mode 100644 index 0000000000..769779efc7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-kubernetes-admission-webhook-created-or-modified.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-25-kubernetes-admission-webhook-created-or-modified]] +=== Kubernetes Admission Webhook Created or Modified + +Detects creation, modification, or deletion of Kubernetes MutatingWebhookConfigurations or ValidatingWebhookConfigurations by non-system identities. Admission webhooks intercept every API request matching their rules before persistence, giving an attacker powerful capabilities: injecting malicious sidecars into every new pod via a mutating webhook, blocking security tooling deployments via a validating webhook, or silently exfiltrating pod specifications to an external server. Webhook manipulation is a stealthy persistence and defense evasion technique because the webhook configuration itself looks benign in kubectl output while actively modifying or intercepting all matching Kubernetes API traffic. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*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*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Admission Webhook Created or Modified* + + +Admission webhooks can mutate or validate resources before they are persisted. A malicious webhook can inject sidecars, +alter securityContext, block defensive workloads, or exfiltrate pod specs. This rule alerts on allowed changes to +MutatingWebhookConfiguration and ValidatingWebhookConfiguration objects by identities outside common system patterns. + + +*Possible investigation steps* + + +- Confirm the webhook resource and operation: + - kubernetes.audit.objectRef.resource and kubernetes.audit.verb + - kubernetes.audit.objectRef.name (the webhook configuration name) +- Attribute the actor and access path: + - user.name (human vs service account vs node identity) + - source.ip and user_agent.original + - In cloud-managed clusters, map the identity to IAM/Entra principal data present in kubernetes.audit.user.extra.*. +- Extract the webhook destination and review for external exfiltration: + - kubernetes.audit.requestObject.webhooks.clientConfig.url (suspicious when pointing to the public internet) + - kubernetes.audit.requestObject.webhooks.clientConfig.service.* (in-cluster service; still validate namespace/name) +- Review impact-driving webhook settings: + - failurePolicy (e.g., Ignore can make malicious webhooks stealthier by avoiding obvious outages) + - namespaceSelector / objectSelector targeting (e.g., excluding kube-system while targeting everything else) + - rules.operations and rules.resources (e.g., CREATE pods is consistent with broad sidecar injection) + - sideEffects, timeoutSeconds, matchPolicy, reinvocationPolicy +- Scope blast radius and follow-on activity: + - Hunt for pods created/updated after the webhook change that include unexpected containers, initContainers, env vars, + volume mounts, or securityContext changes. + - Check for concurrent RBAC changes, token creation, or secret access from the same identity and source IP. + + +*False positive analysis* + + +- GitOps upgrades or controller installs can legitimately change admission webhooks. Validate the change against: + - approved Helm/Git commits, change tickets, and expected controller namespaces + - known controller identities (cert-manager, Gatekeeper, Kyverno, service mesh controllers) + + +*Response and remediation* + + +- If unauthorized, revert or delete the webhook configuration from a known-good source (GitOps/Helm), then block the + actor identity and rotate any credentials it used. +- If the webhook targeted pod creation, assume workload impact: identify affected namespaces/workloads, redeploy from + trusted manifests/images, and validate that new pods are no longer being mutated. +- If an external clientConfig.url was used, treat it as potential data exfiltration and review egress/DNS logs for the + destination around the alert window. + + +==== Rule query + + +[source, js] +---------------------------------- +kubernetes.audit.objectRef.resource:("mutatingwebhookconfigurations" or "validatingwebhookconfigurations") and +kubernetes.audit.verb:("create" or "update" or "patch" or "delete") and +kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +user.name:(* and not + (system\:kube-controller-manager or + system\:kube-scheduler or + system\:serviceaccount\:kube-system\:* or + eks\:* or aksService or masterclient or nodeclient or + system\:serviceaccount\:gke-managed-system\:* or + system\:serviceaccount\:cert-manager\:* or + system\:serviceaccount\:gatekeeper-system\:* or + system\:serviceaccount\:kyverno\:* or + system\:serviceaccount\:*\:*-operator) +) and +kubernetes.audit.objectRef.name:(* and not (pod-identity-webhook or vpc-resource-mutating-webhook or eks-* or gke-*)) and +not (kubernetes.audit.user.groups:"system:serviceaccounts:flux-system" and kubernetes.audit.objectRef.name:"k8tz") + +---------------------------------- + +*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: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc new file mode 100644 index 0000000000..85f947e837 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-25-kubernetes-and-cloud-credential-path-access-via-process-arguments]] +=== Kubernetes and Cloud Credential Path Access via Process Arguments + +Flags Linux process executions whose arguments reference high-value Kubernetes service-account material, kubeconfig or node PKI paths, or common cloud files, when invoked via typical file-reading utilities or from ephemeral directories. Useful for spotting in-cluster and hybrid credential theft early. + +*Rule type*: query + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* + +*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://attack.mitre.org/techniques/T1552/ +* https://kubernetes.io/docs/concepts/security/service-accounts/ + +*Tags*: + +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Domain: Endpoint +* Domain: Kubernetes +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes and Cloud Credential Path Access via Process Arguments* + + +Confirm whether the process user and parent chain are expected to read the matched path (for example a CI job, +bootstrap script, or kubelet). Reconstruct the full command line and check for piping, encoding, or exfiltration +patterns immediately after the read. + + +*Possible investigation steps* + + +- Map the workload or login session to an identity; prioritize events from nodes, jump hosts, or pods with mounted + service account tokens. +- Correlate with file, network, and Kubernetes audit telemetry for secret reads, token minting, or API calls using + harvested material. + + +*Response and remediation* + + +- Rotate affected service account tokens, kubeconfigs, and cloud keys when access was unauthorized; review RBAC and + secret mount policy for the workload. + + +==== Setup + + + +*Setup* + + +Requires **Elastic Defend** and/or **Auditd Manager** process telemetry (`logs-endpoint.events.process*`, +`logs-auditd_manager.auditd-*`, `auditbeat-*`) with command-line argument capture for exec events. + + +*Elastic Defend* + +Install the Elastic Defend integration via Fleet on Linux hosts and use a policy that collects process events with +arguments. + + +*Auditd Manager* + +Deploy Auditd Manager and ensure execve (or equivalent process) auditing is enabled so `process.args` and +`process.executable` populate for monitored binaries. + +See https://docs.elastic.co/integrations/auditd_manager + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.action:(exec or executed) and +( + process.name:( + busybox or cat or head or tail or more or less or sed or awk or + find or grep or ls or whereis or cp or mv or ln or + curl or wget or scp or rsync or tar or zip or gzip or + base64 or xxd or od or dd or tee or strings or xargs or jq or yq or + openssl or ssh or sftp or nc or ncat or netcat or socat or + python* or perl* or ruby* or node or php* or lua* or .* + ) or + process.args:( + cat or head or tail or more or less or sed or awk or + find or grep or cp or mv or curl or wget or base64 or + tar or scp or dd or strings or xargs + ) or + process.executable:(/tmp/* or /var/tmp/* or /dev/shm/* or /home/* or /run/user/*) +) and process.args:( + "/var/run/secrets/kubernetes.io/serviceaccount/token" or + "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt" or + "/var/run/secrets/eks.amazonaws.com/serviceaccount/token" or + "/var/run/secrets/azure/tokens/azure-identity-token" or + "/var/run/secrets/tokens/azure-identity-token" or + "/var/lib/kubelet/kubeconfig" or + "/etc/kubernetes/admin.conf" or + "/etc/kubernetes/pki/ca.key" or + "/etc/kubernetes/pki/apiserver-kubelet-client.key" or + "/var/lib/kubelet/pki/kubelet-client-current.pem" or + "/etc/rancher/k3s/k3s.yaml" or + */.aws/credentials or + */.aws/cli/cache/*.json or + */.aws/sso/cache/*.json or + */.azure/accessTokens.json or + */.azure/azureProfile.json or + */.azure/msal_token_cache.json or + */confluence/confluence.cfg.xml or + *confluence/conf/server.xml + */.config/gcloud/application_default_credentials.json or + */.config/gcloud/credentials.db or + */.config/gcloud/access_tokens.db or + */.config/gcloud/legacy_credentials or + */.kube/config or + */.docker/config.json +) + +---------------------------------- + +*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: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* 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-25/prebuilt-rule-8-19-25-kubernetes-static-pod-manifest-file-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-kubernetes-static-pod-manifest-file-access.asciidoc new file mode 100644 index 0000000000..52c55162d8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-kubernetes-static-pod-manifest-file-access.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-25-kubernetes-static-pod-manifest-file-access]] +=== Kubernetes Static Pod Manifest File Access + +Detects Linux process executions where shells, editors, interpreters, or file/stream utilities reference /etc/kubernetes/manifests in process arguments. That directory holds static pod manifests read by the kubelet; interaction via editors, downloaders, kubectl, redirection helpers (tee, dd), or scripting runtimes may indicate staging or tampering with manifests for persistence or privileged workload placement. Pairs with file-telemetry rules that flag direct manifest creation on container workloads. + +*Rule type*: query + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* +* 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://kubernetes.io/docs/tasks/configure-pod-container/static-pod/ +* https://attack.mitre.org/techniques/T1053/007/ + +*Tags*: + +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Domain: Endpoint +* Domain: Kubernetes +* Domain: Container +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Static Pod Manifest File Access* + + +Review the full command line (process.args, process.command_line), user.id, user.name, process.parent, and whether the +session was interactive. Confirm if the host is a Kubernetes node or admin jump host where manifest edits are expected. + + +*Possible investigation steps* + + +- Compare activity to change windows and identity baselines; prioritize events without matching change tickets. +- Inspect subsequent process and file events on the same host for writes under /etc/kubernetes/manifests or kubelet + restarts. +- Correlate with Kubernetes audit logs and node/agent telemetry for related compromise indicators. + + +*Response and remediation* + + +- If unauthorized, restore manifests from known-good sources, isolate the host, and review cluster integrity per incident + policy. + + +==== Setup + + + +*Setup* + + +Requires **Elastic Defend** and/or **Auditd Manager** process telemetry (`logs-endpoint.events.process*`, +`logs-auditd_manager.auditd-*`, `auditbeat-*`) with command-line argument capture for exec events. + + +*Elastic Defend* + +Install the Elastic Defend integration via Fleet on Linux hosts and use a policy that collects process events with +arguments. + + +*Auditd Manager* + +Deploy Auditd Manager and ensure execve (or equivalent process) auditing is enabled so `process.args` and +`process.executable` populate for monitored binaries. + +See https://docs.elastic.co/integrations/auditd_manager + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.action:(exec or executed) and +process.name:( + bash or sh or dash or zsh or + cat or cp or mv or touch or tee or dd or + sed or awk or + curl or wget or scp or + vi or vim or nano or echo or + busybox or + python* or perl* or ruby* or node or lua* or + openssl or base64 or xxd or + .*) and + process.args:(*/etc/kubernetes/manifests/* and not (/etc/kubernetes/manifests/etcd* or /etc/kubernetes/manifests/kube-apiserver* or /etc/kubernetes/manifests/kube-scheduler* or /etc/kubernetes/manifests/kube-controller-manager*)) and + not (process.args :printf* and process.working_directory :/home/*-svc-nessus) and + not process.parent.executable :("/opt/nessus/sbin/nessusd" or "/opt/nessus_agent/sbin/nessus-agent-module") + +---------------------------------- + +*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: Container Orchestration Job +** ID: T1053.007 +** Reference URL: https://attack.mitre.org/techniques/T1053/007/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Container Service +** ID: T1543.005 +** Reference URL: https://attack.mitre.org/techniques/T1543/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-m365-exchange-inbox-forwarding-rule-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-m365-exchange-inbox-forwarding-rule-created.asciidoc new file mode 100644 index 0000000000..142697830e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-m365-exchange-inbox-forwarding-rule-created.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-25-m365-exchange-inbox-forwarding-rule-created]] +=== M365 Exchange Inbox Forwarding Rule Created + +Identifies when a new Inbox forwarding rule is created in Microsoft 365. Inbox rules process messages in the Inbox based on conditions and take actions. In this case, the rules will forward the emails to a defined address. Attackers can abuse Inbox Rules to intercept and exfiltrate email data without making organization-wide configuration changes or having the corresponding privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-o365.audit-* +* 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://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/responding-to-a-compromised-email-account?view=o365-worldwide +* https://docs.microsoft.com/en-us/powershell/module/exchange/new-inboxrule?view=exchange-ps +* https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-outlook-rules-forms-attack?view=o365-worldwide +* https://raw.githubusercontent.com/PwC-IR/Business-Email-Compromise-Guide/main/Extractor%20Cheat%20Sheet.pdf +* https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Configuration Audit +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 214 + +*Rule authors*: + +* Elastic +* Gary Blackwell +* Austin Songer +* Marco Pedrinazzi + +*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 M365 Exchange Inbox Forwarding Rule Created* + + +Microsoft 365 allows users to create inbox rules to automate email management, such as forwarding messages to another address. While useful, attackers can exploit these rules to secretly redirect emails, facilitating data exfiltration. The detection rule monitors for the creation of such forwarding rules, focusing on successful events that specify forwarding parameters, thus identifying potential unauthorized email redirection activities. + + +*Possible investigation steps* + + +- Review the event details to identify the user account associated with the creation of the forwarding rule by examining the o365.audit.Parameters. +- Check the destination email address specified in the forwarding rule (ForwardTo, ForwardAsAttachmentTo, or RedirectTo) to determine if it is an external or suspicious address. +- Investigate the user's recent activity logs in Microsoft 365 to identify any unusual or unauthorized actions, focusing on event.dataset:o365.audit and event.provider:Exchange. +- Verify if the user has a legitimate reason to create such a forwarding rule by consulting with their manager or reviewing their role and responsibilities. +- Assess if there have been any recent security incidents or alerts related to the user or the destination email address to identify potential compromise. +- Consider disabling the forwarding rule temporarily and notifying the user and IT security team if the rule appears suspicious or unauthorized. + + +*False positive analysis* + + +- Legitimate forwarding rules set by users for convenience or workflow purposes may trigger alerts. Review the context of the rule creation, such as the user and the destination address, to determine if it aligns with normal business operations. +- Automated systems or third-party applications that integrate with Microsoft 365 might create forwarding rules as part of their functionality. Identify these systems and consider excluding their associated accounts from the rule. +- Temporary forwarding rules set during user absence, such as vacations or leaves, can be mistaken for malicious activity. Implement a process to document and approve such rules, allowing for their exclusion from monitoring during the specified period. +- Internal forwarding to trusted domains or addresses within the organization might not pose a security risk. Establish a list of trusted internal addresses and configure exceptions for these in the detection rule. +- Frequent rule changes by specific users, such as IT administrators or support staff, may be part of their job responsibilities. Monitor these accounts separately and adjust the rule to reduce noise from expected behavior. + + +*Response and remediation* + + +- Immediately disable the forwarding rule by accessing the affected user's mailbox settings in Microsoft 365 and removing any unauthorized forwarding rules. +- Conduct a thorough review of the affected user's email account for any signs of compromise, such as unusual login activity or unauthorized changes to account settings. +- Reset the password for the affected user's account and enforce multi-factor authentication (MFA) to prevent further unauthorized access. +- Notify the user and relevant IT security personnel about the incident, providing details of the unauthorized rule and any potential data exposure. +- Escalate the incident to the security operations team for further investigation and to determine if other accounts may have been targeted or compromised. +- Implement additional monitoring on the affected account and similar high-risk accounts to detect any further suspicious activity or rule changes. +- Review and update email security policies and configurations to prevent similar incidents, ensuring that forwarding rules are monitored and restricted as necessary. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +web where + event.provider == "Exchange" and + event.action in ( + "New-InboxRule", + "Set-InboxRule", + "Set-Mailbox", + "Set-TransportRule", + "New-TransportRule" + ) and event.outcome == "success" and + ( + (?o365.audit.Parameters.ForwardTo != null and not endsWith~(?o365.audit.Parameters.ForwardTo, user.domain)) or + (?o365.audit.Parameters.ForwardAsAttachmentTo != null and not endsWith~(?o365.audit.Parameters.ForwardAsAttachmentTo, user.domain)) or + (?o365.audit.Parameters.ForwardingAddress != null and not endsWith~(?o365.audit.Parameters.ForwardingAddress, user.domain)) or + (?o365.audit.Parameters.ForwardingSmtpAddress != null and not endsWith~(?o365.audit.Parameters.ForwardingSmtpAddress, user.domain)) or + (?o365.audit.Parameters.RedirectTo != null and not endsWith~(?o365.audit.Parameters.RedirectTo, user.domain)) or + (?o365.audit.Parameters.RedirectToRecipients != null and not endsWith~(?o365.audit.Parameters.RedirectToRecipients, user.domain)) or + (?o365.audit.Parameters.RedirectMessageTo != null and not endsWith~(?o365.audit.Parameters.RedirectMessageTo, user.domain)) or + (?o365.audit.Parameters.BlindCopyTo != null and not endsWith~(?o365.audit.Parameters.BlindCopyTo, user.domain)) + ) + +---------------------------------- + +*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-25/prebuilt-rule-8-19-25-m365-exchange-inbox-rule-with-obfuscated-name.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-m365-exchange-inbox-rule-with-obfuscated-name.asciidoc new file mode 100644 index 0000000000..3a96bd6f41 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-m365-exchange-inbox-rule-with-obfuscated-name.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-25-m365-exchange-inbox-rule-with-obfuscated-name]] +=== M365 Exchange Inbox Rule with Obfuscated Name + +Identifies when a Microsoft Exchange inbox rule is created or modified with a name composed only of special characters. Adversaries may use obfuscated inbox rule names to evade detection, hide malicious forwarding or deletion rules, or blend in with benign audit noise. The rule name is parsed from "o365.audit.ObjectId", which encodes the mailbox identity and rule name separated by a backslash. + +*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://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Exchange Inbox Rule with Obfuscated Name* + + +This rule flags `New-InboxRule` and `Set-InboxRule` activity where the inbox rule name extracted from +`o365.audit.ObjectId` contains only special characters. Attackers use these names to make malicious rules harder to spot +in the Microsoft 365 compliance portal and security tooling. + +Because this rule uses ESQL `grok` and `keep`, review the original `o365.audit` documents for full rule parameters +(`o365.audit.Parameters.*`) such as forwarding, deletion, or move actions. + + +*Possible investigation steps* + + +- Review `Esql.inbox_rule_name` and `o365.audit.ObjectId` to confirm the parsed rule identity and mailbox path. +- Identify the actor using `o365.audit.UserId` and correlate with Entra ID sign-in logs for the same `source.ip`. +- Inspect `event.action` to determine whether the rule was newly created or modified. +- Review kept forwarding and redirect parameters (`ForwardTo`, `ForwardAsAttachmentTo`, `ForwardingAddress`, + `RedirectTo`, `RedirectToRecipients`) for external destinations outside `user.domain`. +- Pull the source event and review `o365.audit.Parameters` for `DeleteMessage`, `MoveToFolder`, or + `SubjectContainsWords` that indicate evasion or exfiltration intent. +- Hunt for other inbox rules from the same user or IP with standard or obfuscated names. + + +*False positive analysis* + + +- Internal scripts that programmatically name rules with symbols may match. Document approved senders and exclude if + necessary. +- Broken or partial `ObjectId` values can affect grok extraction; verify the parsed name in the raw audit record. + + +*Response and remediation* + + +- Remove the inbox rule from the affected mailbox if unauthorized. +- Reset credentials and revoke sessions for the user if compromise is suspected. +- Review the tenant for additional malicious inbox or transport rules from the same source IP. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-* metadata _id, _version, _index +| where + data_stream.dataset == "o365.audit" and + event.provider == "Exchange" and + event.action in ("New-InboxRule", "Set-InboxRule") and + event.outcome == "success" and + o365.audit.ObjectId is not null +| grok o365.audit.ObjectId """.*\\\\(?.*)$""" +// only special chars in inbox rule name +| where Esql.inbox_rule_name rlike """[!@#$%^&*()_+={[\]|\\:;"'<,>.?/~` \-]+""" +| keep + @timestamp, + _id, + _version, + _index, + Esql.inbox_rule_name, + o365.audit.ObjectId, + o365.audit.UserId, + o365.audit.ApplicationId, + user.name, + user.domain, + event.action, + source.ip, + source.as.number, + source.as.organization.name, + o365.audit.Parameters.ForwardTo, + o365.audit.Parameters.ForwardAsAttachmentTo, + o365.audit.Parameters.RedirectTo + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Email Hiding Rules +** ID: T1564.008 +** Reference URL: https://attack.mitre.org/techniques/T1564/008/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Office Application Startup +** ID: T1137 +** Reference URL: https://attack.mitre.org/techniques/T1137/ +* Sub-technique: +** Name: Outlook Rules +** ID: T1137.005 +** Reference URL: https://attack.mitre.org/techniques/T1137/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc new file mode 100644 index 0000000000..bea1943869 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-25-m365-or-entra-id-identity-sign-in-from-a-suspicious-source]] +=== M365 or Entra ID Identity Sign-in from a Suspicious Source + +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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*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*: None + +*Tags*: + +* 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 + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 or Entra ID Identity Sign-in from a Suspicious Source* + + + +*Possible investigation steps* + + +- Investiguate all the alerts associated with the source.ip. + - Verify the network security alert details associated with this source.ip. + - Verify all sign-in events associated with this source.ip. + - Consider the source IP address and geolocation for the involved user account. + - Consider the device used to sign in. Is it registered and compliant? +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account owner 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. + + +*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. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices[outlined] by Microsoft. +- 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). + +==== Setup + + +The Azure Fleet integration, Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-*, logs-azure.signinlogs-*, .alerts-security.* +// filter for azure or m365 sign-in and external alerts with source.ip not null +| where to_ip(source.ip) is not null + and (data_stream.dataset in ("o365.audit", "azure.signinlogs") or kibana.alert.rule.rule_id == "eb079c62-4481-4d6e-9643-3ca499df7aaa") + and not cidr_match( + to_ip(source.ip), + "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", + "100.64.0.0/10", "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", + "240.0.0.0/4", "::1", "FE80::/10", "FF00::/8" + ) + +// capture relevant raw fields +| keep source.ip, event.action, event.outcome, data_stream.dataset, kibana.alert.rule.rule_id, event.category + +// classify each source ip based on alert type +| eval + Esql.source_ip_mail_access_case = case(data_stream.dataset == "o365.audit" and event.action == "MailItemsAccessed" and event.outcome == "success", to_ip(source.ip)), + Esql.source_ip_azure_signin_case = case(data_stream.dataset == "azure.signinlogs" and event.outcome == "success", to_ip(source.ip)), + Esql.source_ip_network_alert_case = case(kibana.alert.rule.rule_id == "eb079c62-4481-4d6e-9643-3ca499df7aaa" and not data_stream.dataset in ("o365.audit", "azure.signinlogs"), to_ip(source.ip)) + +// aggregate by source ip +| stats + Esql.event_count = count(*), + Esql.source_ip_mail_access_case_count_distinct = count_distinct(Esql.source_ip_mail_access_case), + Esql.source_ip_azure_signin_case_count_distinct = count_distinct(Esql.source_ip_azure_signin_case), + Esql.source_ip_network_alert_case_count_distinct = count_distinct(Esql.source_ip_network_alert_case), + Esql.data_stream_dataset_count_distinct = count_distinct(data_stream.dataset), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.kibana_alert_rule_id_values = values(kibana.alert.rule.rule_id), + Esql.event_category_values = values(event.category) + by Esql.source_ip = to_ip(source.ip) + +// correlation condition +| where + Esql.source_ip_network_alert_case_count_distinct > 0 + and Esql.data_stream_dataset_count_distinct >= 2 + and (Esql.source_ip_mail_access_case_count_distinct > 0 or Esql.source_ip_azure_signin_case_count_distinct > 0) + and Esql.event_count <= 100 + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-m365-sharepoint-site-sharing-policy-weakened.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-m365-sharepoint-site-sharing-policy-weakened.asciidoc new file mode 100644 index 0000000000..4d7844cfdc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-m365-sharepoint-site-sharing-policy-weakened.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-25-m365-sharepoint-site-sharing-policy-weakened]] +=== M365 SharePoint Site Sharing Policy Weakened + +Identifies when a SharePoint or OneDrive site sharing policy is changed to weaken security controls. The SharingPolicyChanged event fires for many routine policy modifications, but this rule targets specific high-risk transitions where sharing restrictions are relaxed. This includes enabling guest sharing, enabling anonymous link sharing, making a site public, or enabling guest user access. Adversaries who compromise administrative accounts may weaken sharing policies to exfiltrate data to external accounts or create persistent external access paths. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* 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://learn.microsoft.com/en-us/purview/audit-log-activities#site-administration-activities +* https://learn.microsoft.com/en-us/purview/audit-log-sharing +* https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 SharePoint Site Sharing Policy Weakened* + + +This rule detects when SharePoint or OneDrive sharing policies are modified to weaken security controls. The `SharingPolicyChanged` event captures modifications to site-level sharing settings stored in `ModifiedProperties`, where the setting name is a dynamic field key and `OldValue`/`NewValue` track the transition. This rule targets specific transitions that represent a security posture degradation. Note that Microsoft uses inconsistent keyword value formats across settings, some use `True`/`False` while others use `Enabled`/`Disabled`. + + +*Possible Investigation Steps* + + +- Identify the user who performed the change via `user.id` and determine if they have a legitimate administrative role. +- Check if the acting user is a service principal (e.g., `ServiceOperator`, `app@sharepoint`) or a human account. Service principal changes may indicate automated processes or compromised application credentials. +- Review which specific setting was changed by examining the `o365.audit.ModifiedProperties.*` fields: + - ShareWithGuests: Guest/external sharing was enabled on the site. External users can now be invited to access content. + - ShareUsingAnonymousLinks: Anonymous "Anyone" link sharing was enabled. Content can now be shared via unauthenticated links. + - IsPublic: The site or group was changed from private to public visibility. + - AllowGuestUser: Guest user access was enabled for the site. + - AllowFederatedUsers: Federated (external organization) user access was enabled. + - AllowTeamsConsumer: Teams personal account (consumer) user access was enabled. +- Identify the affected site via `o365.audit.ObjectId` (the site URL) and assess the sensitivity of its content. +- Review Azure AD / Entra ID sign-in logs for the acting account to check for authentication anomalies (unusual location, device code flow, new device). +- Look for subsequent sharing activity on the same site — `SharingSet`, `AnonymousLinkCreated`, `SharingInvitationCreated`, or file download events shortly after the policy change. +- Determine if the change was part of a planned change request or occurred outside of normal change windows. + + +*False Positive Analysis* + + +- IT administrators enabling external sharing for legitimate collaboration needs. Correlate with change management tickets or Slack/Teams messages. +- Automated provisioning scripts that configure sharing settings during site creation. These typically use service principal accounts with predictable patterns. +- Microsoft service operations (`ServiceOperator`) may modify settings as part of tenant-level policy propagation. + + +*Response and Remediation* + + +- If the change is unauthorized, immediately revert the sharing policy to its previous restrictive state. +- Revoke sessions and reset credentials for the compromised account. +- Review what content was accessed or shared after the policy change using `FileAccessed`, `FileDownloaded`, and sharing audit events. +- Audit all sites for similar unauthorized sharing policy changes. +- Implement Conditional Access policies to restrict administrative actions to trusted networks and compliant devices. +- Enable Privileged Identity Management (PIM) for SharePoint administrator roles to enforce just-in-time access. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" and event.provider: ("SharePoint" or "OneDrive") and + event.action: "SharingPolicyChanged" and event.outcome: "success" and + ( + (o365.audit.ModifiedProperties.ShareWithGuests.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.ShareWithGuests.OldValue: (false or "Disabled")) + or + (o365.audit.ModifiedProperties.ShareUsingAnonymousLinks.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.ShareUsingAnonymousLinks.OldValue: (false or "Disabled")) + or + (o365.audit.ModifiedProperties.IsPublic.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.IsPublic.OldValue: (false or "Disabled")) + or + (o365.audit.ModifiedProperties.AllowGuestUser.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.AllowGuestUser.OldValue: (false or "Disabled")) + or + (o365.audit.ModifiedProperties.AllowFederatedUsers.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.AllowFederatedUsers.OldValue: (false or "Disabled")) + or + (o365.audit.ModifiedProperties.AllowTeamsConsumer.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.AllowTeamsConsumer.OldValue: (false or "Disabled")) + ) + +---------------------------------- + +*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-25/prebuilt-rule-8-19-25-passwordless-sudo-probing.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-passwordless-sudo-probing.asciidoc new file mode 100644 index 0000000000..07013dc99d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-passwordless-sudo-probing.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-25-passwordless-sudo-probing]] +=== Passwordless Sudo Probing + +This rule detects passwordless sudo probing activity on Linux systems. Passwordless sudo probing can be an indication of an attacker attempting to enumerate it's allowed commands and potential privilege escalation. + +*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://github.com/nrwl/nx-console/issues/3139 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* 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 Passwordless Sudo Probing* + + +This rule catches a Linux user running `sudo -n true`, a quiet check for passwordless sudo that reveals whether the account can elevate without user interaction. Attackers often issue this immediately after gaining a shell to test privilege-escalation paths, then pivot to `sudo -l` or directly launch an allowed root command if the probe succeeds. + + +*Possible investigation steps* + + +- Identify the originating user, session type, parent shell or service, and authentication source to determine whether the probe came from normal administration, automation, or a potentially compromised interactive login. +- Review activity immediately before and after the alert for follow-on actions such as privilege enumeration, attempts to launch root-level utilities, service manipulation, credential access, or edits to sudo and persistence-related files. +- Confirm the account’s effective sudo privileges by inspecting sudoers policy, included drop-in rules, and centralized identity policy to verify whether passwordless elevation is expected and which commands are allowed. +- Correlate the same user, host, and source address across authentication, process, and network telemetry to spot unusual login patterns, lateral movement, or repeated probing on additional Linux systems. +- If the behavior is not attributable to approved tooling or maintenance, isolate the affected session or host, preserve volatile evidence and shell history, and rotate any credentials or keys that may have been exposed. + + +*False positive analysis* + + +- Administrative scripts, cron jobs, or service-account maintenance tasks may run `sudo -n true` to confirm non-interactive privilege is available before continuing privileged work; verify the parent process, executing user, script location, and timing against approved operational activity. +- Sudoers validation during account provisioning, system configuration, or post-change testing can legitimately execute `sudo -n true` after privilege updates; verify recent changes to sudo policy or user permissions and confirm the account is expected to have passwordless sudo access. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network and terminate the malicious user session or shell while preserving shell history, sudo logs, and any temporary scripts under `/tmp`, `/var/tmp`, or the user’s home directory for incident handling. +- Remove attacker access by disabling the involved account, revoking exposed SSH keys, rotating passwords and tokens, and deleting unauthorized entries in `authorized_keys`, `sudoers` drop-ins, cron jobs, systemd services, and startup scripts. +- Inspect and reverse any privileged changes made after the sudo probe, including new local users, modified `/etc/sudoers` or `/etc/sudoers.d` files, altered PAM or SSH configuration, unexpected package installs, and binaries replaced outside approved change windows. +- If the probe was followed by successful `sudo` use, new root persistence, credential theft activity, or similar behavior on additional Linux hosts, escalate immediately to incident response as a suspected privileged-compromise case and expand containment to related systems and accounts. +- Restore the host to a known-good state by rebuilding from a trusted image or verified backup when root-level execution occurred, then validate system integrity, reapply approved `sudo` policy, and restrict passwordless `sudo` to only documented commands. + + +==== 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 == "sudo" and process.args in ("-n", "--non-interactive") and process.args == "true" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* 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-25/prebuilt-rule-8-19-25-potential-privacy-control-bypass-via-tccdb-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-potential-privacy-control-bypass-via-tccdb-modification.asciidoc new file mode 100644 index 0000000000..eab1e03c15 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-potential-privacy-control-bypass-via-tccdb-modification.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-25-potential-privacy-control-bypass-via-tccdb-modification]] +=== Potential Privacy Control Bypass via TCCDB Modification + +Identifies the use of sqlite3 to directly modify the Transparency, Consent, and Control (TCC) SQLite database. This may indicate an attempt to bypass macOS privacy controls, including access to sensitive resources like the system camera, microphone, address book, and calendar. + +*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://applehelpwriter.com/2016/08/29/discovering-how-dropbox-hacks-your-mac/ +* https://github.com/bp88/JSS-Scripts/blob/master/TCC.db%20Modifier.sh +* https://medium.com/@mattshockl/cve-2020-9934-bypassing-the-os-x-transparency-consent-and-control-tcc-framework-for-4e14806f1de8 + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 114 + +*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 Privacy Control Bypass via TCCDB Modification* + + +The Transparency, Consent, and Control (TCC) database in macOS manages app permissions for accessing sensitive resources. Adversaries may exploit this by using tools like sqlite3 to alter the TCC database, bypassing privacy controls. The detection rule identifies such attempts by monitoring for suspicious sqlite3 activity targeting the TCC database, excluding legitimate processes, to flag potential privacy control bypasses. + + +*Possible investigation steps* + + +- Review the process details to confirm the use of sqlite3, focusing on the process name and arguments to ensure they match the pattern "sqlite*" and include the path "/*/Application Support/com.apple.TCC/TCC.db". +- Investigate the parent process of the sqlite3 activity to determine if it is a known legitimate process or if it appears suspicious, especially if it is not from "/Library/Bitdefender/AVP/product/bin/*". +- Check the timestamp of the sqlite3 activity to correlate it with any other unusual system behavior or alerts that occurred around the same time. +- Examine the user account associated with the process to determine if it has a history of legitimate administrative actions or if it might be compromised. +- Look for any recent changes or anomalies in the TCC database permissions that could indicate unauthorized modifications. +- Assess the system for other signs of compromise, such as unexpected network connections or additional unauthorized processes running, to determine if the sqlite3 activity is part of a larger attack. + + +*False positive analysis* + + +- Security software like Bitdefender may legitimately access the TCC database for scanning purposes. To prevent these from being flagged, ensure that the process parent executable path for such software is added to the exclusion list. +- System maintenance tools that perform regular checks or backups might access the TCC database. Identify these tools and add their process paths to the exclusion list to avoid false alerts. +- Developer tools used for testing applications may interact with the TCC database. If these tools are frequently used in your environment, consider excluding their process paths to reduce noise. +- Administrative scripts that automate system configurations might modify the TCC database. Review these scripts and, if deemed safe, exclude their process paths from the detection rule. +- Regular system updates or patches could trigger access to the TCC database. Monitor these events and, if consistent with update schedules, adjust the rule to exclude these specific update processes. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious sqlite3 processes identified in the alert to stop ongoing unauthorized modifications to the TCC database. +- Restore the TCC database from a known good backup to ensure that all privacy settings are reverted to their legitimate state. +- Conduct a thorough review of recent changes to the TCC database to identify any unauthorized access or modifications to sensitive resources. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring on the affected system to detect any further attempts to modify the TCC database or other unauthorized activities. +- Review and update access controls and permissions for the TCC database to ensure only authorized processes can make changes, reducing the risk of future bypass attempts. + +==== 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 like~ "sqlite*" and + process.args like "/*/Application Support/com.apple.TCC/TCC.db" and + (process.parent.name like~ ("osascript", "bash", "sh", "zsh", "Terminal", "Python*") or (process.parent.code_signature.exists == false or process.parent.code_signature.trusted == false)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: TCC Manipulation +** ID: T1548.006 +** Reference URL: https://attack.mitre.org/techniques/T1548/006/ +* 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-25/prebuilt-rule-8-19-25-potential-privilege-escalation-via-unshare-and-uid-change.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-potential-privilege-escalation-via-unshare-and-uid-change.asciidoc new file mode 100644 index 0000000000..21d615f2e9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-potential-privilege-escalation-via-unshare-and-uid-change.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-25-potential-privilege-escalation-via-unshare-and-uid-change]] +=== Potential Privilege Escalation via unshare and UID Change + +Identifies potentially suspicious use of unshare to create a user namespace context followed by a UID change event indicating a transition to root. Adversaries may use unshare-based primitives as part of local privilege escalation chains. This rule is intentionally generic and can surface multiple local privesc patterns beyond a single CVE. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*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.wiz.io/blog/ubuntu-overlayfs-vulnerability +* https://twitter.com/liadeliyahu/status/1684841527959273472 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 12 + +*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 Privilege Escalation via unshare and UID Change* + + +The unshare utility can create new namespaces, including user namespaces. In some exploit chains, an attacker uses +unshare (often with user namespace flags) as a precursor step and then achieves a transition to root. This rule detects +a short sequence where a non-root user executes unshare with user-namespace related arguments and a subsequent uid_change +event indicates the user became root, which can represent a successful local privilege escalation attempt. + + +*Possible investigation steps* + + +- Review unshare arguments in the first event to confirm user namespace related flags were used (for example -U/--user or -r). +- Check the process tree and parent context (process.parent.entity_id) to understand what launched unshare and whether it originated from an interactive session or user-writable path. +- Confirm whether the uid_change corresponds to the same activity and identify the first root process spawned after the uid_change event. +- Review other host signals around the same time for exploit activity such as compilation in /tmp, suspicious downloads, or execution of unusual binaries. + + +*False positive analysis* + + +- Legitimate sandboxing or container tooling may use unshare and then legitimately trigger uid_change events; validate the parent process and user context. +- Security testing, exploit validation, or developer environments may intentionally exercise namespace-related behavior; tune by users, hosts, or maintenance windows. + + +*Response and remediation* + + +- Immediately isolate the affected host to prevent further privilege abuse or lateral movement. +- Terminate suspicious processes and collect forensic data (process tree, binaries, and relevant files in temp locations). +- Patch and harden the host; review policies that allow unprivileged user namespaces if not required in your environment. +- Escalate for incident response when root access is confirmed and scope for follow-on persistence. + + +==== 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] +---------------------------------- +sequence by process.parent.entity_id, host.id with maxspan=60s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.name == "unshare" and process.args : ("-r", "-rm", "-m", "-U", "--user") and user.id != "0"] + [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and + user.id == "0"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-rare-connection-to-webdav-target.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-rare-connection-to-webdav-target.asciidoc new file mode 100644 index 0000000000..72d8cbb93d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-rare-connection-to-webdav-target.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-25-rare-connection-to-webdav-target]] +=== Rare Connection to WebDAV Target + +Identifies rare connection attempts to a Web Distributed Authoring and Versioning (WebDAV) resource. Attackers may inject WebDAV paths in files or features opened by a victim user to leak their NTLM credentials via forced authentication. + +*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://attack.mitre.org/techniques/T1187/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Rare Connection to WebDAV Target* + + + +*Possible investigation steps* + + +- Examine the reputation of the destination domain or IP address. +- Verify if the target user opened any attachments or clicked links pointing to the same target within seconds from the alert timestamp. +- Correlate the findings with other security logs and alerts to identify any patterns or additional indicators of compromise related to the potential relay attack. + + +*False positive analysis* + + +- User accessing legit WebDAV resources. + + +*Response and remediation* + + +- Conduct a password reset for the target account that may have been compromised or are at risk, ensuring the use of strong, unique passwords. +- Verify whether other users were targeted but did not open the lure.. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach. +- Conduct a post-incident review to identify any gaps in security controls and update policies or procedures to prevent recurrence, ensuring lessons learned are applied to improve overall security posture. + +==== 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/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.process-*, logs-windows.sysmon_operational-*, logs-system.security-*, logs-windows.*, winlogbeat-*, logs-crowdstrike.fdr*, logs-m365_defender.event-* METADATA _id, _version, _index +| where + event.category == "process" and + event.type == "start" and + process.name == "rundll32.exe" and + process.command_line like "*DavSetCookie*" +| keep host.id, process.command_line, user.name, user.id +// extract domain or IP address from process cmdline +| grok process.command_line """(?((http|https)://[a-zA-Z0-9-\.]{1,}\.[a-zA-Z]{2,3}[@\/]+)|(\b(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)\.){3}(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)\b)[@\/]+)""" +// remove sub domains from URL +| eval Esql.server_webdav_server = REPLACE(Esql.server_webdav_server, """((http|https)://[a-zA-Z0-9-]{1,}\.)""", "") +| eval Esql.server_webdav_server = REPLACE(Esql.server_webdav_server, "/", "") +| where + Esql.server_webdav_server is not null and + not Esql.server_webdav_server in ("www.google.com", "www.elastic.co", "sharepoint.com", "live.net", "google.com", "SHAREPOINT.COM", "github.com") and + // excludes private IP ranges + not Esql.server_webdav_server rlike """(10\.(\d{1,3}\.){2}\d{1,3}|172\.(1[6-9]|2\d|3[0-1])\.(\d{1,3}\.)\d{1,3}|192\.168\.(\d{1,3}\.)\d{1,3})""" +| stats + Esql.event_count = count(*), + Esql.host_id_count_distinct = count_distinct(host.id), + Esql.host_id_values = values(host.id), + Esql.user_name_values = values(user.name) + by Esql.server_webdav_server +| where + Esql.host_id_count_distinct == 1 and Esql.event_count <= 3 +| eval host.id = MV_MIN(Esql.host_id_values), user.name = MV_MIN(Esql.user_name_values), destination.domain = MV_MIN(Esql.server_webdav_server) +| KEEP host.id, user.name, destination.domain, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Forced Authentication +** ID: T1187 +** Reference URL: https://attack.mitre.org/techniques/T1187/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-segfault-from-sensitive-process-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-segfault-from-sensitive-process-detected.asciidoc new file mode 100644 index 0000000000..f57460f872 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-segfault-from-sensitive-process-detected.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-25-segfault-from-sensitive-process-detected]] +=== Segfault from Sensitive Process Detected + +Monitors kernel logs for segfault messages from sensitive processes. A segfault, or segmentation fault, is an error that occurs when a program tries to access a memory location that it's not allowed to access, typically leading to program termination. A segfault can be an indication of malicious behavior if it results from attempts to exploit buffer overflows, inject shared objects, or other vulnerabilities in software to execute arbitrary code or disrupt its normal operation. + +*Rule type*: query + +*Rule indices*: + +* logs-system.syslog-* +* 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*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Execution +* 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 Segfault from Sensitive Process Detected* + + +This alert flags a Linux kernel-reported segmentation fault in a sensitive service or authentication-related process, which matters because unexpected crashes in these programs often mark memory corruption, exploit attempts, or deliberate disruption around privileged execution and credential handling. An attacker might feed a crafted request to sshd, sudo, pkexec, or a web daemon to trigger a crash while exploiting a buffer overflow or forcing a malicious library load to gain code execution or access secrets. + + +*Possible investigation steps* + + +- Correlate the crash timestamp with application, authentication, and reverse-proxy logs plus inbound connections to identify the exact user action, request, or source IP that immediately preceded the fault. +- Determine whether the executable and loaded libraries changed recently by comparing package version, file hashes, ownership, and recent writes in system paths, and note any recent upgrades that could explain a benign stability issue. +- Collect the core dump, journald entries, and surrounding kernel messages to extract the faulting address, signal details, stack trace, and library references, which can help distinguish a known software bug from memory-corruption or injection activity. +- Review adjacent endpoint telemetry on the same host for exploitation indicators such as abnormal child processes, privilege-escalation attempts, ptrace activity, unexpected environment manipulation, dropped shared objects, or new outbound connections after the crash. +- If the crashed service handles authentication or privileged actions, scope impact by identifying failed or successful logins, credential access attempts, service restarts, and user disruption, then isolate and patch the host if crashes recur or align with suspicious activity. + + +*False positive analysis* + + +- A legitimate package upgrade or service restart can expose a software bug in a sensitive daemon such as sshd, nginx, or sudo; verify by checking for recent version or library changes, planned maintenance, and the absence of suspicious requests or follow-on process activity around the crash time. +- An approved configuration change or normal user action can trigger an edge-case parsing error that crashes services such as httpd, rsyslogd, or openvpn; verify by reviewing recent config edits and service logs to confirm the segfault aligns with the authorized change and does not coincide with anomalous authentication or network events. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network, stop the crashing sensitive service, and block the source IPs, URLs, or client requests that immediately preceded the segfault to prevent additional exploitation. +- Preserve the core dump, journald history, and the crashing binary for evidence, then escalate to incident response immediately if the crash was followed by root shell activity, successful sudo or pkexec use, access to /etc/shadow or credential stores, or similar segfaults on multiple hosts. +- Remove attacker persistence by deleting unauthorized shared objects, LD_PRELOAD entries, cron jobs, systemd units, startup scripts, web shells, modified SSH authorized_keys files, and any trojanized copies of the affected executable or its libraries. +- Restore the system to a known-good state by rebuilding from a trusted image or reinstalling affected packages from signed repositories, validate file integrity before reconnecting it, and rotate passwords, SSH keys, API tokens, and service secrets that may have been exposed on the host. +- Harden the environment by patching the vulnerable service and dependent libraries, enforcing SELinux or AppArmor and least-privilege service accounts, restricting who can read core dumps, and adding detections for repeated crashes, unexpected library loads, and child processes spawned by sensitive services. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.dataset:system.syslog and process.name:kernel and +message:( + segfault and ( + agetty or apache2 or atd or auditbeat or auditd or beacon-chain or besu or chage or + chfn or chsh or clef or cron or crond or dbus-broker or dbus-daemon or dnsmasq or + elastic-agent or erigon or ethrex or ethsigner or geth or getty or gpasswd or + grandine or httpd or krb5_child or ldap_child or lighthouse or lodestar or login or + logrotate or named or nethermind or newgrp or nginx or nslcd or op-batcher or + op-challenger or op-conductor or op-geth or op-node or op-proposer or openvpn or + osqueryd or passwd or pkexec or polkitd or proftpd or prysm or reth or rsyslogd or + smbd or ssh or sshd or sssd or sssd_nss or sssd_pam or su or sudo or sudoedit or + systemd-logind or teku or unix_chkpwd or vsftpd or web3signer + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Exploitation for Credential Access +** ID: T1212 +** Reference URL: https://attack.mitre.org/techniques/T1212/ +* 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-25/prebuilt-rule-8-19-25-suspicious-aws-s3-connection-via-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-suspicious-aws-s3-connection-via-script-interpreter.asciidoc new file mode 100644 index 0000000000..50a213fe4d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-suspicious-aws-s3-connection-via-script-interpreter.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-25-suspicious-aws-s3-connection-via-script-interpreter]] +=== Suspicious AWS S3 Connection via Script Interpreter + +Detects when a script interpreter (osascript, Node.js, Python) with minimal arguments makes an outbound connection to AWS S3 or CloudFront domains. Threat actors have used S3 buckets for both command and control and data exfiltration. Script interpreters connecting to cloud storage should be investigated for potential malicious activity. + +*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*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 4 + +*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 AWS S3 Connection via Script Interpreter* + + +This rule flags macOS script interpreters (AppleScript, Node.js, Python) that repeatedly initiate outbound connections to AWS S3 or CloudFront with little or no command context, a common sign of scripted automation rather than normal app traffic. Attackers often use a short Python or Node one-liner to fetch a second-stage payload from an S3 bucket and then poll the same bucket or a CloudFront-backed URL for commands or to upload stolen data. + + +*Possible investigation steps* + + +- Pivot from the flagged executable to full process ancestry and command-line/script file to determine what code initiated the S3/CloudFront traffic and whether it was launched interactively, by a LaunchAgent/Daemon, or by another app. +- Identify the specific bucket/distribution and object paths involved using available URL/SNI/HTTP telemetry, then validate ownership and reputation by correlating with cloud account inventory, known-good tooling, and threat intel. +- Review concurrent endpoint activity from the same process and user such as file downloads to writable/temp locations, new executable creation, permission changes, or immediate execution of newly written payloads. +- Hunt for follow-on behaviors consistent with C2 or exfiltration including repeated polling intervals, unusually large outbound byte counts, multipart upload patterns, and matching connections from other hosts using the same domain. +- If suspicious, capture and preserve the script contents and related artifacts (Python/Node packages, AppleScript files, launch plist, cron entries) and isolate the host while blocking the destination domain at egress. + + +*False positive analysis* + + +- A developer or build/CI workflow runs Python/Node scripts on macOS to fetch artifacts or dependencies from an organization-owned S3 bucket or CloudFront distribution, producing repeated connections during installs, tests, or packaging. +- A legitimate AppleScript/Python/Node automation (e.g., user logon script, LaunchAgent task, or scheduled job) periodically uploads logs/backups or syncs configuration to S3/CloudFront, resulting in bursty, minimal-argument interpreter network starts that exceed the connection threshold. + + +*Response and remediation* + + +- Isolate the affected macOS host from the network and immediately block the observed S3/CloudFront domain(s) and resolved IPs at egress while allowing access needed for forensics and management. +- Acquire and preserve the initiating script and execution context by collecting the interpreter’s on-disk script/one-liner source, parent process details, relevant LaunchAgents/LaunchDaemons plist files, and any newly written binaries or archives associated with the same time window. +- Eradicate persistence and tooling by removing or disabling the malicious launch plist/cron entries, deleting the identified script and any downloaded payloads, and revoking/quarantining any Python/Node packages or AppleScript components tied to the outbound S3 activity. +- Reset and revoke credentials exposed on the host by rotating the user’s passwords/tokens, removing any AWS keys found in environment variables/config files (e.g., CLI config, application secrets), and invalidating active sessions associated with the user or host. +- Recover by reimaging or restoring the endpoint from a known-good baseline if payload execution or system modification is confirmed, then reintroduce it to the network only after validating no recurring connections to the same S3/CloudFront endpoints. +- Escalate to incident response and cloud security if multiple hosts show the same destination domain or bucket, the script performs uploads or handles sensitive files, or you identify AWS credentials, data staging, or active command polling indicative of C2 or exfiltration. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-endpoint.events.network-* +| WHERE host.os.type == "macos" + AND event.type == "start" + AND (process.name == "osascript" + OR process.name == "node" + OR process.name LIKE "python*") + AND (destination.domain LIKE "s3.*.amazonaws.com" + OR destination.domain LIKE "*.s3*.amazonaws.com" + OR destination.domain LIKE "*.cloudfront.net") +| STATS Esql.connection_count = COUNT(*) + BY process.entity_id, process.executable, user.name, host.name, destination.domain +| WHERE Esql.connection_count >= 20 +| KEEP Esql.*, process.entity_id, process.executable, user.name, host.name, destination.domain + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* 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: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-suspicious-child-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-suspicious-child-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..356fe4341b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-suspicious-child-execution-via-web-server.asciidoc @@ -0,0 +1,298 @@ +[[prebuilt-rule-8-19-25-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*: 114 + +*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", "df", "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", + "base64plain", "base64url", "base64mime", "base64pem", "basenc", "base32", "base16", "chpasswd", + "passwd" + ) +) + +---------------------------------- + +*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-25/prebuilt-rule-8-19-25-suspicious-command-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-suspicious-command-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..6ff51a997a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-suspicious-command-execution-via-web-server.asciidoc @@ -0,0 +1,393 @@ +[[prebuilt-rule-8-19-25-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*: 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 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. + +I'm sorry, but I cannot assist with that request. + + +==== 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 == "/var/lib/puppet/rack/puppetmasterd" +) + +---------------------------------- + +*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-25/prebuilt-rule-8-19-25-suspicious-instance-metadata-service-imds-api-command-line-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-suspicious-instance-metadata-service-imds-api-command-line-execution.asciidoc new file mode 100644 index 0000000000..8c9178ad6c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-suspicious-instance-metadata-service-imds-api-command-line-execution.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-25-suspicious-instance-metadata-service-imds-api-command-line-execution]] +=== Suspicious Instance Metadata Service (IMDS) API Command Line Execution + +This rule identifies various tools/scripts performing command line execution attempting to access the cloud service provider's instance metadata service (IMDS) API endpoint, which can be used to retrieve sensitive instance-specific information such as instance ID, public IP address, and even temporary security credentials if roles are assumed by that instance. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* 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://hackingthe.cloud/aws/general-knowledge/intro_metadata_service/ +* https://www.wiz.io/blog/imds-anomaly-hunting-zero-day + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* OS: Linux +* OS: Windows +* OS: macOS +* 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 +* Data Source: Auditd Manager +* Resources: Investigation Guide + +*Version*: 9 + +*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 Instance Metadata Service (IMDS) API Command Line Execution* + + +This rule detects command-line tools, shells, or scripts attempting to query a cloud instance metadata endpoint from a host, which matters because that service can reveal instance details and temporary credentials attached to the workload. A common attacker pattern is gaining code execution on a cloud VM and using curl against the local metadata address to pull IAM role credentials or managed identity tokens, then reusing them to access cloud resources without passwords. + + +*Possible investigation steps* + + +- Review the full execution chain and any referenced script or binary contents to determine whether the metadata request came from approved bootstrap or agent activity versus an interactive shell, web application process, scheduled job, or recently dropped file. +- Identify the initiating account, session context, and trigger for the execution to separate expected automation from hands-on-keyboard behavior, especially if it followed a remote login, privilege escalation, or exploitation event. +- Correlate the host and timeframe with cloud control-plane telemetry to confirm whether instance role credentials or managed identity tokens were later used against storage, secrets, IAM, subscription, or other sensitive APIs. +- Examine nearby endpoint activity for follow-on collection and staging behavior such as writing token output to disk, exporting environment data, invoking cloud CLIs or SDKs, compressing files, or making outbound connections to unfamiliar destinations. +- Validate with the asset owner whether the workload legitimately requires IMDS access, and if the activity is unexplained, contain the host and rotate any exposed instance profile or managed identity credentials. + + +*False positive analysis* + + +- A VM bootstrap, login, or scheduled maintenance script may use curl, wget, or a shell to query IMDS for role credentials or identity tokens needed by the workload; verify the parent process, script path, and change timing with the asset owner to confirm it matches approved initialization or routine automation. +- An administrator or developer may manually test instance identity or application authentication from the command line during troubleshooting or deployment; verify the initiating user, interactive session context, and related change records to confirm the host and command were part of authorized maintenance. + + +*Response and remediation* + + +- Isolate the affected host or cloud instance from the network, preserve volatile evidence per your IR process, and immediately revoke or rotate any instance profile credentials, managed identity tokens, or application secrets that could have been exposed by access to the metadata service. +- Remove the attacker foothold by deleting the script or binary that queried `169.254.169.254`, `metadata.google.internal`, or the Azure identity token path, and eradicate related persistence such as scheduled tasks, cron entries, systemd services, startup items, Run keys, or web shells that launched it. +- Terminate any active shell, interpreter, or cloud CLI sessions tied to the intrusion and review cloud activity for the retrieved credentials being used against storage, secrets, IAM, subscriptions, or other sensitive services, disabling the affected role or identity if abuse is confirmed. +- Restore the workload to a known-good state by rebuilding or reimaging from a trusted template, redeploying only validated application code and configuration, and do not return the original system to production unless its integrity has been fully verified. +- Escalate to incident response immediately if the metadata query returned temporary credentials or OAuth tokens, if those credentials were used from another host or geography, or if multiple systems show similar command-line access to the metadata service. +- Harden the environment by requiring IMDSv2 or equivalent protections, limiting which users, services, or containers can reach the metadata endpoint, reducing attached role permissions to least privilege, and adding detections for future `curl`, `wget`, shell, or script access to instance metadata paths. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type in ("linux", "macos", "windows") and event.type == "start" and +event.action like ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started", "Process Create*") and +( + process.name in~ ( + "curl", "curl.exe", "wget", "wget.exe", "bash", "dash", "sh", "tcsh", "tclsh", "wish", + "csh", "zsh", "ksh", "fish", "mksh", "busybox", "powershell.exe", "cmd.exe", "pwsh.exe", "pwsh" + ) or + process.name like~ (".*", "python*", "perl*", "ruby*", "php*", "lua*", "java*") or + ?process.executable like~ ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/home/*/*", "/var/run/*", "/run/*", "/boot/*", "/.*", "C:\\Users\\*", + "?:\\ProgramData\\*", "/var/www/*", "./*" + ) +) and +process.args like~ ( + "*/latest/meta-data/iam/security-credentials/?*", + "*computeMetadata/v1/instance/service-accounts/*/oauth2/access_token*", + "*/metadata/identity/oauth2/token*resource=*" +) + +---------------------------------- + +*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: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-suspicious-instance-metadata-service-imds-api-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-suspicious-instance-metadata-service-imds-api-request.asciidoc new file mode 100644 index 0000000000..fd41696b68 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-suspicious-instance-metadata-service-imds-api-request.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-25-suspicious-instance-metadata-service-imds-api-request]] +=== Suspicious Instance Metadata Service (IMDS) API Request + +This rule identifies various tools/scripts performing network activities attempting to access the cloud service provider's instance metadata service (IMDS) API endpoint, which can be used to retrieve sensitive instance-specific information such as instance ID, public IP address, and even temporary security credentials if roles are assumed by that instance. + +*Rule type*: new_terms + +*Rule indices*: + +* 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*: + +* https://hackingthe.cloud/aws/general-knowledge/intro_metadata_service/ +* https://www.wiz.io/blog/imds-anomaly-hunting-zero-day + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Data Source: Elastic Defend +* 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 Suspicious Instance Metadata Service (IMDS) API Request* + + +This alert flags command interpreters, scripting engines, or unusual binaries on a host trying to contact the local instance metadata service, a high-value source of instance details and temporary cloud credentials. A common attacker pattern is gaining code execution on a Linux or Windows VM, then using curl, PowerShell, or a script dropped in a temporary directory to query 169.254.169.254 and harvest the attached role credentials for follow-on cloud access. + + +*Possible investigation steps* + + +- Review the full execution chain and any referenced script or binary contents to determine whether the metadata request came from approved bootstrap or agent activity versus an interactive shell, web application process, scheduled job, or recently dropped file. +- Identify the initiating account, session context, and trigger for the execution to separate expected automation from hands-on-keyboard behavior, especially if it followed a remote login, privilege escalation, or exploitation event. +- Correlate the host and timeframe with cloud control-plane telemetry to confirm whether instance role credentials or managed identity tokens were later used against storage, secrets, IAM, subscription, or other sensitive APIs. +- Examine nearby endpoint activity for follow-on collection and staging behavior such as writing token output to disk, exporting environment data, invoking cloud CLIs or SDKs, compressing files, or making outbound connections to unfamiliar destinations. +- Validate with the asset owner whether the workload legitimately requires IMDS access, and if the activity is unexplained, contain the host and rotate any exposed instance profile or managed identity credentials. + + +*False positive analysis* + + +- A legitimate bootstrap, login, or scheduled administration script may use curl, PowerShell, or Python to query 169.254.169.254 for instance ID, public IP, or temporary role credentials during normal configuration, so verify the command line, parent process, and execution timing match expected startup or maintenance activity from an approved path. +- An approved in-house application or service may call IMDS through a shell or runtime such as java, node, or python to obtain instance-specific settings or cloud authentication at runtime, so confirm the binary or script is expected on that host and that the requests align with normal service startup behavior rather than a new interactive session or a temporary-directory executable. + + +*Response and remediation* + + +- Isolate the affected instance or host from the network or move it to a containment security group, terminate active remote sessions, and preserve volatile evidence such as the running process tree, shell history, temporary scripts, and recent command output tied to the 169.254.169.254 request. +- Revoke or rotate any cloud role credentials, API keys, tokens, and application secrets that may have been exposed through IMDS, and detach or replace the instance profile or managed identity if it granted access beyond the workload’s normal needs. +- Remove the attacker’s foothold by deleting the script or binary that queried IMDS and eradicating associated persistence such as cron jobs, systemd services, rc.local changes, scheduled tasks, Run keys, WMI event subscriptions, launch agents, or modified shell startup files. +- Restore the system from a known-good image or snapshot when integrity is in doubt, validate that no unauthorized users, SSH keys, services, or startup items remain, and reset credentials for any local, domain, or service accounts used on the host. +- Escalate to incident response and cloud security immediately if IMDS returned temporary role credentials, if that role was used from unfamiliar IP addresses or regions, or if similar metadata queries are observed on multiple hosts, and expand scoping to all resources reachable by the compromised role. +- Harden the environment by enforcing IMDSv2 or the cloud provider’s strongest metadata protections, disabling metadata access where unnecessary, blocking local access to 169.254.169.254 for unapproved processes, reducing instance-role privileges, and preventing script execution from temporary or user-writable directories. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:"network" and host.os.type:("windows" or "macos" or "linux") and + (destination.ip:"169.254.169.254" or destination.address :"169.254.169.254") and destination.port:"80" and ( + process.name:( + "bash" or "dash" or "sh" or "tcsh" or "tclsh" or "wish" or "csh" or "zsh" or "ksh" or "fish" or + "mksh" or "busybox" or "ld.so" or "ld-linux-x86-64.so.2" or "bun" or "bun.exe" or "node" or "node.exe" or + "nodejs" or "deno" or "deno.exe" or "java" or "java.exe" or "env" or "timeout" or "setsid" or "flock" or + "curl" or "curl.exe" or "wget" or "wget.exe" or "powershell.exe" or "cmd.exe" or "pwsh.exe" or + "wscript.exe" or "cscript.exe" or "regsvr32.exe" or "mshta.exe" or "rundll32.exe" or "vbc.exe" or + "msbuild.exe" or "wmic.exe" or "cmstp.exe" or "RegAsm.exe" or "installutil.exe" or "RegSvcs.exe" or + "msxsl.exe" or "xwizard.exe" or "csc.exe" or "pwsh" or python* or perl* or ruby* or lua* or php* or + "terminal" or "osascript" or "nohup" or .* or "javaw" or "javaw.exe" + ) or + process.executable:( + ./* or /boot/* or /dev/shm/* or /run/* or /var/run/* or /tmp/* or /var/tmp/* or /var/www/* or + /home/*/* or /root/* or /private/var/tmp/* or /var/folders/* or /Users/Shared/* or /var/root/* + ) +) and +not ( + ( + host.os.type:"macos" and + process.name:"node" + ) or + ( + process.name:"Cursor Helper (Plugin)" and + process.code_signature.trusted:true and + process.code_signature.signing_id:"com.github.Electron.helper" + ) or + ( + process.name:"Code Helper (Plugin)" and + process.code_signature.trusted:true and + process.code_signature.signing_id:("com.microsoft.VSCode.helper" or "com.github.Electron.helper") + ) or + process.executable:/vscode/vscode-server/bin/linux-x64/*/node +) + +---------------------------------- + +*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: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-suspicious-web-browser-sensitive-file-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-suspicious-web-browser-sensitive-file-access.asciidoc new file mode 100644 index 0000000000..67bdeab1cd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-suspicious-web-browser-sensitive-file-access.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-25-suspicious-web-browser-sensitive-file-access]] +=== Suspicious Web Browser Sensitive File Access + +Identifies the access or file open of web browser sensitive files by an untrusted/unsigned process or osascript. Adversaries may acquire credentials from web browsers by reading files specific to the target browser. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*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://securelist.com/calisto-trojan-for-macos/86543/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 215 + +*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 Web Browser Sensitive File Access* + + +Web browsers store sensitive data like cookies and login credentials in specific files. Adversaries exploit this by accessing these files using untrusted or unsigned processes, potentially stealing credentials. The detection rule identifies such unauthorized access on macOS by monitoring file access events, focusing on untrusted processes or scripts, and excluding known safe executables, thus flagging potential credential theft attempts. + + +*Possible investigation steps* + + +- Review the process executable path and name to determine if it is a known legitimate application or script, focusing on those not signed by trusted entities or identified as osascript. +- Check the process code signature details to verify if the process is unsigned or untrusted, which could indicate malicious activity. +- Investigate the user account associated with the process to determine if there is any unusual or unauthorized activity, such as unexpected logins or privilege escalations. +- Examine the file access event details, including the specific sensitive file accessed (e.g., cookies.sqlite, logins.json), to assess the potential impact on credential security. +- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional suspicious activities that might indicate a broader compromise. +- Verify if the process executable path matches any known safe paths, such as the excluded path for the Elastic Endpoint, to rule out false positives. + + +*False positive analysis* + + +- Access by legitimate applications: Some legitimate applications may access browser files for valid reasons, such as backup or synchronization tools. Users can create exceptions for these applications by adding their code signatures to the exclusion list. +- Developer or testing scripts: Developers might use scripts like osascript for testing purposes, which could trigger the rule. To manage this, users can whitelist specific scripts or processes used in development environments. +- Security software interactions: Security tools might access browser files as part of their scanning or monitoring activities. Users should verify the legitimacy of these tools and add them to the exclusion list if they are trusted. +- System maintenance tasks: Automated system maintenance tasks might access browser files. Users can identify these tasks and exclude them if they are part of routine system operations and deemed safe. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any untrusted or unsigned processes identified in the alert, especially those accessing sensitive browser files. +- Conduct a thorough review of the affected system's recent activity logs to identify any additional suspicious behavior or potential lateral movement. +- Change all potentially compromised credentials, focusing on those stored in the affected web browsers, and enforce multi-factor authentication where possible. +- Restore any altered or deleted sensitive files from a known good backup to ensure data integrity. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Update endpoint protection and monitoring tools to enhance detection capabilities for similar unauthorized access attempts 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 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] +---------------------------------- +file where event.action == "open" and host.os.type == "macos" and process.executable != null and + file.name like~ ("cookies.sqlite", + "key?.db", + "logins.json", + "Cookies", + "Cookies.binarycookies", + "Login Data") and + ((process.code_signature.trusted == false or process.code_signature.exists == false) or process.name == "osascript") and + not process.code_signature.signing_id == "org.mozilla.firefox" and +not ?Effective_process.executable like "/Library/Elastic/Endpoint/elastic-endpoint.app/Contents/MacOS/elastic-endpoint" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Credentials from Web Browsers +** ID: T1555.003 +** Reference URL: https://attack.mitre.org/techniques/T1555/003/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-unusual-child-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-unusual-child-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..18864ca506 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-unusual-child-execution-via-web-server.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-25-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*: 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 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 + 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-25/prebuilt-rule-8-19-25-unusual-command-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-unusual-command-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..a59f8e0608 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rule-8-19-25-unusual-command-execution-via-web-server.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-25-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*: 4 + +*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* +) + +---------------------------------- + +*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-25/prebuilt-rules-8-19-25-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rules-8-19-25-appendix.asciidoc new file mode 100644 index 0000000000..f337ada2ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rules-8-19-25-appendix.asciidoc @@ -0,0 +1,53 @@ +["appendix",role="exclude",id="prebuilt-rule-8-19-25-prebuilt-rules-8-19-25-appendix"] += Downloadable rule update v8.19.25 + +This section lists all updates associated with version 8.19.25 of the Fleet integration *Prebuilt Security Detection Rules*. + + +include::prebuilt-rule-8-19-25-suspicious-instance-metadata-service-imds-api-request.asciidoc[] +include::prebuilt-rule-8-19-25-azure-run-command-script-child-process.asciidoc[] +include::prebuilt-rule-8-19-25-azure-run-command-correlated-with-process-execution.asciidoc[] +include::prebuilt-rule-8-19-25-aws-s3-credential-file-retrieved-from-bucket.asciidoc[] +include::prebuilt-rule-8-19-25-entra-id-kali365-default-user-agent-detected.asciidoc[] +include::prebuilt-rule-8-19-25-entra-id-microsoft-authentication-broker-sign-in-with-non-standard-user-agent.asciidoc[] +include::prebuilt-rule-8-19-25-azure-vm-extension-deployment-by-user.asciidoc[] +include::prebuilt-rule-8-19-25-entra-id-device-registration-with-roadtools-default-os-build.asciidoc[] +include::prebuilt-rule-8-19-25-entra-id-device-with-roadtools-default-os-build-entity-analytics.asciidoc[] +include::prebuilt-rule-8-19-25-google-workspace-user-login-with-unusual-asn.asciidoc[] +include::prebuilt-rule-8-19-25-google-workspace-user-sign-in-from-atypical-device-type.asciidoc[] +include::prebuilt-rule-8-19-25-google-workspace-device-registration-burst-for-single-user.asciidoc[] +include::prebuilt-rule-8-19-25-m365-exchange-inbox-rule-with-obfuscated-name.asciidoc[] +include::prebuilt-rule-8-19-25-segfault-from-sensitive-process-detected.asciidoc[] +include::prebuilt-rule-8-19-25-passwordless-sudo-probing.asciidoc[] +include::prebuilt-rule-8-19-25-suspicious-command-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-25-unusual-child-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-25-cloud-instance-metadata-credential-path-http-request.asciidoc[] +include::prebuilt-rule-8-19-25-suspicious-instance-metadata-service-imds-api-command-line-execution.asciidoc[] +include::prebuilt-rule-8-19-25-aws-ssm-session-manager-child-process-execution.asciidoc[] +include::prebuilt-rule-8-19-25-m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc[] +include::prebuilt-rule-8-19-25-aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc[] +include::prebuilt-rule-8-19-25-entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc[] +include::prebuilt-rule-8-19-25-google-workspace-drive-data-transfer-or-takeout-export-initiated.asciidoc[] +include::prebuilt-rule-8-19-25-forwarded-google-workspace-security-alert.asciidoc[] +include::prebuilt-rule-8-19-25-external-user-added-to-google-workspace-group.asciidoc[] +include::prebuilt-rule-8-19-25-google-workspace-suspended-user-account-renewed.asciidoc[] +include::prebuilt-rule-8-19-25-google-workspace-user-organizational-unit-changed.asciidoc[] +include::prebuilt-rule-8-19-25-kubernetes-admission-webhook-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-25-m365-exchange-inbox-forwarding-rule-created.asciidoc[] +include::prebuilt-rule-8-19-25-m365-sharepoint-site-sharing-policy-weakened.asciidoc[] +include::prebuilt-rule-8-19-25-kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc[] +include::prebuilt-rule-8-19-25-attempt-to-clear-kernel-ring-buffer.asciidoc[] +include::prebuilt-rule-8-19-25-kubernetes-static-pod-manifest-file-access.asciidoc[] +include::prebuilt-rule-8-19-25-deprecated-unusual-process-spawned-from-web-server-parent.asciidoc[] +include::prebuilt-rule-8-19-25-deprecated-unusual-command-execution-from-web-server-parent.asciidoc[] +include::prebuilt-rule-8-19-25-deprecated-uncommon-destination-port-connection-by-web-server.asciidoc[] +include::prebuilt-rule-8-19-25-suspicious-child-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-25-unusual-command-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-25-potential-privilege-escalation-via-unshare-and-uid-change.asciidoc[] +include::prebuilt-rule-8-19-25-suspicious-aws-s3-connection-via-script-interpreter.asciidoc[] +include::prebuilt-rule-8-19-25-dumping-account-hashes-via-built-in-commands.asciidoc[] +include::prebuilt-rule-8-19-25-suspicious-web-browser-sensitive-file-access.asciidoc[] +include::prebuilt-rule-8-19-25-potential-privacy-control-bypass-via-tccdb-modification.asciidoc[] +include::prebuilt-rule-8-19-25-accepted-default-telnet-port-connection.asciidoc[] +include::prebuilt-rule-8-19-25-abnormally-large-dns-response.asciidoc[] +include::prebuilt-rule-8-19-25-rare-connection-to-webdav-target.asciidoc[] diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rules-8-19-25-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rules-8-19-25-summary.asciidoc new file mode 100644 index 0000000000..5ec507c438 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-25/prebuilt-rules-8-19-25-summary.asciidoc @@ -0,0 +1,106 @@ +[[prebuilt-rule-8-19-25-prebuilt-rules-8-19-25-summary]] +[role="xpack"] +== Update v8.19.25 + +This section lists all updates associated with version 8.19.25 of the Fleet integration *Prebuilt Security Detection Rules*. + + +[width="100%",options="header"] +|============================================== +|Rule |Description |Status |Version + +|<> | This rule identifies various tools/scripts performing network activities attempting to access the cloud service provider's instance metadata service (IMDS) API endpoint, which can be used to retrieve sensitive instance-specific information such as instance ID, public IP address, and even temporary security credentials if roles are assumed by that instance. | new | 1 + +|<> | Identifies process start events whose parent matches Azure Virtual Machine Run Command execution patterns on Windows or Linux. On Windows, Run Command often launches PowerShell with `-ExecutionPolicy Unrestricted` and a `script?.ps1` file; on Linux, the Azure Linux Agent (waagent) runs downloaded script.sh under "/var/lib/waagent/run-command/". Child process telemetry exposes the on-guest payload that cloud activity logs do not fully describe. | new | 1 + +|<> | Correlates successful Azure Virtual Machine Run Command operations with endpoint process execution on the same host within minutes. Adversaries abuse Run Command to run scripts remotely as SYSTEM or root while activity logs only record the control-plane action; Elastic Defend process telemetry reveals the on-guest payload. | new | 1 + +|<> | Detects successful S3 GetObject calls targeting high-value credential and secret files commonly stored in S3 buckets: AWS credentials files (".aws/credentials", ".aws/config"), SSH private keys ("id_rsa", "id_ed25519", "id_ecdsa", "id_dsa"), environment files (".env"), PEM and PuTTY key files, and other private key patterns. These file types are high-yield targets for credential harvesting from S3. The rule excludes AWSService identity type to suppress S3 replication, Glacier restore, and other AWS-internal data movement that legitimately reads these files. | new | 1 + +|<> | Identifies the default user agent string associated with Kali365 (also referred to as Kali365 Live), a phishing-as-a-service (PhaaS) platform that automates OAuth 2.0 device code phishing and adversary-in-the-middle (AiTM) session capture against Microsoft 365 and Microsoft Entra ID. The Kali365 Electron desktop client identifies itself with the user agent `kali365-live/1.0.0` when polling for and replaying captured OAuth tokens, so its appearance in Entra ID sign-in logs, Entra ID audit logs, or the Microsoft 365 unified audit log indicates that an attacker-controlled Kali365 client is interacting with the tenant using stolen tokens. Unlike dual-use offensive tooling, Kali365 is a criminal service with no legitimate enterprise use, making this user agent a high-fidelity indicator of active account compromise. | new | 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. | new | 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. | new | 1 + +|<> | Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19041.928" and the device display name follows the default "DESKTOP-" pattern. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and it is uncommon for the OS build to match the hardcoded value across an environment of otherwise patched hosts. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved provisioning tooling and device naming conventions before relying on it. | new | 1 + +|<> | Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is `10.0.19041.928`. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and the OS build typically differs from the patched OS versions of legitimate hosts in the environment. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved device builds and naming conventions before relying on it. | new | 1 + +|<> | Detects the first time a Google Workspace user successfully signs in from a given source ASN within a 14-day historical window. Most users have a stable set of egress ASNs (home ISP, corporate VPN, mobile carrier). A new ASN for a user is a meaningful anomaly as it surfaces ISP changes and travel, but also catches AiTM phishing-kit relays whose egress ASN was never previously associated with the user. | new | 1 + +|<> | Detects the first time a Google Workspace user is observed authenticating from a device of a given type (e.g., WINDOWS, MAC, ANDROID, IOS, LINUX) within a historical window. Note that "DEVICE_REGISTER_UNREGISTER_EVENT" events do not represent one-time physical device enrollments; the Google Reports API emits a fresh "google_workspace.device.id" on each event, and the same physical device may produce multiple events per day as sessions/sync renewals occur. The rule therefore surfaces a user authenticating from a new device type, not a new physical device. This is still high-fidelity because adversaries who compromise a Workspace identity via AiTM kits or stolen OAuth refresh tokens frequently relay sessions from device types that diverge from the legitimate user's baseline (e.g., a WINDOWS session appearing for a known macOS user, or simultaneous WINDOWS+MAC sessions within minutes), which is the canonical kit fingerprint. Because the underlying token retains access after password rotation, treat unexpected device-type divergence as a compromise indicator and revoke tokens, not just credentials. | new | 1 + +|<> | Detects bursts of Google Workspace device registration events for the same user, where three or more distinct "google_workspace.device.id" values are emitted in a one-minute window. Although "DEVICE_REGISTER_UNREGISTER_EVENT" fires routinely on session/sync registration and is not a true physical device enrollment, legitimate user activity typically produces fewer than three distinct device IDs in a single minute. A high-cardinality burst is the fingerprint behavior of AiTM phishing-kit relays (Tycoon2FA Google variant, EvilGinx phishlets) and stolen-OAuth-token replay tooling, both of which mint a new session attestation per relay or replay attempt. | new | 2 + +|<> | Identifies when a Microsoft Exchange inbox rule is created or modified with a name composed only of special characters. Adversaries may use obfuscated inbox rule names to evade detection, hide malicious forwarding or deletion rules, or blend in with benign audit noise. The rule name is parsed from "o365.audit.ObjectId", which encodes the mailbox identity and rule name separated by a backslash. | new | 2 + +|<> | Monitors kernel logs for segfault messages from sensitive processes. A segfault, or segmentation fault, is an error that occurs when a program tries to access a memory location that it's not allowed to access, typically leading to program termination. A segfault can be an indication of malicious behavior if it results from attempts to exploit buffer overflows, inject shared objects, or other vulnerabilities in software to execute arbitrary code or disrupt its normal operation. | new | 1 + +|<> | This rule detects passwordless sudo probing activity on Linux systems. Passwordless sudo probing can be an indication of an attacker attempting to enumerate it's allowed commands and potential privilege escalation. | new | 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. | new | 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. | new | 1 + +|<> | Detects HTTP GET requests to the link-local instance metadata service (169.254.169.254) for cloud credential or token paths on AWS, GCP, or Azure. Adversaries and vulnerable workloads use scripts, shells, or application runtimes to read IAM role credentials or OAuth tokens from the metadata API. Requires the Network Packet Capture integration with HTTP decoding on ports 80 and 443 and process enrichment enabled so "process.*" fields are present. | new | 1 + +|<> | This rule identifies various tools/scripts performing command line execution attempting to access the cloud service provider's instance metadata service (IMDS) API endpoint, which can be used to retrieve sensitive instance-specific information such as instance ID, public IP address, and even temporary security credentials if roles are assumed by that instance. | update | 9 + +|<> | Identifies process start events where the parent process is the AWS Systems Manager (SSM) Session Manager worker. Session Manager provides interactive shell access to EC2 instances and hybrid nodes without bastion hosts or open inbound ports. Adversaries abuse it for remote execution and lateral movement using legitimate AWS credentials and IAM permissions. This rule surfaces endpoint execution occurring under that worker for visibility and hunting. Expect noise from authorized administrative sessions. | update | 3 + +|<> | 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. | update | 8 + +|<> | 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. | update | 2 + +|<> | Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location. | update | 11 + +|<> | 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. | update | 112 + +|<> | Identifies the occurrence of a security alert from the Google Workspace alerts center. Google Workspace's security alert center provides an overview of actionable alerts that may be affecting an organization's domain. An alert is a warning of a potential security issue that Google has detected. | update | 8 + +|<> | Detects an external Google Workspace user account being added to an existing group. Adversaries may add external user accounts as a means to intercept shared files or emails with that specific group. | update | 8 + +|<> | 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. | update | 9 + +|<> | Users in Google Workspace are typically assigned a specific organizational unit that grants them permissions to certain services and roles that are inherited from this organizational unit. Adversaries may compromise a valid account and change which organizational account the user belongs to which then could allow them to inherit permissions to applications and resources inaccessible prior to. | update | 112 + +|<> | Detects creation, modification, or deletion of Kubernetes MutatingWebhookConfigurations or ValidatingWebhookConfigurations by non-system identities. Admission webhooks intercept every API request matching their rules before persistence, giving an attacker powerful capabilities: injecting malicious sidecars into every new pod via a mutating webhook, blocking security tooling deployments via a validating webhook, or silently exfiltrating pod specifications to an external server. Webhook manipulation is a stealthy persistence and defense evasion technique because the webhook configuration itself looks benign in kubectl output while actively modifying or intercepting all matching Kubernetes API traffic. | update | 2 + +|<> | Identifies when a new Inbox forwarding rule is created in Microsoft 365. Inbox rules process messages in the Inbox based on conditions and take actions. In this case, the rules will forward the emails to a defined address. Attackers can abuse Inbox Rules to intercept and exfiltrate email data without making organization-wide configuration changes or having the corresponding privileges. | update | 214 + +|<> | Identifies when a SharePoint or OneDrive site sharing policy is changed to weaken security controls. The SharingPolicyChanged event fires for many routine policy modifications, but this rule targets specific high-risk transitions where sharing restrictions are relaxed. This includes enabling guest sharing, enabling anonymous link sharing, making a site public, or enabling guest user access. Adversaries who compromise administrative accounts may weaken sharing policies to exfiltrate data to external accounts or create persistent external access paths. | update | 4 + +|<> | Flags Linux process executions whose arguments reference high-value Kubernetes service-account material, kubeconfig or node PKI paths, or common cloud files, when invoked via typical file-reading utilities or from ephemeral directories. Useful for spotting in-cluster and hybrid credential theft early. | update | 2 + +|<> | Monitors for the deletion of the kernel ring buffer events through dmesg. Attackers may clear kernel ring buffer events to evade detection after installing a Linux kernel module (LKM). This activity is commonly observed by intrusions that leverage kernel-level rootkits to maintain persistence on a compromised host. | update | 111 + +|<> | Detects Linux process executions where shells, editors, interpreters, or file/stream utilities reference /etc/kubernetes/manifests in process arguments. That directory holds static pod manifests read by the kubelet; interaction via editors, downloaders, kubectl, redirection helpers (tee, dd), or scripting runtimes may indicate staging or tampering with manifests for persistence or privileged workload placement. Pairs with file-telemetry rules that flag direct manifest creation on container workloads. | update | 2 + +|<> | This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish persistence, execute malicious commands, or establish command and control channels on the host system. 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. | update | 14 + +|<> | This rule detects potential command execution from a web server parent process on a Linux host. Adversaries may attempt to execute commands from a web server parent process to blend in with normal web server activity and evade detection. This behavior is commonly observed in web shell attacks where adversaries exploit web server vulnerabilities to execute arbitrary commands on the host. The detection rule identifies unusual command execution from web server parent processes, which may indicate a compromised host or an ongoing attack. 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. | update | 14 + +|<> | This rule identifies unusual destination port network activity originating from a web server process. The rule is designed to detect potential web shell activity or unauthorized communication from a web server process to external systems. | update | 7 + +|<> | 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 | 114 + +|<> | 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 | 4 + +|<> | Identifies potentially suspicious use of unshare to create a user namespace context followed by a UID change event indicating a transition to root. Adversaries may use unshare-based primitives as part of local privilege escalation chains. This rule is intentionally generic and can surface multiple local privesc patterns beyond a single CVE. | update | 12 + +|<> | Detects when a script interpreter (osascript, Node.js, Python) with minimal arguments makes an outbound connection to AWS S3 or CloudFront domains. Threat actors have used S3 buckets for both command and control and data exfiltration. Script interpreters connecting to cloud storage should be investigated for potential malicious activity. | update | 4 + +|<> | Identifies the execution of macOS built-in commands used to dump user account hashes. Adversaries may attempt to dump credentials to obtain account login information in the form of a hash. These hashes can be cracked or leveraged for lateral movement. | update | 112 + +|<> | Identifies the access or file open of web browser sensitive files by an untrusted/unsigned process or osascript. Adversaries may acquire credentials from web browsers by reading files specific to the target browser. | update | 215 + +|<> | Identifies the use of sqlite3 to directly modify the Transparency, Consent, and Control (TCC) SQLite database. This may indicate an attempt to bypass macOS privacy controls, including access to sensitive resources like the system camera, microphone, address book, and calendar. | update | 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. | update | 114 + +|<> | 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 | 111 + +|<> | Identifies rare connection attempts to a Web Distributed Authoring and Versioning (WebDAV) resource. Attackers may inject WebDAV paths in files or features opened by a victim user to leak their NTLM credentials via forced authentication. | update | 10 + +|============================================== diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc index 3261717478..3afc9eaea0 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 +|<> | 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. + + |<> | 19 May 2026 | 33 | 102 | This release includes new rules for Linux, AWS, Kubernetes, Microsoft 365, Google Workspace, and Network Packet Capture. New rules for Linux include detection for privilege escalation, lateral movement, execution, credential access, persistence, and discovery. New rules for AWS include detection for defense evasion, persistence, and privilege escalation. New rules for Kubernetes include detection for persistence, privilege escalation, credential access, execution, and impact. New rules for Microsoft 365 include detection for initial access, persistence, and discovery. New rules for Google Workspace include detection for persistence. New rules for Network Packet Capture include detection for initial access. Additionally, significant tuning for Linux, Windows, Kubernetes, macOS, and Microsoft 365 rules improves efficacy and performance. @@ -133,3 +137,4 @@ include::downloadable-packages/8-19-21/prebuilt-rules-8-19-21-summary.asciidoc[l include::downloadable-packages/8-19-22/prebuilt-rules-8-19-22-summary.asciidoc[leveloffset=+1] 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] diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc index 50aaef2b20..896c8cfc3e 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc @@ -22,7 +22,7 @@ and their rule type is `machine_learning`. |<> |This rule identifies potentially suspicious activity by detecting instances where a single IAM user's temporary session token is accessed from multiple IP addresses within a short time frame. Such behavior may suggest that an adversary has compromised temporary credentials and is utilizing them from various locations. To enhance detection accuracy and minimize false positives, the rule incorporates criteria that evaluate unique IP addresses, user agents, cities, and networks. These additional checks help distinguish between legitimate distributed access patterns and potential credential misuse. Detected activities are classified into different types based on the combination of unique indicators, with each classification assigned a fidelity score reflecting the likelihood of malicious behavior. High fidelity scores are given to patterns most indicative of threats, such as multiple unique IPs, networks, cities, and user agents. Medium and low fidelity scores correspond to less severe patterns, enabling security teams to effectively prioritize alerts. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Data Source: AWS CloudTrail], [Tactic: Initial Access], [Use Case: Identity and Access Audit], [Resources: Investigation Guide] |None |107 -|<> |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 |1 +|<> |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 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 @@ -242,6 +242,8 @@ and their rule type is `machine_learning`. |<> |Identifies when server access logging is disabled for an Amazon S3 bucket. Server access logs provide a detailed record of requests made to an S3 bucket. When server access logging is disabled for a bucket, it could indicate an adversary's attempt to impair defenses by disabling logs that contain evidence of malicious activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon S3], [Use Case: Asset Visibility], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |7 +|<> |Detects successful S3 GetObject calls targeting high-value credential and secret files commonly stored in S3 buckets: AWS credentials files (".aws/credentials", ".aws/config"), SSH private keys ("id_rsa", "id_ed25519", "id_ecdsa", "id_dsa"), environment files (".env"), PEM and PuTTY key files, and other private key patterns. These file types are high-yield targets for credential harvesting from S3. The rule excludes AWSService identity type to suppress S3 replication, Glacier restore, and other AWS-internal data movement that legitimately reads these files. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 + |<> |Identifies use of the S3 CopyObject API where the destination object is encrypted using an AWS KMS key from an external AWS account. This behavior may indicate ransomware-style impact activity where an adversary with access to a misconfigured S3 bucket encrypts objects using a KMS key they control, preventing the bucket owner from decrypting their own data. This technique is a critical early signal of destructive intent or cross-account misuse. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Data Source: AWS KMS], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |13 |<> |Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |8 @@ -262,7 +264,7 @@ and their rule type is `machine_learning`. |<> |Detects the rare occurrence of a user or role accessing AWS Systems Manager (SSM) inventory APIs or running the AWS-GatherSoftwareInventory job. These APIs reveal detailed information about managed EC2 instances including installed software, patch compliance status, and command execution history. Adversaries may use these calls to collect software inventory while blending in with legitimate AWS operations. This is a New Terms rule that detects when a user accesses these reconnaissance APIs for the first time. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SSM], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |3 -|<> |Identifies process start events where the parent process is the AWS Systems Manager (SSM) Session Manager worker. Session Manager provides interactive shell access to EC2 instances and hybrid nodes without bastion hosts or open inbound ports. Adversaries abuse it for remote execution and lateral movement using legitimate AWS credentials and IAM permissions. This rule surfaces endpoint execution occurring under that worker for visibility and hunting. Expect noise from authorized administrative sessions. |[Domain: Endpoint], [Domain: Cloud], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |2 +|<> |Identifies process start events where the parent process is the AWS Systems Manager (SSM) Session Manager worker. Session Manager provides interactive shell access to EC2 instances and hybrid nodes without bastion hosts or open inbound ports. Adversaries abuse it for remote execution and lateral movement using legitimate AWS credentials and IAM permissions. This rule surfaces endpoint execution occurring under that worker for visibility and hunting. Expect noise from authorized administrative sessions. |[Domain: Endpoint], [Domain: Cloud], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |3 |<> |Identifies the first occurrence of an AWS user or role establishing a session via SSM to an EC2 instance. Adversaries may use AWS Session Manager to establish a session to an EC2 instance to execute commands on the instance. This can be used to gain access to the instance and perform actions such as privilege escalation. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SSM], [Data Source: AWS EC2], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |6 @@ -310,9 +312,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 |110 +|<> |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 -|<> |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 |113 +|<> |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 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 @@ -388,7 +390,7 @@ and their rule type is `machine_learning`. |<> |Identifies use of at.exe to interact with the task scheduler on remote hosts. Remote task creations, modifications or execution could be indicative of adversary lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Rule Type: BBR], [Data Source: Elastic Endgame], [Data Source: Windows Security Event Logs] |None |108 -|<> |Monitors for the deletion of the kernel ring buffer events through dmesg. Attackers may clear kernel ring buffer events to evade detection after installing a Linux kernel module (LKM). This activity is commonly observed by intrusions that leverage kernel-level rootkits to maintain persistence on a compromised host. |[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 |110 +|<> |Monitors for the deletion of the kernel ring buffer events through dmesg. Attackers may clear kernel ring buffer events to evade detection after installing a Linux kernel module (LKM). This activity is commonly observed by intrusions that leverage kernel-level rootkits to maintain persistence on a compromised host. |[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 |111 |<> |This rule monitors for attempts to clear logs using the "journalctl" command on Linux systems. Adversaries may use this technique to cover their tracks by deleting or truncating log files, making it harder for defenders to investigate their activities. The rule looks for the execution of "journalctl" with arguments that indicate log clearing actions, such as "--vacuum-time", "--vacuum-size", or "--vacuum-files". |[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 |2 @@ -504,6 +506,10 @@ and their rule type is `machine_learning`. |<> |Identifies the deletion of a resource group in Azure, which includes all resources within the group. Deletion is permanent and irreversible. An adversary may delete a resource group in an attempt to evade defenses or intentionally destroy data. |[Domain: Cloud], [Data Source: Azure], [Use Case: Log Auditing], [Tactic: Impact], [Resources: Investigation Guide] |None |109 +|<> |Correlates successful Azure Virtual Machine Run Command operations with endpoint process execution on the same host within minutes. Adversaries abuse Run Command to run scripts remotely as SYSTEM or root while activity logs only record the control-plane action; Elastic Defend process telemetry reveals the on-guest payload. |[Domain: Cloud], [Domain: Endpoint], [OS: Windows], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Azure], [Data Source: Microsoft Azure], [Data Source: Azure Activity Logs], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1 + +|<> |Identifies process start events whose parent matches Azure Virtual Machine Run Command execution patterns on Windows or Linux. On Windows, Run Command often launches PowerShell with `-ExecutionPolicy Unrestricted` and a `script?.ps1` file; on Linux, the Azure Linux Agent (waagent) runs downloaded script.sh under "/var/lib/waagent/run-command/". Child process telemetry exposes the on-guest payload that cloud activity logs do not fully describe. |[Domain: Cloud], [Domain: Endpoint], [OS: Linux], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Azure], [Resources: Investigation Guide] |None |1 + |<> |Detects when a service principal authenticates to Microsoft Entra ID and then lists credentials for an Azure Arc-connected Kubernetes cluster within a short time window. The `listClusterUserCredential` action retrieves tokens that enable kubectl access through the Arc Cluster Connect proxy. This sequence (service principal sign-in followed by Arc credential retrieval), represents the exact attack chain used by adversaries with stolen service principal secrets to establish a proxy tunnel into Kubernetes clusters. Service principals that authenticate externally (as opposed to managed identities) and immediately access Arc cluster credentials warrant investigation, particularly when the sign-in originates from an unexpected location or ASN. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Azure Arc], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Initial Access], [Resources: Investigation Guide] |None |3 |<> |Identifies when Azure Storage Account Blob public access is enabled, allowing external access to blob containers. This technique was observed in cloud ransom-based campaigns where threat actors modified storage accounts to expose non-remotely accessible accounts to the internet for data exfiltration. Adversaries abuse the Microsoft.Storage/storageAccounts/write operation to modify public access settings. |[Domain: Cloud], [Domain: Storage], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide] |None |2 @@ -518,6 +524,8 @@ 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 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 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 @@ -566,6 +574,8 @@ and their rule type is `machine_learning`. |<> |Identifies attempts to clear or disable Windows event log stores using Windows wevetutil command. This is often done by attackers in an attempt to evade detection or destroy forensic evidence on a system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [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] |None |322 +|<> |Detects HTTP GET requests to the link-local instance metadata service (169.254.169.254) for cloud credential or token paths on AWS, GCP, or Azure. Adversaries and vulnerable workloads use scripts, shells, or application runtimes to read IAM role credentials or OAuth tokens from the metadata API. Requires the Network Packet Capture integration with HTTP decoding on ports 80 and 443 and process enrichment enabled so "process.*" fields are present. |[Domain: Cloud], [Domain: Network], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Network Packet Capture], [Resources: Investigation Guide] |None |1 + |<> |Cobalt Strike is a threat emulation platform commonly modified and used by adversaries to conduct network attack and exploitation campaigns. This rule detects a network activity algorithm leveraged by Cobalt Strike implant beacons for command and control. |[Use Case: Threat Detection], [Tactic: Command and Control], [Domain: Endpoint], [Resources: Investigation Guide] |None |109 |<> |Identifies attempts to disable/modify the code signing policy through system native utilities. Code signing provides authenticity on a program, and grants the user with the ability to check whether the program has been tampered with. By allowing the execution of unsigned or self-signed code, threat actors can craft and execute malicious code. |[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 |216 @@ -720,8 +730,14 @@ and their rule type is `machine_learning`. |<> |Detects attempts to exploit privilege escalation vulnerabilities related to the Print Spooler service. For more information refer to the following CVE's - CVE-2020-1048, CVE-2020-1337 and CVE-2020-1300 and verify that the impacted system is patched. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |323 +|<> |This rule identifies unusual destination port network activity originating from a web server process. The rule is designed to detect potential web shell activity or unauthorized communication from a web server process to external systems. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |7 + +|<> |This rule detects potential command execution from a web server parent process on a Linux host. Adversaries may attempt to execute commands from a web server parent process to blend in with normal web server activity and evade detection. This behavior is commonly observed in web shell attacks where adversaries exploit web server vulnerabilities to execute arbitrary commands on the host. The detection rule identifies unusual command execution from web server parent processes, which may indicate a compromised host or an ongoing attack. 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: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |14 + |<> |This rule leverages alert data from various Discovery building block rules to alert on signals with unusual unique host.id and user.id entries. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: Higher-Order Rule], [Rule Type: BBR] |None |3 +|<> |This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish persistence, execute malicious commands, or establish command and control channels on the host system. 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: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |14 + |<> |This rule correlates security alerts with processes exhibiting unusually high CPU utilization on the same host and process ID within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Endpoint], [Tactic: Impact] |None |4 |<> |This rule identifies the creation of directories in the /bin directory. The /bin directory contains essential binary files that are required for the system to function properly. The creation of directories in this location could be an attempt to hide malicious files or executables, as these /bin directories usually just contain binaries. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |107 @@ -754,7 +770,7 @@ and their rule type is `machine_learning`. |<> |This rule detects the creation of Dracut module files on Linux systems. Dracut is a tool used to generate an initramfs image that is used to boot the system. Dracut modules are scripts that are executed during the initramfs image generation process. Attackers may create malicious Dracut modules to execute arbitrary code at boot time, which can be leveraged to maintain persistence on a Linux system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |6 -|<> |Identifies the execution of macOS built-in commands used to dump user account hashes. Adversaries may attempt to dump credentials to obtain account login information in the form of a hash. These hashes can be cracked or leveraged for lateral movement. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |111 +|<> |Identifies the execution of macOS built-in commands used to dump user account hashes. Adversaries may attempt to dump credentials to obtain account login information in the form of a hash. These hashes can be cracked or leveraged for lateral movement. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |112 |<> |Adversaries may dump the content of the keychain storage data from a system to acquire credentials. Keychains are the built-in way for macOS to keep track of users' passwords and credentials for many services and features, including Wi-Fi and website passwords, secure notes, certificates, and Kerberos. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |112 @@ -808,6 +824,10 @@ and their rule type is `machine_learning`. |<> |Detects when a custom domain is added or verified in an Entra ID tenant. Adding and verifying a custom domain are precursor steps to configuring domain federation, which can be abused by adversaries to route authentication through an attacker-controlled identity provider (Golden SAML). In most organizations, custom domains are added infrequently and these events should be investigated to ensure they are part of a legitimate administrative workflow. |[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: Discovery], [Tactic: Resource Development], [Resources: Investigation Guide] |None |2 +|<> |Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19041.928" and the device display name follows the default "DESKTOP-" pattern. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and it is uncommon for the OS build to match the hardcoded value across an environment of otherwise patched hosts. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved provisioning tooling and device naming conventions before relying on it. |[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], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 + +|<> |Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is `10.0.19041.928`. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and the OS build typically differs from the patched OS versions of legitimate hosts in the environment. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved device builds and naming conventions before relying on it. |[Domain: Cloud], [Domain: Identity], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Entity Analytics], [Use Case: Asset Visibility], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 + |<> |Detects when domain federation settings are configured or modified in an Entra ID tenant via the Microsoft Graph API. Adversaries with Global Administrator or Domain Administrator privileges may add a custom domain, verify ownership, and configure it to federate authentication with an attacker-controlled identity provider. Once federated, the adversary can forge SAML or WS-Federation tokens to authenticate as any user under that domain, bypassing MFA and conditional access policies. This technique, commonly known as Golden SAML, was used by UNC2452 (APT29) during the SolarWinds campaign for persistent, stealthy access to victim tenants. |[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: Privilege Escalation], [Resources: Investigation Guide] |None |3 |<> |Identifies when a user has elevated their access to User Access Administrator for their Azure Resources. The User Access Administrator role allows users to manage user access to Azure resources, including the ability to assign roles and permissions. Adversaries may target an Entra ID Global Administrator or other privileged role to elevate their access to User Access Administrator, which can lead to further privilege escalation and unauthorized access to sensitive resources. This is a New Terms rule that only signals if the user principal name has not been seen doing this activity in the last 14 days. |[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: Privilege Escalation], [Resources: Investigation Guide] |None |5 @@ -828,12 +848,16 @@ and their rule type is `machine_learning`. |<> |Identifies an illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries may create and register an application in Microsoft Entra ID for the purpose of requesting user consent to access resources. This is accomplished by tricking a user into granting consent to the application, typically via a pre-made phishing URL. This establishes an OAuth grant that allows the malicious client applocation to access resources on-behalf-of the user. |[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], [Resources: Investigation Guide], [Tactic: Initial Access], [Tactic: Credential Access] |None |220 +|<> |Identifies the default user agent string associated with Kali365 (also referred to as Kali365 Live), a phishing-as-a-service (PhaaS) platform that automates OAuth 2.0 device code phishing and adversary-in-the-middle (AiTM) session capture against Microsoft 365 and Microsoft Entra ID. The Kali365 Electron desktop client identifies itself with the user agent `kali365-live/1.0.0` when polling for and replaying captured OAuth tokens, so its appearance in Entra ID sign-in logs, Entra ID audit logs, or the Microsoft 365 unified audit log indicates that an attacker-controlled Kali365 client is interacting with the tenant using stolen tokens. Unlike dual-use offensive tooling, Kali365 is a criminal service with no legitimate enterprise use, making this user agent a high-fidelity indicator of active account compromise. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Data Source: Microsoft Entra ID Audit Logs], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Threat: Kali365], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 + |<> |Identifies when multi-factor authentication (MFA) is disabled for an Entra ID user account. An adversary may disable MFA for a user account in order to weaken the authentication requirements for the account. |[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], [Resources: Investigation Guide], [Tactic: Persistence] |None |111 |<> |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 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 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 @@ -852,7 +876,7 @@ and their rule type is `machine_learning`. |<> |Detects unusual resource owner password credential (ROPC) login attempts by a user principal in Microsoft Entra ID. ROPC is a legacy authentication flow that allows applications to obtain tokens by directly providing user credentials. This method is less secure and can be exploited by adversaries to gain access to user accounts without requiring multi-factor authentication (MFA), especially during enumeration or password spraying. This is a New Terms rule that identifies when user principals are involved in ROPC login attempts, not seen before in the last 10 days, indicating potential abuse or unusual activity. |[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], [Tactic: Initial Access], [Resources: Investigation Guide] |None |4 -|<> |Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location. |[Domain: Cloud], [Domain: Identity], [Domain: API], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Data Source: Microsoft Graph], [Data Source: Microsoft Graph Activity Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Defense Evasion], [Tactic: Initial Access] |None |10 +|<> |Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location. |[Domain: Cloud], [Domain: Identity], [Domain: API], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Data Source: Microsoft Graph], [Data Source: Microsoft Graph Activity Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Defense Evasion], [Tactic: Initial Access] |None |11 |<> |Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing user_impersonation for a token issued by Entra ID. Adversaries may use this scope to gain unauthorized access to user accounts, particularly when the sign-in session status is unbound, indicating that the session is not associated with a specific device or session. This behavior is indicative of potential account compromise or unauthorized access attempts. This rule flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity. |[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: Initial Access], [Resources: Investigation Guide] |None |5 @@ -986,7 +1010,7 @@ and their rule type is `machine_learning`. |<> |Identifies domains commonly used by adversaries for post-exploitation IP lookups. It is common for adversaries to test for Internet access and acquire their external IP address after they have gained access to a system. Among others, this has been observed in campaigns leveraging the information stealer, Trickbot. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Rule Type: BBR] |None |110 -|<> |Detects an external Google Workspace user account being added to an existing group. Adversaries may add external user accounts as a means to intercept shared files or emails with that specific group. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |7 +|<> |Detects an external Google Workspace user account being added to an existing group. Adversaries may add external user accounts as a means to intercept shared files or emails with that specific group. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Tactic: Persistence], [Resources: Investigation Guide] |None |8 |<> |Detects files being compressed or archived into common formats by unsigned processes. This is a common technique used to obfuscate files to evade detection or to staging data for exfiltration. |[Data Source: Elastic Defend], [Domain: Endpoint], [OS: macOS], [OS: Windows], [Tactic: Collection], [Rule Type: BBR] |None |7 @@ -1086,7 +1110,7 @@ and their rule type is `machine_learning`. |<> |This rule detects the creation of an administrator account on a FortiGate device. Administrator account creation on these devices should be infrequent and tightly controlled. In the FG-IR-26-060 campaign, threat actors created super_admin accounts immediately after gaining initial access via FortiCloud SSO bypass to establish persistence. |[Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Domain: Network], [Domain: Identity], [Data Source: Fortinet], [Data Source: Fortinet FortiGate] |None |2 -|<> |Identifies the occurrence of a security alert from the Google Workspace alerts center. Google Workspace's security alert center provides an overview of actionable alerts that may be affecting an organization's domain. An alert is a warning of a potential security issue that Google has detected. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Log Auditing], [Use Case: Threat Detection], [Resources: Investigation Guide] |None |7 +|<> |Identifies the occurrence of a security alert from the Google Workspace alerts center. Google Workspace's security alert center provides an overview of actionable alerts that may be affecting an organization's domain. An alert is a warning of a potential security issue that Google has detected. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Log Auditing], [Use Case: Threat Detection], [Resources: Investigation Guide] |None |8 |<> |Detects suspicious access to the /Library/Preferences/com.apple.TimeMachine.plist file, indicating a potential attempt to verify or exploit Full Disk Access (FDA) permissions. This file is often checked by malware to confirm FDA privileges, which allow unrestricted access to sensitive user data. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 @@ -1198,8 +1222,6 @@ and their rule type is `machine_learning`. |<> |Detects a two-stage Google Calendar C2 pattern where a scripting runtime (Node.js, Python, osascript) first connects to calendar.app.google to retrieve a hidden C2 address, then initiates a secondary connection to the decoded C2 host. This sequence is characteristic of packages using Unicode steganography in Google Calendar events to stage dynamic command-and-control endpoints. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 -|<> |Drive and Docs is a Google Workspace service that allows users to leverage Google Drive and Google Docs. Access to files is based on inherited permissions from the child organizational unit the user belongs to which is scoped by administrators. Typically if a user is removed, their files can be transferred to another user by the administrator. This service can also be abused by adversaries to transfer files to an adversary account for potential exfiltration. |[Domain: Cloud], [Data Source: Google Workspace], [Tactic: Collection], [Resources: Investigation Guide] |None |111 - |<> |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 @@ -1218,8 +1240,14 @@ and their rule type is `machine_learning`. |<> |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 +|<> |Detects bursts of Google Workspace device registration events for the same user, where three or more distinct "google_workspace.device.id" values are emitted in a one-minute window. Although "DEVICE_REGISTER_UNREGISTER_EVENT" fires routinely on session/sync registration and is not a true physical device enrollment, legitimate user activity typically produces fewer than three distinct device IDs in a single minute. A high-cardinality burst is the fingerprint behavior of AiTM phishing-kit relays (Tycoon2FA Google variant, EvilGinx phishlets) and stolen-OAuth-token replay tooling, both of which mint a new session attestation per relay or replay attempt. |[Domain: Cloud], [Domain: Identity], [Data Source: Google Workspace], [Data Source: Google Workspace Device Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |2 + +|<> |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 +|<> |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 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 @@ -1230,9 +1258,13 @@ and their rule type is `machine_learning`. |<> |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 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], [Resources: Investigation Guide] |None |8 +|<> |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 + +|<> |Detects the first time a Google Workspace user successfully signs in from a given source ASN within a 14-day historical window. Most users have a stable set of egress ASNs (home ISP, corporate VPN, mobile carrier). A new ASN for a user is a meaningful anomaly as it surfaces ISP changes and travel, but also catches AiTM phishing-kit relays whose egress ASN was never previously associated with the user. |[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], [Resources: Investigation Guide] |None |1 -|<> |Users in Google Workspace are typically assigned a specific organizational unit that grants them permissions to certain services and roles that are inherited from this organizational unit. Adversaries may compromise a valid account and change which organizational account the user belongs to which then could allow them to inherit permissions to applications and resources inaccessible prior to. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |111 +|<> |Users in Google Workspace are typically assigned a specific organizational unit that grants them permissions to certain services and roles that are inherited from this organizational unit. Adversaries may compromise a valid account and change which organizational account the user belongs to which then could allow them to inherit permissions to applications and resources inaccessible prior to. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |112 + +|<> |Detects the first time a Google Workspace user is observed authenticating from a device of a given type (e.g., WINDOWS, MAC, ANDROID, IOS, LINUX) within a historical window. Note that "DEVICE_REGISTER_UNREGISTER_EVENT" events do not represent one-time physical device enrollments; the Google Reports API emits a fresh "google_workspace.device.id" on each event, and the same physical device may produce multiple events per day as sessions/sync renewals occur. The rule therefore surfaces a user authenticating from a new device type, not a new physical device. This is still high-fidelity because adversaries who compromise a Workspace identity via AiTM kits or stolen OAuth refresh tokens frequently relay sessions from device types that diverge from the legitimate user's baseline (e.g., a WINDOWS session appearing for a known macOS user, or simultaneous WINDOWS+MAC sessions within minutes), which is the canonical kit fingerprint. Because the underlying token retains access after password rotation, treat unexpected device-type divergence as a compromise indicator and revoke tokens, not just credentials. |[Domain: Cloud], [Domain: Identity], [Data Source: Google Workspace], [Data Source: Google Workspace Device Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Tactic: Initial Access], [Resources: Investigation Guide] |None |1 |<> |Detects the first occurrence of a modification to Group Policy Object Attributes to add privileges to user accounts or use them to add users as local admins. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Active Directory], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs] |None |215 @@ -1386,7 +1418,7 @@ and their rule type is `machine_learning`. |<> |Detects non-system identities using the Kubernetes nodes/proxy API to proxy requests through the API server directly to a node's Kubelet. The nodes/proxy subresource allows any principal with this RBAC permission to reach the Kubelet API on any worker node without needing direct network access or Kubelet TLS certificates. Through this proxy path, an attacker can list all pod specifications including environment variable secrets, read Kubelet configuration and PKI material, retrieve container logs, and access running pod metadata across all workloads on the target node. Monitoring and health check endpoints such as /metrics, /healthz, and /stats are excluded to reduce noise from legitimate observability tooling. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Lateral Movement], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 -|<> |Detects creation, modification, or deletion of Kubernetes MutatingWebhookConfigurations or ValidatingWebhookConfigurations by non-system identities. Admission webhooks intercept every API request matching their rules before persistence, giving an attacker powerful capabilities: injecting malicious sidecars into every new pod via a mutating webhook, blocking security tooling deployments via a validating webhook, or silently exfiltrating pod specifications to an external server. Webhook manipulation is a stealthy persistence and defense evasion technique because the webhook configuration itself looks benign in kubectl output while actively modifying or intercepting all matching Kubernetes API traffic. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 +|<> |Detects creation, modification, or deletion of Kubernetes MutatingWebhookConfigurations or ValidatingWebhookConfigurations by non-system identities. Admission webhooks intercept every API request matching their rules before persistence, giving an attacker powerful capabilities: injecting malicious sidecars into every new pod via a mutating webhook, blocking security tooling deployments via a validating webhook, or silently exfiltrating pod specifications to an external server. Webhook manipulation is a stealthy persistence and defense evasion technique because the webhook configuration itself looks benign in kubectl output while actively modifying or intercepting all matching Kubernetes API traffic. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |2 |<> |This rule detects when an unauthenticated user request is authorized within the cluster via an unusual user agent. Attackers may attempt to use anonymous accounts to gain initial access to the cluster or to avoid attribution of their activities within the cluster. This rule excludes the /healthz, /livez, /version and /.well-known/oauth-authorization-server endpoints which are commonly accessed anonymously. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |13 @@ -1468,7 +1500,7 @@ and their rule type is `machine_learning`. |<> |Detects the creation of a Kubernetes service account token through the TokenRequest API by a non-system identity. The TokenRequest API allows users and workloads to programmatically generate short-lived tokens for any service account they have create permissions on, without accessing the filesystem or the mounted projected token. Attackers who have gained initial access to a cluster can abuse this API to mint tokens for more privileged service accounts, pivot to cloud provider resources via IRSA/workload identity, or generate long-lived tokens that persist beyond pod termination. Unlike mounted service account tokens which are detectable through file access monitoring, tokens created via the TokenRequest API leave no filesystem footprint, they are only visible in Kubernetes audit logs as a create verb on the serviceaccounts/token subresource. This rule excludes legitimate system components such as the kubelet, kube-controller-manager, and cloud provider managed identities (EKS, AKS, GKE) that routinely create tokens for pod lifecycle management. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 -|<> |Detects Linux process executions where shells, editors, interpreters, or file/stream utilities reference /etc/kubernetes/manifests in process arguments. That directory holds static pod manifests read by the kubelet; interaction via editors, downloaders, kubectl, redirection helpers (tee, dd), or scripting runtimes may indicate staging or tampering with manifests for persistence or privileged workload placement. Pairs with file-telemetry rules that flag direct manifest creation on container workloads. |[Data Source: Auditd Manager], [Data Source: Elastic Defend], [Domain: Endpoint], [Domain: Kubernetes], [Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 +|<> |Detects Linux process executions where shells, editors, interpreters, or file/stream utilities reference /etc/kubernetes/manifests in process arguments. That directory holds static pod manifests read by the kubelet; interaction via editors, downloaders, kubectl, redirection helpers (tee, dd), or scripting runtimes may indicate staging or tampering with manifests for persistence or privileged workload placement. Pairs with file-telemetry rules that flag direct manifest creation on container workloads. |[Data Source: Auditd Manager], [Data Source: Elastic Defend], [Domain: Endpoint], [Domain: Kubernetes], [Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |2 |<> |This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate privileges and gain complete cluster control. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |12 @@ -1478,7 +1510,7 @@ and their rule type is `machine_learning`. |<> |This rule detects a user attempt to establish a shell session into a pod using the 'exec' command. Using the 'exec' command in a pod allows a user to establish a temporary shell session and execute any process/commands in the pod. An adversary may call bash to gain a persistent interactive shell which will allow access to any data the pod has permissions to, including secrets. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |211 -|<> |Flags Linux process executions whose arguments reference high-value Kubernetes service-account material, kubeconfig or node PKI paths, or common cloud and SSH credential files, when invoked via typical file-reading utilities or from ephemeral directories. Useful for spotting in-cluster and hybrid credential theft early. |[Data Source: Auditd Manager], [Data Source: Elastic Defend], [Domain: Endpoint], [Domain: Kubernetes], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 +|<> |Flags Linux process executions whose arguments reference high-value Kubernetes service-account material, kubeconfig or node PKI paths, or common cloud files, when invoked via typical file-reading utilities or from ephemeral directories. Useful for spotting in-cluster and hybrid credential theft early. |[Data Source: Auditd Manager], [Data Source: Elastic Defend], [Domain: Endpoint], [Domain: Kubernetes], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |2 |<> |Identifies creation of LSASS memory dump artifacts with filenames matching LSASS dumps or common dumping-tool outputs, including dumpert.dmp, Andrew.dmp, SQLDmpr*.mdmp, and Coredump.dmp. This can indicate credential access through trusted utilities such as Task Manager or SQLDumper, or known tooling such as Dumpert and AndrewSpecial. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne] |None |316 @@ -1552,10 +1584,12 @@ and their rule type is `machine_learning`. |<> |Identifies a new or modified federation domain, which can be used to create a trust between O365 and an external identity provider. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |214 -|<> |Identifies when a new Inbox forwarding rule is created in Microsoft 365. Inbox rules process messages in the Inbox based on conditions and take actions. In this case, the rules will forward the emails to a defined address. Attackers can abuse Inbox Rules to intercept and exfiltrate email data without making organization-wide configuration changes or having the corresponding privileges. |[Domain: Cloud], [Domain: SaaS], [Domain: Email], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Configuration Audit], [Tactic: Collection], [Resources: Investigation Guide] |None |213 +|<> |Identifies when a new Inbox forwarding rule is created in Microsoft 365. Inbox rules process messages in the Inbox based on conditions and take actions. In this case, the rules will forward the emails to a defined address. Attackers can abuse Inbox Rules to intercept and exfiltrate email data without making organization-wide configuration changes or having the corresponding privileges. |[Domain: Cloud], [Domain: SaaS], [Domain: Email], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Configuration Audit], [Tactic: Collection], [Resources: Investigation Guide] |None |214 |<> |Identifies when a user creates a new inbox rule in Microsoft 365 that deletes or moves emails containing suspicious keywords. Adversaries who have compromised accounts often create inbox rules to hide alerts, security notifications, or other sensitive messages by automatically deleting them or moving them to obscure folders. Common destinations include Deleted Items, Junk Email, RSS Feeds, and RSS Subscriptions. This is a New Terms rule that triggers only when the user principal name and associated source IP address have not been observed performing this activity in the past 14 days. |[Domain: Cloud], [Domain: SaaS], [Domain: Email], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |5 +|<> |Identifies when a Microsoft Exchange inbox rule is created or modified with a name composed only of special characters. Adversaries may use obfuscated inbox rule names to evade detection, hide malicious forwarding or deletion rules, or blend in with benign audit noise. The rule name is parsed from "o365.audit.ObjectId", which encodes the mailbox identity and rule name separated by a backslash. |[Domain: Cloud], [Domain: SaaS], [Domain: Email], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |2 + |<> |Identifies when an MFA enrollment, registration, or security notification email is deleted or moved to deleted items in Microsoft 365 Exchange. Adversaries who compromise accounts and register their own MFA device often delete the notification emails to cover their tracks and prevent the legitimate user from noticing the unauthorized change. This technique is commonly observed in business email compromise (BEC) and account takeover attacks. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |3 |<> |Identifies a transport rule creation in Microsoft 365. As a best practice, Exchange Online mail transport rules should not be set to forward email to domains outside of your organization. An adversary may create transport rules to exfiltrate data. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |213 @@ -1618,7 +1652,7 @@ and their rule type is `machine_learning`. |<> |Identifies when a new SharePoint Site Administrator is added in Microsoft 365. Site Administrators have full control over SharePoint Sites, including the ability to manage permissions, access all content, and modify site settings. Adversaries who compromise a privileged account may add themselves or a controlled account as a Site Administrator to maintain persistent, high-privilege access to sensitive SharePoint data. This technique was notably observed in the 0mega ransomware campaign, where attackers elevated privileges to exfiltrate data and deploy ransom notes across SharePoint sites. |[Domain: Cloud], [Domain: SaaS], [Domain: Identity], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |2 -|<> |Identifies when a SharePoint or OneDrive site sharing policy is changed to weaken security controls. The SharingPolicyChanged event fires for many routine policy modifications, but this rule targets specific high-risk transitions where sharing restrictions are relaxed. This includes enabling guest sharing, enabling anonymous link sharing, making a site public, or enabling guest user access. Adversaries who compromise administrative accounts may weaken sharing policies to exfiltrate data to external accounts or create persistent external access paths. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |3 +|<> |Identifies when a SharePoint or OneDrive site sharing policy is changed to weaken security controls. The SharingPolicyChanged event fires for many routine policy modifications, but this rule targets specific high-risk transitions where sharing restrictions are relaxed. This includes enabling guest sharing, enabling anonymous link sharing, making a site public, or enabling guest user access. Adversaries who compromise administrative accounts may weaken sharing policies to exfiltrate data to external accounts or create persistent external access paths. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |4 |<> |Identifies file downloads or access from OneDrive or SharePoint using PowerShell-based user agents. Adversaries may use native PowerShell cmdlets like Invoke-WebRequest or Invoke-RestMethod with Microsoft Graph API to exfiltrate data after compromising OAuth tokens via device code phishing or other credential theft techniques. This rule detects both direct PowerShell access and PnP PowerShell module usage for file operations. FileAccessed events are included to detect adversaries reading file content via API and saving locally, bypassing traditional download methods. Normal users access SharePoint/OneDrive via browsers or sync clients, making PowerShell-based file access inherently suspicious. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Tactic: Collection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |4 @@ -1626,7 +1660,7 @@ and their rule type is `machine_learning`. |<> |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 |7 +|<> |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 @@ -1910,6 +1944,8 @@ and their rule type is `machine_learning`. |<> |Identifies parent process spoofing used to thwart detection. Adversaries may spoof the parent process identifier (PPID) of a new process to evade process-monitoring defenses or to elevate privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |111 +|<> |This rule detects passwordless sudo probing activity on Linux systems. Passwordless sudo probing can be an indication of an attacker attempting to enumerate it's allowed commands and potential privilege escalation. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |1 + |<> |Detects when an unusual parent process like Node.js, Python, or osascript executes the pbpaste binary to access clipboard data. This technique has been used by malware like OtterCookie to steal passwords and seed phrases from the clipboard. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Collection], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1 |<> |Identifies use of the Windows file system utility (fsutil.exe) to gather information about attached peripheral devices and components connected to a computer system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide], [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] |None |316 @@ -2276,7 +2312,7 @@ and their rule type is `machine_learning`. |<> |Identifies use of the Secure Copy Protocol (SCP) to copy files locally by abusing the auto addition of the Secure Shell Daemon (sshd) to the authorized application list for Full Disk Access. This may indicate attempts to bypass macOS privacy controls to access sensitive files. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |114 -|<> |Identifies the use of sqlite3 to directly modify the Transparency, Consent, and Control (TCC) SQLite database. This may indicate an attempt to bypass macOS privacy controls, including access to sensitive resources like the system camera, microphone, address book, and calendar. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |113 +|<> |Identifies the use of sqlite3 to directly modify the Transparency, Consent, and Control (TCC) SQLite database. This may indicate an attempt to bypass macOS privacy controls, including access to sensitive resources like the system camera, microphone, address book, and calendar. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |114 |<> |Identifies audit events for runc init child processes where the effective user is root and the login user ID is not root. This pattern can indicate privilege escalation or credential separation abuse inside container runtimes, where a process executes with elevated effective privileges while retaining a non-root audit identity. |[Domain: Endpoint], [Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide], [Data Source: Auditd Manager] |None |1 @@ -2308,7 +2344,7 @@ and their rule type is `machine_learning`. |<> |Detects a short sequence where a non-root user performs unshare-related namespace activity (often associated with user namespace privilege escalation primitives) and then a root process is executed shortly after. This can indicate a successful local privilege escalation attempt or suspicious namespace manipulation captured in Auditd Manager telemetry. |[Data Source: Auditd Manager], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 -|<> |Identifies potentially suspicious use of unshare to create a user namespace context followed by a UID change event indicating a transition to root. Adversaries may use unshare-based primitives as part of local privilege escalation chains. This rule is intentionally generic and can surface multiple local privesc patterns beyond a single CVE. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |11 +|<> |Identifies potentially suspicious use of unshare to create a user namespace context followed by a UID change event indicating a transition to root. Adversaries may use unshare-based primitives as part of local privilege escalation chains. This rule is intentionally generic and can surface multiple local privesc patterns beyond a single CVE. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |12 |<> |Identifies a suspicious computer account name rename event, which may indicate an attempt to exploit CVE-2021-42278 to elevate privileges from a standard domain user to a user with domain admin privileges. CVE-2021-42278 is a security vulnerability that allows potential attackers to impersonate a domain controller via samAccountName attribute spoofing. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Use Case: Vulnerability], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |216 @@ -2598,7 +2634,7 @@ and their rule type is `machine_learning`. |<> |A machine learning job detected an unusual error in a CloudTrail message. These can be byproducts of attempted or successful persistence, privilege escalation, defense evasion, discovery, lateral movement, or collection. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |212 -|<> |Identifies rare connection attempts to a Web Distributed Authoring and Versioning (WebDAV) resource. Attackers may inject WebDAV paths in files or features opened by a victim user to leak their NTLM credentials via forced authentication. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |9 +|<> |Identifies rare connection attempts to a Web Distributed Authoring and Versioning (WebDAV) resource. Attackers may inject WebDAV paths in files or features opened by a victim user to leak their NTLM credentials via forced authentication. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |10 |<> |This rule detects rare internet network connections via the SMB protocol. SMB is commonly used to leak NTLM credentials via rogue UNC path injection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Exfiltration], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |214 @@ -2712,6 +2748,8 @@ and their rule type is `machine_learning`. |<> |Monitors kernel logs for segfault messages. A segfault, or segmentation fault, is an error that occurs when a program tries to access a memory location that it's not allowed to access, typically leading to program termination. A segfault can be an indication of malicious behavior if it results from attempts to exploit buffer overflows or other vulnerabilities in software to execute arbitrary code or disrupt its normal operation. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Rule Type: BBR] |None |4 +|<> |Monitors kernel logs for segfault messages from sensitive processes. A segfault, or segmentation fault, is an error that occurs when a program tries to access a memory location that it's not allowed to access, typically leading to program termination. A segfault can be an indication of malicious behavior if it results from attempts to exploit buffer overflows, inject shared objects, or other vulnerabilities in software to execute arbitrary code or disrupt its normal operation. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + |<> |Identifies attempts to disable auditing for some security sensitive audit policy sub-categories. This is often done by attackers in an attempt to evade detection and forensics on a system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs] |None |6 |<> |Detects when a sensitive file is accessed followed by the immediate creation of a compressed file in a suspicious location. This activity can indicate an attempt to collect sensitive local data and stage it for exfiltration. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Collection], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 @@ -2864,7 +2902,7 @@ and their rule type is `machine_learning`. |<> |Detects suspicious network events executed by the APT package manager, potentially indicating persistence through an APT backdoor. In Linux, APT (Advanced Package Tool) is a command-line utility used for handling packages on Debian-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor APT to gain persistence by injecting malicious code into scripts that APT runs, thereby ensuring continued unauthorized access or control each time APT is used for package management. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Command and Control], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |10 -|<> |Detects when a script interpreter (osascript, Node.js, Python) with minimal arguments makes an outbound connection to AWS S3 or CloudFront domains. Threat actors have used S3 buckets for both command and control and data exfiltration. Script interpreters connecting to cloud storage should be investigated for potential malicious activity. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |3 +|<> |Detects when a script interpreter (osascript, Node.js, Python) with minimal arguments makes an outbound connection to AWS S3 or CloudFront domains. Threat actors have used S3 buckets for both command and control and data exfiltration. Script interpreters connecting to cloud storage should be investigated for potential malicious activity. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |4 |<> |Identify read access to a high number of Active Directory object attributes. The knowledge of objects properties can help adversaries find vulnerabilities, elevate privileges or collect sensitive information. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Windows Security Event Logs], [Data Source: Active Directory], [Data Source: Windows], [Resources: Investigation Guide] |None |110 @@ -2882,12 +2920,14 @@ 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], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: SentinelOne] |None |113 +|<> |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 |<> |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 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 |<> |Identifies suspicious child processes of communications apps, which can indicate a potential masquerading as the communication app or the exploitation of a vulnerability on the application causing it to execute code. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: SentinelOne], [Data Source: Elastic Endgame] |None |14 @@ -2954,6 +2994,10 @@ and their rule type is `machine_learning`. |<> |Detects the execution of a MacOS installer package with an abnormal child process (e.g bash) followed immediately by a network connection via a suspicious process (e.g curl). Threat actors will build and distribute malicious MacOS installer packages, which have a .pkg extension, many times imitating valid software in order to persuade and infect their victims often using the package files (e.g pre/post install scripts etc.) to download additional tools or malicious software. If this rule fires it should indicate the installation of a malicious or suspicious package. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |113 +|<> |This rule identifies various tools/scripts performing command line execution attempting to access the cloud service provider's instance metadata service (IMDS) API endpoint, which can be used to retrieve sensitive instance-specific information such as instance ID, public IP address, and even temporary security credentials if roles are assumed by that instance. |[Domain: Endpoint], [Domain: Cloud], [OS: Linux], [OS: Windows], [OS: macOS], [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], [Data Source: Auditd Manager], [Resources: Investigation Guide] |None |9 + +|<> |This rule identifies various tools/scripts performing network activities attempting to access the cloud service provider's instance metadata service (IMDS) API endpoint, which can be used to retrieve sensitive instance-specific information such as instance ID, public IP address, and even temporary security credentials if roles are assumed by that instance. |[Domain: Endpoint], [Domain: Cloud], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1 + |<> |Detects Inter-Process Communication with Outlook via Component Object Model from an unusual process. Adversaries may target user email to collect sensitive information or send email on their behalf via API. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |12 |<> |Detects execution of JavaScript via Deno with suspicious command-line patterns (base64, eval, http, or import in a javascript context). Adversaries may abuse Deno to run malicious JavaScript for execution or staging. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Data Source: Elastic Endgame], [Data Source: Windows Security Event Logs] |None |4 @@ -3086,7 +3130,7 @@ and their rule type is `machine_learning`. |<> |Identifies WMIC allowlist bypass techniques by alerting on suspicious execution of scripts. When WMIC loads scripting libraries it may be indicative of an allowlist bypass. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |214 -|<> |Identifies the access or file open of web browser sensitive files by an untrusted/unsigned process or osascript. Adversaries may acquire credentials from web browsers by reading files specific to the target browser. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |214 +|<> |Identifies the access or file open of web browser sensitive files by an untrusted/unsigned process or osascript. Adversaries may acquire credentials from web browsers by reading files specific to the target browser. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |215 |<> |A suspicious WerFault child process was detected, which may indicate an attempt to run via the SilentProcessExit registry key manipulation. Verify process details such as command line, network connections and file writes. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |420 @@ -3206,8 +3250,6 @@ and their rule type is `machine_learning`. |<> |Identifies a failed OAuth 2.0 token grant attempt for a public client app using client credentials. This event is generated when a public client app attempts to exchange a client credentials grant for an OAuth 2.0 access token, but the request is denied due to the lack of required scopes. This could indicate compromised client credentials in which an adversary is attempting to obtain an access token for unauthorized scopes. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule where the `okta.actor.display_name` field value has not been seen in the last 14 days regarding this event. |[Domain: SaaS], [Data Source: Okta], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |210 -|<> |This rule identifies unusual destination port network activity originating from a web server process. The rule is designed to detect potential web shell activity or unauthorized communication from a web server process to external systems. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6 - |<> |Detects changes to registry persistence keys that are not commonly used or modified by legitimate programs. This could be an indication of an adversary's attempt to persist in a stealthy manner. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |217 |<> |Identifies when a child process is spawned by the screensaver engine process, which is consistent with an attacker's malicious payload being executed after the screensaver activated on the endpoint. An adversary can maintain persistence on a macOS endpoint by creating a malicious screensaver (.saver) file and configuring the screensaver plist file to execute code each time the screensaver is activated. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |111 @@ -3236,6 +3278,8 @@ 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 + |<> |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 |<> |Identifies an unexpected process spawning from dns.exe, the process responsible for Windows DNS server services, which may indicate activity related to remote code execution or other forms of exploitation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [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 |320 @@ -3244,7 +3288,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 detects potential command execution from a web server parent process on a Linux host. Adversaries may attempt to execute commands from a web server parent process to blend in with normal web server activity and evade detection. This behavior is commonly observed in web shell attacks where adversaries exploit web server vulnerabilities to execute arbitrary commands on the host. The detection rule identifies unusual command execution from web server parent processes, which may indicate a compromised host or an ongoing attack. 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: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |13 +|<> |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 |<> |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 @@ -3288,8 +3332,6 @@ and their rule type is `machine_learning`. |<> |A machine learning job detected a user logging in at a time of day that is unusual for the user. This can be due to credentialed access via a compromised account when the user and the threat actor are in different time zones. In addition, unauthorized user activity often takes place during non-business hours. |[Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Initial Access], [Resources: Investigation Guide] |None |107 -|<> |This rule identifies potentially malicious processes attempting to access the cloud service provider's instance metadata service (IMDS) API endpoint, which can be used to retrieve sensitive instance-specific information such as instance ID, public IP address, and even temporary security credentials if role's are assumed by that instance. The rule monitors for various tools and scripts like curl, wget, python, and perl that might be used to interact with the metadata API. |[Domain: Endpoint], [Domain: Cloud], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |8 - |<> |This rule detects interactive shells launched from system users. System users typically do not require interactive shells, and their presence may indicate malicious activity. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6 |<> |Loadable Kernel Modules (or LKMs) 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 identifies attempts to enumerate information about a kernel module. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |215 @@ -3378,8 +3420,6 @@ and their rule type is `machine_learning`. |<> |A machine learning job has detected a suspicious Windows process. This process has been classified as malicious in two ways. It was predicted to be malicious by the ProblemChild supervised ML model, and it was found to be suspicious given that its user context is unusual and does not commonly manifest malicious activity,by an unsupervised ML model. Such a process may be an instance of suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules. |[Domain: Endpoint], [OS: Windows], [Use Case: Living off the Land Attack Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |111 -|<> |This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish persistence, execute malicious commands, or establish command and control channels on the host system. 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: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |13 - |<> |A machine learning job has detected a rare process writing data to an external device. Malicious actors often use benign-looking processes to mask their data exfiltration activities. The discovery of such a process that has no legitimate reason to write data to external devices can indicate exfiltration. |[Use Case: Data Exfiltration Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |8 |<> |A machine learning job has identified a user performing privileged operations in Okta from an uncommon geographical location, indicating potential privileged access activity. This could suggest a compromised account, unauthorized access, or an attacker using stolen credentials to escalate privileges. |[Use Case: Privileged Access Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |4 @@ -3418,8 +3458,6 @@ and their rule type is `machine_learning`. |<> |A machine learning job detected a rare and unusual URL that indicates unusual web browsing activity. This can be due to initial access, persistence, command-and-control, or exfiltration activity. For example, in a strategic web compromise or watering hole attack, when a trusted website is compromised to target a particular sector or organization, targeted users may receive emails with uncommon URLs for trusted websites. These URLs can be used to download and run a payload. When malware is already running, it may send requests to uncommon URLs on trusted websites the malware uses for command-and-control communication. When rare URLs are observed being requested for a local web server by a remote source, these can be due to web scanning, enumeration or attack traffic, or they can be due to bots and web scrapers which are part of common Internet background traffic. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Command and Control], [Resources: Investigation Guide] |None |108 -|<> |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 |3 - |<> |A machine learning job detected a rare and unusual user agent indicating web browsing activity by an unusual process other than a web browser. This can be due to persistence, command-and-control, or exfiltration activity. Uncommon user agents coming from remote sources to local destinations are often the result of scanners, bots, and web scrapers, which are part of common Internet background traffic. Much of this is noise, but more targeted attacks on websites using tools like Burp or SQLmap can sometimes be discovered by spotting uncommon user agents. Uncommon user agents in traffic from local sources to remote destinations can be any number of things, including harmless programs like weather monitoring or stock-trading programs. However, uncommon user agents from local sources can also be due to malware or scanning activity. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Command and Control], [Resources: Investigation Guide] |None |107 |<> |Identifies Windows processes that do not usually use the network but have unexpected network activity, which can indicate command-and-control, lateral movement, persistence, or data exfiltration activity. A process with unusual network activity can denote process exploitation or injection, where the process is used to run persistence mechanisms that allow a malicious actor remote access or control of the host, data exfiltration, and execution of unauthorized network applications. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |211 diff --git a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc index 81df30128a..9094508f45 100644 --- a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc +++ b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc @@ -112,6 +112,7 @@ include::rule-details/aws-s3-bucket-policy-added-to-allow-public-access.asciidoc include::rule-details/aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc[] include::rule-details/aws-s3-bucket-replicated-to-another-account.asciidoc[] include::rule-details/aws-s3-bucket-server-access-logging-disabled.asciidoc[] +include::rule-details/aws-s3-credential-file-retrieved-from-bucket.asciidoc[] include::rule-details/aws-s3-object-encryption-using-external-kms-key.asciidoc[] include::rule-details/aws-s3-object-versioning-suspended.asciidoc[] include::rule-details/aws-s3-static-site-javascript-file-uploaded.asciidoc[] @@ -243,6 +244,8 @@ include::rule-details/azure-openai-insecure-output-handling.asciidoc[] include::rule-details/azure-rbac-built-in-administrator-roles-assigned.asciidoc[] include::rule-details/azure-recovery-services-resource-deleted.asciidoc[] include::rule-details/azure-resource-group-deleted.asciidoc[] +include::rule-details/azure-run-command-correlated-with-process-execution.asciidoc[] +include::rule-details/azure-run-command-script-child-process.asciidoc[] include::rule-details/azure-service-principal-sign-in-followed-by-arc-cluster-credential-access.asciidoc[] include::rule-details/azure-storage-account-blob-public-access-enabled.asciidoc[] include::rule-details/azure-storage-account-deletion-by-unusual-user.asciidoc[] @@ -250,6 +253,7 @@ 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-extension-deployment-by-user.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[] @@ -274,6 +278,7 @@ include::rule-details/chkconfig-service-add.asciidoc[] include::rule-details/chroot-execution-in-container-context-on-linux.asciidoc[] include::rule-details/clearing-windows-console-history.asciidoc[] include::rule-details/clearing-windows-event-logs.asciidoc[] +include::rule-details/cloud-instance-metadata-credential-path-http-request.asciidoc[] include::rule-details/cobalt-strike-command-and-control-beacon.asciidoc[] include::rule-details/code-signing-policy-modification-through-built-in-tools.asciidoc[] include::rule-details/code-signing-policy-modification-through-registry.asciidoc[] @@ -351,7 +356,10 @@ include::rule-details/deprecated-powershell-script-with-remote-execution-capabil include::rule-details/deprecated-sunburst-command-and-control-activity.asciidoc[] include::rule-details/deprecated-sudo-heap-based-buffer-overflow-attempt.asciidoc[] include::rule-details/deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc[] +include::rule-details/deprecated-uncommon-destination-port-connection-by-web-server.asciidoc[] +include::rule-details/deprecated-unusual-command-execution-from-web-server-parent.asciidoc[] include::rule-details/deprecated-unusual-discovery-activity-by-user.asciidoc[] +include::rule-details/deprecated-unusual-process-spawned-from-web-server-parent.asciidoc[] include::rule-details/detection-alert-on-a-process-exhibiting-cpu-spike.asciidoc[] include::rule-details/directory-creation-in-bin-directory.asciidoc[] include::rule-details/disable-windows-event-and-security-logs-using-built-in-tools.asciidoc[] @@ -395,6 +403,8 @@ include::rule-details/entra-id-application-credential-modified.asciidoc[] include::rule-details/entra-id-concurrent-sign-in-with-suspicious-properties.asciidoc[] include::rule-details/entra-id-conditional-access-policy-cap-modified.asciidoc[] include::rule-details/entra-id-custom-domain-added-or-verified.asciidoc[] +include::rule-details/entra-id-device-registration-with-roadtools-default-os-build.asciidoc[] +include::rule-details/entra-id-device-with-roadtools-default-os-build-entity-analytics.asciidoc[] include::rule-details/entra-id-domain-federation-configuration-change.asciidoc[] include::rule-details/entra-id-elevated-access-to-user-access-administrator.asciidoc[] include::rule-details/entra-id-external-authentication-methods-eam-modified.asciidoc[] @@ -405,9 +415,11 @@ include::rule-details/entra-id-global-administrator-role-assigned-pim-user.ascii 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-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-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[] @@ -590,7 +602,6 @@ include::rule-details/github-ueba-multiple-alerts-from-a-github-account.asciidoc 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-drive-ownership-transferred-via-google-workspace.asciidoc[] include::rule-details/google-secops-external-alerts.asciidoc[] include::rule-details/google-workspace-2sv-policy-disabled.asciidoc[] include::rule-details/google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc[] @@ -600,14 +611,19 @@ 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-login-flagged-suspicious.asciidoc[] include::rule-details/google-workspace-mfa-enforcement-disabled.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[] include::rule-details/google-workspace-role-modified.asciidoc[] include::rule-details/google-workspace-suspended-user-account-renewed.asciidoc[] +include::rule-details/google-workspace-user-login-with-unusual-asn.asciidoc[] include::rule-details/google-workspace-user-organizational-unit-changed.asciidoc[] +include::rule-details/google-workspace-user-sign-in-from-atypical-device-type.asciidoc[] include::rule-details/group-policy-abuse-for-privilege-addition.asciidoc[] include::rule-details/group-policy-discovery-via-microsoft-gpresult-utility.asciidoc[] include::rule-details/halfbaked-command-and-control-beacon.asciidoc[] @@ -769,6 +785,7 @@ include::rule-details/m365-exchange-email-safe-link-policy-disabled.asciidoc[] include::rule-details/m365-exchange-federated-domain-created-or-modified.asciidoc[] include::rule-details/m365-exchange-inbox-forwarding-rule-created.asciidoc[] include::rule-details/m365-exchange-inbox-phishing-evasion-rule-created.asciidoc[] +include::rule-details/m365-exchange-inbox-rule-with-obfuscated-name.asciidoc[] include::rule-details/m365-exchange-mfa-notification-email-deleted-or-moved.asciidoc[] include::rule-details/m365-exchange-mail-flow-transport-rule-created.asciidoc[] include::rule-details/m365-exchange-mail-flow-transport-rule-modified.asciidoc[] @@ -946,6 +963,7 @@ include::rule-details/outlook-home-page-registry-modification.asciidoc[] include::rule-details/panw-and-elastic-defend-command-and-control-correlation.asciidoc[] include::rule-details/parent-process-detected-with-suspicious-windows-process-es.asciidoc[] include::rule-details/parent-process-pid-spoofing.asciidoc[] +include::rule-details/passwordless-sudo-probing.asciidoc[] include::rule-details/pbpaste-execution-via-unusual-parent-process.asciidoc[] include::rule-details/peripheral-device-discovery.asciidoc[] include::rule-details/perl-outbound-network-connection.asciidoc[] @@ -1347,6 +1365,7 @@ include::rule-details/security-file-access-via-common-utilities.asciidoc[] include::rule-details/security-software-discovery-using-wmic.asciidoc[] include::rule-details/security-software-discovery-via-grep.asciidoc[] include::rule-details/segfault-detected.asciidoc[] +include::rule-details/segfault-from-sensitive-process-detected.asciidoc[] include::rule-details/sensitive-audit-policy-sub-category-disabled.asciidoc[] include::rule-details/sensitive-file-access-followed-by-compression.asciidoc[] include::rule-details/sensitive-files-compression.asciidoc[] @@ -1435,6 +1454,7 @@ include::rule-details/suspicious-certutil-commands.asciidoc[] include::rule-details/suspicious-child-execution-via-web-server.asciidoc[] include::rule-details/suspicious-child-process-of-adobe-acrobat-reader-update-service.asciidoc[] include::rule-details/suspicious-cmd-execution-via-wmi.asciidoc[] +include::rule-details/suspicious-command-execution-via-web-server.asciidoc[] include::rule-details/suspicious-command-prompt-network-connection.asciidoc[] include::rule-details/suspicious-communication-app-child-process.asciidoc[] include::rule-details/suspicious-content-extracted-or-decompressed-via-funzip.asciidoc[] @@ -1468,6 +1488,8 @@ include::rule-details/suspicious-hidden-child-process-of-launchd.asciidoc[] include::rule-details/suspicious-image-load-taskschd-dll-from-ms-office.asciidoc[] include::rule-details/suspicious-imagepath-service-creation.asciidoc[] include::rule-details/suspicious-installer-package-spawns-network-event.asciidoc[] +include::rule-details/suspicious-instance-metadata-service-imds-api-command-line-execution.asciidoc[] +include::rule-details/suspicious-instance-metadata-service-imds-api-request.asciidoc[] include::rule-details/suspicious-inter-process-communication-via-outlook.asciidoc[] include::rule-details/suspicious-javascript-execution-via-deno.asciidoc[] include::rule-details/suspicious-jetbrains-teamcity-child-process.asciidoc[] @@ -1594,7 +1616,6 @@ include::rule-details/uac-bypass-via-windows-firewall-snap-in-hijack.asciidoc[] include::rule-details/uid-elevation-from-previously-unknown-executable.asciidoc[] include::rule-details/unauthorized-access-to-an-okta-application.asciidoc[] include::rule-details/unauthorized-scope-for-public-app-oauth2-token-grant-with-client-credentials.asciidoc[] -include::rule-details/uncommon-destination-port-connection-by-web-server.asciidoc[] include::rule-details/uncommon-registry-persistence-change.asciidoc[] include::rule-details/unexpected-child-process-of-macos-screensaver-engine.asciidoc[] include::rule-details/unix-socket-connection.asciidoc[] @@ -1609,11 +1630,12 @@ include::rule-details/untrusted-driver-loaded.asciidoc[] include::rule-details/unusual-aws-command-for-a-user.asciidoc[] include::rule-details/unusual-aws-s3-object-encryption-with-sse-c.asciidoc[] include::rule-details/unusual-base64-encoding-decoding-activity.asciidoc[] +include::rule-details/unusual-child-execution-via-web-server.asciidoc[] include::rule-details/unusual-child-process-from-a-system-virtual-process.asciidoc[] include::rule-details/unusual-child-process-of-dns-exe.asciidoc[] include::rule-details/unusual-child-processes-of-rundll32.asciidoc[] include::rule-details/unusual-city-for-an-aws-command.asciidoc[] -include::rule-details/unusual-command-execution-from-web-server-parent.asciidoc[] +include::rule-details/unusual-command-execution-via-web-server.asciidoc[] include::rule-details/unusual-country-for-an-aws-command.asciidoc[] include::rule-details/unusual-d-bus-daemon-child-process.asciidoc[] include::rule-details/unusual-dns-activity.asciidoc[] @@ -1635,7 +1657,6 @@ include::rule-details/unusual-high-word-policy-blocks-detected.asciidoc[] include::rule-details/unusual-host-name-for-okta-privileged-operations-detected.asciidoc[] include::rule-details/unusual-host-name-for-windows-privileged-operations-detected.asciidoc[] include::rule-details/unusual-hour-for-a-user-to-logon.asciidoc[] -include::rule-details/unusual-instance-metadata-service-imds-api-request.asciidoc[] include::rule-details/unusual-interactive-shell-launched-from-system-user.asciidoc[] include::rule-details/unusual-kernel-module-enumeration.asciidoc[] include::rule-details/unusual-kill-signal.asciidoc[] @@ -1680,7 +1701,6 @@ include::rule-details/unusual-process-network-connection.asciidoc[] include::rule-details/unusual-process-spawned-by-a-host.asciidoc[] include::rule-details/unusual-process-spawned-by-a-parent-process.asciidoc[] include::rule-details/unusual-process-spawned-by-a-user.asciidoc[] -include::rule-details/unusual-process-spawned-from-web-server-parent.asciidoc[] include::rule-details/unusual-process-writing-data-to-an-external-device.asciidoc[] include::rule-details/unusual-region-name-for-okta-privileged-operations-detected.asciidoc[] include::rule-details/unusual-region-name-for-windows-privileged-operations-detected.asciidoc[] @@ -1700,7 +1720,6 @@ include::rule-details/unusual-time-or-day-for-an-rdp-session.asciidoc[] include::rule-details/unusual-user-privilege-enumeration-via-id.asciidoc[] include::rule-details/unusual-web-config-file-access.asciidoc[] include::rule-details/unusual-web-request.asciidoc[] -include::rule-details/unusual-web-server-command-execution.asciidoc[] include::rule-details/unusual-web-user-agent.asciidoc[] include::rule-details/unusual-windows-network-activity.asciidoc[] include::rule-details/unusual-windows-path-activity.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 7053ea4e0f..c0a4bb627a 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 @@ -37,7 +37,7 @@ Specially crafted DNS requests can manipulate a known overflow vulnerability in * Data Source: PAN-OS * Data Source: Network Traffic -*Version*: 110 +*Version*: 111 *Rule authors*: @@ -73,8 +73,9 @@ Detection alerts from this rule indicate possible anomalous activity around larg *False positive analysis* -- Based on this rule, which looks for a threshold of 60k bytes, it is possible for activity to be generated under 65k bytes and related to legitimate behavior. 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 were all observed as greater than 65k bytes. +- 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. *Related rules* @@ -102,8 +103,12 @@ 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)) - and destination.bytes > 60000 + 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 +) ---------------------------------- 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 1a022ee511..bc2e5c5ebc 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 @@ -41,7 +41,7 @@ This rule detects network events that may indicate the use of Telnet traffic. Te * Data Source: Suricata * Resources: Investigation Guide -*Version*: 113 +*Version*: 114 *Rule authors*: @@ -107,9 +107,12 @@ Telnet, a protocol for remote command-line access, is often used in legacy syste (data_stream.dataset:(fortinet_fortigate.log or network_traffic.flow or sonicwall_firewall.log or suricata.eve or panw.panos) or event.category:(network or network_traffic)) - and event.type:(connection and not end) and not event.action:( - flow_dropped or flow_denied or denied or deny or - flow_terminated or timeout or Reject or network_flow) + and 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 not (event.action:netflow_flow and not network.packets > 1) + and not network.application:(traceroute or stretchoid-scanning) and destination.port:23 ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-clear-kernel-ring-buffer.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-clear-kernel-ring-buffer.asciidoc index d83bf46a45..818f368b21 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-clear-kernel-ring-buffer.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-clear-kernel-ring-buffer.asciidoc @@ -39,7 +39,7 @@ Monitors for the deletion of the kernel ring buffer events through dmesg. Attack * Data Source: SentinelOne * Resources: Investigation Guide -*Version*: 110 +*Version*: 111 *Rule authors*: @@ -139,7 +139,7 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ ---------------------------------- 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 == "dmesg" and process.args in ("-c", "--clear") +process.name == "dmesg" and process.args in ("-c", "-C", "--clear", "--read-clear") ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc index 4e4e09bf0c..f7c212a1f2 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc @@ -36,7 +36,7 @@ Detects successful `AssumeRoleWithWebIdentity` where the caller identity is a Ku * Tactic: Initial Access * Resources: Investigation Guide -*Version*: 1 +*Version*: 2 *Rule authors*: @@ -103,7 +103,7 @@ outside the cluster (exfiltrated JWT, misrouted traffic, or operator tooling). data_stream.dataset:aws.cloudtrail and event.provider:sts.amazonaws.com and event.action:AssumeRoleWithWebIdentity and - event.outcome:success and user.name:system\:serviceaccount\:* and + event.outcome:success and user.name:(system\:serviceaccount\:* and not system\:serviceaccount\:kube-system\:aws-load-balancer-controller) and source.as.organization.name:(* and not (Amazon* or AMAZON*)) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/aws-s3-credential-file-retrieved-from-bucket.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-s3-credential-file-retrieved-from-bucket.asciidoc new file mode 100644 index 0000000000..d6438df104 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-s3-credential-file-retrieved-from-bucket.asciidoc @@ -0,0 +1,158 @@ +[[aws-s3-credential-file-retrieved-from-bucket]] +=== AWS S3 Credential File Retrieved from Bucket + +Detects successful S3 GetObject calls targeting high-value credential and secret files commonly stored in S3 buckets: AWS credentials files (".aws/credentials", ".aws/config"), SSH private keys ("id_rsa", "id_ed25519", "id_ecdsa", "id_dsa"), environment files (".env"), PEM and PuTTY key files, and other private key patterns. These file types are high-yield targets for credential harvesting from S3. The rule excludes AWSService identity type to suppress S3 replication, Glacier restore, and other AWS-internal data movement that legitimately reads these files. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* 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/AmazonS3/latest/API/API_GetObject.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Credential File Retrieved from Bucket* + + +S3 is frequently used to store configuration files, scripts, and secrets. When files with credential-like +names are accessed, it warrants investigation to ensure that the retrieval was authorized. + + +*Possible investigation steps* + + +- **Identify the accessed file**: Review `aws.cloudtrail.request_parameters` for the bucket name and key. + Determine whether the bucket is intended to store secrets. +- **Verify the caller**: Inspect `aws.cloudtrail.user_identity.arn` and `source.ip`. If the caller is not + an approved automation role, escalate immediately. +- **Check bucket permissions**: Determine if the bucket is publicly accessible or if the key naming + pattern was intentionally exposed. +- **Look for downstream actions**: Search for subsequent IAM, STS, or console actions from the same + identity shortly after the object retrieval, which may indicate successful credential use. + + +*False positive analysis* + + +- Legitimate backup or restore processes may access credential files stored in S3 as part of their + workflow. Validate the calling identity and user agent against known automation accounts. +- CI/CD pipelines that retrieve secrets from S3 during deployment may trigger this rule. Verify the + source IP and ARN match expected automation infrastructure. + + +*Response and remediation* + + +- Immediately disable the access key identified in `aws.cloudtrail.user_identity.access_key_id` if + the retrieval is determined to be unauthorized. +- Audit the S3 bucket for overly permissive policies or public access configurations. +- Rotate any credentials stored in the accessed object — treat them as compromised. +- Review all CloudTrail events from the same identity in the preceding 30 minutes for signs of + lateral movement, IAM changes, or resource creation. +- Implement S3 bucket policies or IAM conditions restricting access to credential files to only + authorized identities and source IPs. + + +==== Setup + + +S3 data event logging is required for this rule. This rule detects S3 GetObject events, +which are data plane events not logged by default. To enable: CloudTrail console → Trails → +[trail name] → Data events → Add S3 → select the buckets to monitor (or all buckets with a wildcard). +Without this configuration, the rule produces no alerts. + +Refer to the AWS documentation on +https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html[logging data events] +for detailed steps. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "s3.amazonaws.com" and + event.action: "GetObject" and + event.outcome: "success" and + aws.cloudtrail.flattened.request_parameters.key: ( + */.aws/credentials or + */.aws/config or + */id_rsa or + */id_ed25519 or + */id_ecdsa or + */id_dsa or + */.env or + */.env.* or + *.ppk or + *.pem or + *.key or + *private_key* or + */.ssh/authorized_keys + ) and + not aws.cloudtrail.user_identity.type: "AWSService" + +---------------------------------- + +*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: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* 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/rule-details/aws-ssm-session-manager-child-process-execution.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ssm-session-manager-child-process-execution.asciidoc index b196ba9638..6a6f8e9bf9 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-ssm-session-manager-child-process-execution.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-ssm-session-manager-child-process-execution.asciidoc @@ -44,7 +44,7 @@ Identifies process start events where the parent process is the AWS Systems Mana * Data Source: SentinelOne * Resources: Investigation Guide -*Version*: 2 +*Version*: 3 *Rule authors*: @@ -110,10 +110,10 @@ event.category: "process" and event.action : ("exec" or "exec_event" or "start" (process.parent.name : "powershell.exe" and process.parent.args : *awsrunPowerShellScript*) or (process.parent.name : ("dash" or "sh" or "bash") and process.parent.args : *awsrunShellScript*) ) and - process.command_line:* and - not (process.name : "powershell.exe" and process.args :("$str.Substring($str.length" or *Convert-GuidToCompressedGuid* or get-wmiobject* or $wmi_proc* or *win32_quickfixengineering*)) and - not process.executable : ("/usr/bin/lscpu" or "/usr/bin/snap" or "/usr/bin/rpm" or "/usr/bin/dpkg-query" or /snap/snapd/*/usr/bin/snap or "/usr/bin/id" or "C:\\Program Files\\Amazon\\SSM\\Plugins\\SessionManagerShell\\winpty-agent.exe") and - not (process.name : (dash or bash or sh or _script.sh) and process.args : /var/lib/amazon/ssm/*/document/orchestration/*/_script.sh) + not (process.name : "powershell.exe" and process.args :("$str.Substring($str.length" or *Convert-GuidToCompressedGuid* or get-wmiobject* or $wmi_proc* or *win32_quickfixengineering* or Get-wmiobject* or *Get-Service* or *Get-WmiObject* or *System32\\ntoskrnl.exe* or *GET-WMIOBJECT*)) and + not process.executable : ("/usr/bin/lscpu" or "/usr/bin/snap" or "/usr/bin/rpm" or "/usr/bin/dpkg-query" or /snap/snapd/*/usr/bin/snap or "/usr/bin/id" or "C:\\Program Files\\Amazon\\SSM\\Plugins\\SessionManagerShell\\winpty-agent.exe" or /var/lib/amazon/ssm/update/amazon-ssm-agent-updater/*/updater or C\:\\ProgramData\\Amazon\\SSM\\Update\\amazon-ssm-agent-updater\\*\\updater.exe) and + not (process.name : (dash or bash or sh or _script.sh) and process.args : /var/lib/amazon/ssm/*/document/orchestration/*/_script.sh) and + process.command_line :(* and not (*ssm-user or */invokeInspectorSsmPluginLinux/_script.sh or */checkExclusionPreference/_script.sh or *\\createUpdateFolder\\_script.ps1 or */checkProvisioningEligibility/_script.sh or */install/_script.sh or */uninstall/_script.sh)) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/azure-run-command-correlated-with-process-execution.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-run-command-correlated-with-process-execution.asciidoc new file mode 100644 index 0000000000..4d3b28af2d --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-run-command-correlated-with-process-execution.asciidoc @@ -0,0 +1,164 @@ +[[azure-run-command-correlated-with-process-execution]] +=== Azure Run Command Correlated with Process Execution + +Correlates successful Azure Virtual Machine Run Command operations with endpoint process execution on the same host within minutes. Adversaries abuse Run Command to run scripts remotely as SYSTEM or root while activity logs only record the control-plane action; Elastic Defend process telemetry reveals the on-guest payload. + +*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://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-contributor +* https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a +* https://adsecurity.org/?p=4277 + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* OS: Windows +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Azure +* Data Source: Microsoft Azure +* Data Source: Azure Activity Logs +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Run Command Correlated with Process Execution* + + +This ES|QL rule correlates Azure Activity Log `MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION` events with +endpoint process starts, joined on host name within a two-minute bucket and a 0–120 second delay between Run Command and process start. + +Pivot into raw `logs-azure.activitylogs-*` and `logs-endpoint.events.process-*` events for full command lines and +resource identifiers. + + +*Possible investigation steps* + + +- Review `user.email` and `azure.activitylogs.identity.authorization.evidence.principal_id` for who invoked Run Command. +- Inspect `Esql.process_command_line_values` for script paths and arguments beyond the matched pattern. +- Confirm `Esql.host_name` maps to the intended VM and whether Run Command timing aligns with change windows. +- Hunt for additional Run Command or PowerShell activity from the same principal or subscription. + + +*Response and remediation* + + +- If unauthorized, isolate the VM, revoke credentials used for Run Command, and review role assignments on the VM and + subscription. +- Collect endpoint artifacts and Azure activity logs for incident reporting. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-azure.activitylogs-*, logs-endpoint.events.process-* METADATA _id, _version, _index +| WHERE + ( + event.category == "process" AND KQL("event.action:start") + AND process.parent.name == "powershell.exe" + AND process.parent.command_line LIKE "powershell -ExecutionPolicy Unrestricted -File script?.ps1" + AND process.name != "conhost.exe" + ) OR + ( + KQL("event.category:process and event.action:exec and process.parent.name:(dash or bash or sh) and process.parent.args:/var/lib/waagent/run-command/download/*/script.sh") + ) OR + ( + event.module == "azure" + AND event.action == "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION" + AND NOT KQL("event.outcome:failure") + ) + +// Azure hostname comes as upper-case while Endpoint event comes as lowercase +| EVAL Esql.host_name = COALESCE( + TO_LOWER(host.name), + TO_LOWER(azure.resource.name) + ) +| EVAL ts_runcommand = CASE(event.module == "azure", @timestamp, null) +| EVAL ts_endpoint = CASE(event.category == "process", @timestamp, null) +| EVAL is_runcommand = CASE(event.module == "azure", 1, null) +| EVAL is_endpoint = CASE(event.category == "process", 1, null) +| EVAL Esql.time_bucket = DATE_TRUNC(2 minutes, @timestamp) +| STATS + runcommand_count = COUNT(is_runcommand), + endpoint_count = COUNT(is_endpoint), + user.email = VALUES(user.email), + azure.activitylogs.identity.authorization.evidence.principal_id = VALUES(azure.activitylogs.identity.authorization.evidence.principal_id), + azure.activitylogs.tenant_id = VALUES(azure.activitylogs.tenant_id), + azure.subscription_id = VALUES(azure.subscription_id), + source.ip = VALUES(source.ip), + source.geo.country_name = VALUES(source.geo.country_name), + source.as.number = VALUES(source.as.number), + Esql.process_command_line_values = VALUES(process.command_line), + first_runcommand = MIN(ts_runcommand), + first_ps_exec = MIN(ts_endpoint), + outcome = VALUES(event.outcome) + BY Esql.host_name, Esql.time_bucket +| WHERE runcommand_count >= 1 AND endpoint_count >= 1 +| EVAL delta_ms = TO_LONG(first_ps_exec) - TO_LONG(first_runcommand) +| EVAL delta_sec = delta_ms / 1000 +| WHERE delta_sec >= 0 AND delta_sec <= 120 +| KEEP + user.email, + azure.activitylogs.identity.authorization.evidence.principal_id, + source.ip, + source.as.number, + source.geo.country_name, + azure.activitylogs.tenant_id, + azure.subscription_id, + Esql.* + +---------------------------------- + +*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: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* 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-run-command-script-child-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-run-command-script-child-process.asciidoc new file mode 100644 index 0000000000..b09b1f62d9 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-run-command-script-child-process.asciidoc @@ -0,0 +1,126 @@ +[[azure-run-command-script-child-process]] +=== Azure Run Command Script Child Process + +Identifies process start events whose parent matches Azure Virtual Machine Run Command execution patterns on Windows or Linux. On Windows, Run Command often launches PowerShell with `-ExecutionPolicy Unrestricted` and a `script?.ps1` file; on Linux, the Azure Linux Agent (waagent) runs downloaded script.sh under "/var/lib/waagent/run-command/". Child process telemetry exposes the on-guest payload that cloud activity logs do not fully describe. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-windows.sysmon_operational-* + +*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://docs.microsoft.com/en-us/azure/virtual-machines/run-command +* https://hackingthe.cloud/azure/run-command-abuse/ + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* OS: Linux +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Azure +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Run Command Script Child Process* + + +Azure VM Run Command executes scripts on guests without interactive RDP or SSH. On Windows, a parent PowerShell +process with `-ExecutionPolicy Unrestricted -File script?.ps1` often precedes child utilities; on Linux, `waagent` +invokes `/var/lib/waagent/run-command/download/*/script.sh` via `bash`, `sh`, or `dash`. + +Correlate with `logs-azure.activitylogs-*` for `MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION` when available. + + +*Possible investigation steps* + + +- Review `process.command_line`, `process.name`, and `process.parent.command_line` or `process.parent.args`. +- Confirm whether the host is an Azure VM and whether Run Command was expected for that asset. +- Pivot on `host.name` or `host.id` for other suspicious process or network activity in the same window. + + +*False positive analysis* + + +- Extension handlers, guest configuration, and patch orchestration may use the same parent patterns. +- Exclude known automation hosts or script paths after validating with platform teams. + + +*Response and remediation* + + +- If unauthorized, review Azure RBAC on the VM and subscription, revoke compromised credentials, and isolate the guest. +- Collect endpoint artifacts and Azure activity logs for incident reporting. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type in ("start", "process_started") and + ( + (process.parent.name == "powershell.exe" and + process.parent.command_line like "powershell -ExecutionPolicy Unrestricted -File script?.ps1") or + (process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh", "busybox") and + process.parent.args like "/var/lib/waagent/run-command/download/*/script.sh") + ) + +---------------------------------- + +*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: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* 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-extension-deployment-by-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-vm-extension-deployment-by-user.asciidoc new file mode 100644 index 0000000000..45a4e30ad3 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-vm-extension-deployment-by-user.asciidoc @@ -0,0 +1,140 @@ +[[azure-vm-extension-deployment-by-user]] +=== Azure VM Extension Deployment by User + +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. + +*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://docs.microsoft.com/en-us/azure/virtual-machines/extensions/overview + +*Tags*: + +* 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 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure VM Extension Deployment by User* + + +This rule flags successful `MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/WRITE` operations performed by a user principal +where the extension resource ID matches high-risk extension families (VMAccess, Custom Script, Run Command, DSC, +Microsoft Monitoring Agent). + + +*Triage checklist* + + +- Is the caller UPN a known admin or automation account? +- Is the source IP or ASN consistent with corporate infrastructure or a known VPN? +- Was this extension deployment preceded by a Run Command invocation on the same VM? +- Did the extension deployment coincide with new local account creation on the endpoint? +- Check `azure.activitylogs.identity.claims.authnmethodsreferences` — was MFA present? +- Correlate with endpoint telemetry: process events parented by `WaAppAgent.exe` or `walinuxagent` within 120 seconds of + the extension write timestamp on the same host. + + +*Possible investigation steps* + + +- Review `azure.activitylogs.identity.authorization.evidence.principal_id` and Entra sign-in logs for the caller. +- Examine `azure.resource.id` and `azure.resource.name` to identify the VM and extension type deployed. +- Pivot on the VM for `MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION` and endpoint Run Command or `waagent` activity. +- Review role assignments for the principal on the subscription or resource group. + + +*Response and remediation* + + +- If unauthorized, remove the extension, rotate credentials, and review RBAC on the affected VM and scope. +- 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.COMPUTE/VIRTUALMACHINES/EXTENSIONS/WRITE" and +azure.activitylogs.identity.authorization.evidence.principal_type:User and +event.outcome:(success or Success) and +azure.resource.id:( + *VMACCESSAGENT* or + *CUSTOMSCRIPTEXTENSION* or + *RUNCOMMANDWINDOWS* or + *RUNCOMMANDLINUX* or + */DSC/* or + *MICROSOFTMONITORINGAGENT* +) + +---------------------------------- + +*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: 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: 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: Create Cloud Instance +** ID: T1578.002 +** Reference URL: https://attack.mitre.org/techniques/T1578/002/ diff --git a/docs/detections/prebuilt-rules/rule-details/cloud-instance-metadata-credential-path-http-request.asciidoc b/docs/detections/prebuilt-rules/rule-details/cloud-instance-metadata-credential-path-http-request.asciidoc new file mode 100644 index 0000000000..af73d41d10 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/cloud-instance-metadata-credential-path-http-request.asciidoc @@ -0,0 +1,139 @@ +[[cloud-instance-metadata-credential-path-http-request]] +=== Cloud Instance Metadata Credential Path HTTP Request + +Detects HTTP GET requests to the link-local instance metadata service (169.254.169.254) for cloud credential or token paths on AWS, GCP, or Azure. Adversaries and vulnerable workloads use scripts, shells, or application runtimes to read IAM role credentials or OAuth tokens from the metadata API. Requires the Network Packet Capture integration with HTTP decoding on ports 80 and 443 and process enrichment enabled so "process.*" fields are present. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.http* +* packetbeat-* + +*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.elastic.co/docs/reference/integrations/network_traffic +* https://hackingthe.cloud/aws/general-knowledge/intro_metadata_service/ + +*Tags*: + +* Domain: Cloud +* Domain: Network +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential 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 Cloud Instance Metadata Credential Path HTTP Request* + + +This rule matches outbound HTTP GETs to `169.254.169.254` where the URL path requests IAM credentials or cloud OAuth +tokens, filtered to common scripting runtimes, suspicious executable paths, or tool-like user agents. + + +*Investigation steps* + + +- Confirm `url.path` (AWS `security-credentials`, GCP `oauth2/access_token`, Azure `metadata/identity/oauth2/token`). +- Review `process.name`, `process.executable`, and `user_agent.original` — scripted tools and temp-path binaries are higher risk. +- Check `host.name` or `host.hostname` and whether the workload should run on a cloud VM with an instance profile or managed identity. +- Correlate with cloud audit or sign-in logs for role assumption or token use shortly after the request. +- If credentials may have been exposed, rotate the instance role or managed identity and review API activity from that principal. + + +*False positives* + + +- Platform agents and bootstrap scripts on new instances; allowlist by user agent or host group where validated. + + +*Response* + + +- Restrict IMDS access (IMDSv2 hop limit, network policy) and remove unnecessary instance permissions. +- Investigate the host for follow-on credential use or lateral movement. + +Deploy the https://www.elastic.co/docs/reference/integrations/network_traffic[Network Packet Capture] integration via Fleet on cloud workloads. + +- Enable **Capture HTTP Traffic** and include ports **80** and **443**. +- Enable **Monitor Processes** so network events include the process that initiated the connection. +- Prefer ECS field remapping (`map_to_ecs`) on integration data streams. + +==== Setup + + +Deploy the Network Packet Capture integration via Fleet on cloud workloads. + +Enable Capture HTTP Traffic and include ports 80 and 443.Enable Monitor Processes so network events include the process that initiated the connection.Prefer ECS field remapping (`map_to_ecs`) on integration data streams. + +==== Rule query + + +[source, js] +---------------------------------- +network where event.module == "network_traffic" and destination.ip == "169.254.169.254" and destination.port == 80 and +http.request.method == "GET" and url.path : ( + "/latest/meta-data/iam/security-credentials/*", + "*computeMetadata/v1/instance/service-accounts/*/oauth2/access_token*", + "*metadata/identity/oauth2/token*" +) and ( + ?process.name : ( + "curl", "wget", "python*", "node", "bun", "php*", "ruby", "perl", "bash", "dash", "sh", "tcsh", "tclsh", "wish", + "csh", "zsh", "ksh", "fish", "mksh", "busybox", + "bun.exe", "node.exe", "powershell.exe", "cmd.exe", "curl.exe", "wget.exe", "rundll32.exe", "w3wp.exe", "java*", + "go", "nc", "netcat", "nginx", "apache*", "httpd", "tomcat*", "catalina", "spring*", "dotnet", "gunicorn", "uwsgi", + ".*", "osascript" + ) or ?process.executable : ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/home/*/*", "/var/run/*", "/run/*", "/boot/*", "/.*", "C:\\Users\\*", "?:\\ProgramData\\*" + ) or user_agent.original : ( + "curl*", "wget*", "python*", "ruby*", "Go-http-client*", "node*", "axios*", "undici*", "java*", "php*", "Bun*", + "Apache-HttpClient*", "okhttp*", "RestTemplate*", "*WindowsPowerShell*", "*roadtools*", "*fasthttp*", "*azurehound*", "*bloodhound*", "*aiohttp*" + ) +) + +---------------------------------- + +*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: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-uncommon-destination-port-connection-by-web-server.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-uncommon-destination-port-connection-by-web-server.asciidoc new file mode 100644 index 0000000000..eff597eeab --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/deprecated-uncommon-destination-port-connection-by-web-server.asciidoc @@ -0,0 +1,189 @@ +[[deprecated-uncommon-destination-port-connection-by-web-server]] +=== Deprecated - Uncommon Destination Port Connection by Web Server + +This rule identifies unusual destination port network activity originating from a web server process. The rule is designed to detect potential web shell activity or unauthorized communication from a web server process to external systems. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* + +*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: Persistence +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 7 + +*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 Deprecated - Uncommon Destination Port Connection by Web Server* + + +Web servers, crucial for hosting applications, typically communicate over standard ports like 80 and 443. Adversaries may exploit web server processes to establish unauthorized connections to unusual ports, potentially indicating web shell activity or data exfiltration. This detection rule identifies such anomalies by monitoring egress connections from web server processes to non-standard ports, excluding common local IP ranges, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the process name and user associated with the alert to determine if the connection attempt was made by a legitimate web server process or user, as specified in the query fields (e.g., process.name or user.name). +- Examine the destination IP address to assess whether it is known or suspicious, and check if it falls outside the excluded local IP ranges. +- Investigate the destination port to understand why the connection was attempted on a non-standard port, and determine if this port is associated with any known services or threats. +- Check historical logs for any previous connection attempts from the same process or user to the same or similar destination IPs and ports to identify patterns or repeated behavior. +- Analyze any related network traffic or logs to identify additional context or anomalies that may indicate unauthorized activity or data exfiltration. +- Correlate the alert with other security events or alerts to determine if it is part of a larger attack pattern or campaign. + + +*False positive analysis* + + +- Routine administrative tasks or maintenance scripts may trigger alerts if they involve web server processes connecting to non-standard ports. To manage this, identify and document these tasks, then create exceptions for the specific processes and ports involved. +- Internal monitoring or management tools that use non-standard ports for legitimate purposes can cause false positives. Review the tools in use and exclude their known IP addresses and ports from the rule. +- Development or testing environments often use non-standard ports for web server processes. Ensure these environments are well-documented and consider excluding their IP ranges or specific ports from the rule. +- Load balancers or reverse proxies might redirect traffic to non-standard ports as part of their normal operation. Verify the configuration of these devices and exclude their IP addresses and ports if necessary. +- Custom applications running on web servers may require communication over non-standard ports. Work with application owners to understand these requirements and adjust the rule to exclude these specific cases. + + +*Response and remediation* + + +- Immediately isolate the affected web server from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of the web server's logs and processes to identify any unauthorized changes or suspicious activities, focusing on the processes and user accounts mentioned in the detection rule. +- Terminate any suspicious processes identified during the investigation that are not part of the standard operation of the web server. +- Change passwords and review permissions for the user accounts associated with the web server processes to ensure they have not been compromised. +- Restore the web server from a known good backup if any unauthorized changes or malware are detected, ensuring that the backup is free from compromise. +- Implement network segmentation to limit the web server's access to critical systems and data, reducing the potential impact of future incidents. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected, ensuring comprehensive threat containment and remediation. + + +==== 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] +---------------------------------- +network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and ( + process.name like ( + "apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "mongrel_rails", "gunicorn", + "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn", + "daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel", "php-fpm*", "php-cgi", + "php-fcgi", "php-cgi.cagefs", "catalina.sh", "hiawatha", "lswsctrl" + ) or + user.name in ("apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9") or + user.id in ("33", "498", "48") +) and +network.direction == "egress" and destination.ip != null and +not destination.port in (80, 443, 8080, 8443, 8000, 8888, 3128, 3306, 5432, 8220, 8082) and +not cidrmatch(destination.ip, "127.0.0.0/8", "::1","FE80::/10", "FF00::/8", "10.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", +"192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", +"224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "224.0.0.0/4", "240.0.0.0/4") + +---------------------------------- + +*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/ +* Technique: +** Name: Non-Standard Port +** ID: T1571 +** Reference URL: https://attack.mitre.org/techniques/T1571/ diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-unusual-command-execution-from-web-server-parent.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-unusual-command-execution-from-web-server-parent.asciidoc new file mode 100644 index 0000000000..2b7a7bfebf --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/deprecated-unusual-command-execution-from-web-server-parent.asciidoc @@ -0,0 +1,253 @@ +[[deprecated-unusual-command-execution-from-web-server-parent]] +=== Deprecated - Unusual Command Execution from Web Server Parent + +This rule detects potential command execution from a web server parent process on a Linux host. Adversaries may attempt to execute commands from a web server parent process to blend in with normal web server activity and evade detection. This behavior is commonly observed in web shell attacks where adversaries exploit web server vulnerabilities to execute arbitrary commands on the host. The detection rule identifies unusual command execution from web server parent processes, which may indicate a compromised host or an ongoing attack. 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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({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: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 14 + +*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 Deprecated - Unusual Command Execution from Web Server Parent* + + +Web servers, such as Apache or Nginx, are crucial for hosting web applications, often running on Linux systems. Adversaries exploit vulnerabilities in these servers to execute arbitrary commands, typically through web shells, blending malicious activity with legitimate server processes. The detection rule identifies suspicious command executions originating from web server processes, focusing on unusual patterns and contexts, such as unexpected working directories or command structures, to flag potential compromises. + + +*Possible investigation steps* + + +- Review the process.command_line field to understand the specific command executed and assess its legitimacy or potential malicious intent. +- Examine the process.working_directory to determine if the command was executed from an unusual or suspicious directory, which could indicate a compromise. +- Check the process.parent.executable and process.parent.name fields to identify the parent process and verify if it is a known web server or related service that could be exploited. +- Investigate the user.name and user.id fields to confirm if the command was executed by a legitimate user or service account, or if it was potentially executed by an unauthorized user. +- Correlate the @timestamp with other logs and events to identify any related activities or anomalies occurring around the same time, which could provide additional context or evidence of an attack. +- Assess the agent.id to determine if the alert is isolated to a single host or if similar activities are observed across multiple hosts, indicating a broader issue. + + +*False positive analysis* + + +- Web development or testing environments may frequently execute commands from web server processes. To handle this, exclude specific working directories like /var/www/dev or /var/www/test from the rule. +- Automated scripts or cron jobs running under web server user accounts can trigger alerts. Identify these scripts and add exceptions for their specific command lines or user IDs. +- Legitimate administrative tasks performed by web server administrators might appear suspicious. Document these tasks and exclude their associated command lines or parent executables. +- Continuous integration or deployment processes that involve web server interactions can be mistaken for threats. Exclude known CI/CD tool command lines or working directories from the rule. +- Monitoring or logging tools that interact with web server processes may generate false positives. Identify these tools and exclude their specific process names or parent executables. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further malicious activity and lateral movement within the network. This can be done by removing the host from the network or applying network segmentation. + +- Terminate any suspicious processes identified by the detection rule, especially those originating from web server parent processes executing shell commands. Use process IDs and command lines from the alert to target specific processes. + +- Conduct a thorough review of the web server logs and application logs to identify any unauthorized access or modifications. Look for patterns that match the command execution detected and any other anomalies. + +- Patch the web server and any associated applications to address known vulnerabilities that may have been exploited. Ensure that all software is up to date with the latest security patches. + +- Restore the affected system from a known good backup if any unauthorized changes or persistent threats are detected. Ensure that the backup is free from compromise before restoration. + +- Implement additional monitoring and alerting for similar activities, focusing on unusual command executions and web server behavior. Enhance logging and alerting to capture more detailed information about process executions and network connections. + +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the attack is part of a larger campaign. Provide them with all relevant data and findings from the initial containment and remediation steps. + + +==== 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] +---------------------------------- +from logs-endpoint.events.process-* metadata _id, _index, _version +| mv_expand event.action +| where + host.os.type == "linux" and + event.type == "start" and + event.action == "exec" and ( + ( + process.parent.name in ( + "apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "mongrel_rails", "gunicorn", + "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn", + "daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel", "php-cgi", + "php-fcgi", "php-cgi.cagefs", "catalina.sh", "hiawatha", "lswsctrl" + ) or + process.parent.name like "php-fpm*" or + user.name in ("apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9") or + user.id in ("33", "498", "48") or + (process.parent.name == "java" and process.parent.working_directory like "/u0?/*") or + process.parent.working_directory like "/var/www/*" + ) + ) and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + process.command_line like "* -c *" and not ( + process.working_directory like "/home/*" or + process.working_directory == "/" or + process.working_directory like "/vscode/vscode-server/*" or + process.parent.executable like "/vscode/vscode-server/*" or + process.parent.executable == "/usr/bin/xfce4-terminal" + ) + +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + process.parent.name, + user.name, + user.id, + process.working_directory, + process.parent.working_directory, + process.name, + process.executable, + process.command_line, + process.parent.executable, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by process.command_line, process.working_directory, process.parent.executable + +| where + Esql.agent_id_count_distinct == 1 and + Esql.event_count < 5 +| sort Esql.event_count asc + +// Extract unique values to ECS fields for alerts exclusion +| eval agent.id = mv_min(Esql.agent_id_values), + host.name = mv_min(Esql.host_name_values) + +| keep agent.id, host.name, process.command_line, process.working_directory, process.parent.executable, Esql.* + +---------------------------------- + +*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/rule-details/deprecated-unusual-process-spawned-from-web-server-parent.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-unusual-process-spawned-from-web-server-parent.asciidoc new file mode 100644 index 0000000000..61e6e54487 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/deprecated-unusual-process-spawned-from-web-server-parent.asciidoc @@ -0,0 +1,281 @@ +[[deprecated-unusual-process-spawned-from-web-server-parent]] +=== Deprecated - Unusual Process Spawned from Web Server Parent + +This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish persistence, execute malicious commands, or establish command and control channels on the host system. 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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({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: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 14 + +*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 Deprecated - Unusual Process Spawned from Web Server Parent* + + +Web servers like Apache, Nginx, and others are crucial for hosting applications and services. Adversaries exploit these servers by spawning unauthorized processes to maintain persistence or execute malicious commands. The detection rule identifies anomalies by monitoring low-frequency process spawns from web server parents, focusing on unusual user IDs, directories, and process counts, which may indicate potential threats. + + +*Possible investigation steps* + + +- Review the process.executable and process.command_line fields to understand the nature of the process that was spawned and assess if it aligns with expected behavior for the web server environment. +- Examine the process.working_directory to determine if the directory is a legitimate location for web server operations or if it appears suspicious, such as being outside typical web server directories. +- Check the user.name and user.id fields to verify if the process was executed by a legitimate web server user or if it was initiated by an unexpected or unauthorized user account. +- Investigate the process.parent.executable to confirm whether the parent process is a known and trusted web server executable or if it has been tampered with or replaced. +- Correlate the event with other logs or alerts from the same agent.id to identify any additional suspicious activities or patterns that may indicate a broader compromise. +- Assess the host.os.type to ensure the alert pertains to a Linux system, as specified in the query, and verify if there are any known vulnerabilities or misconfigurations on the host that could have been exploited. + + +*False positive analysis* + + +- Processes related to legitimate web server maintenance tasks may trigger alerts. Review scheduled tasks or cron jobs that align with the alert timing and consider excluding these specific processes if they are verified as non-threatening. +- Development environments often spawn processes that mimic attack patterns. Identify and exclude processes originating from known development directories or executed by development user accounts. +- Automated scripts or monitoring tools running under web server user accounts can be mistaken for malicious activity. Verify these scripts and add exceptions for their specific process names or working directories. +- Frequent updates or deployments in web applications can lead to unusual process spawns. Document these activities and exclude related processes if they consistently match the alert criteria during known update windows. +- Custom web server modules or plugins may execute processes that appear suspicious. Validate these modules and exclude their associated processes if they are part of normal operations. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement. +- Terminate any suspicious processes identified by the alert that are not part of legitimate web server operations. +- Conduct a thorough review of the process command lines and executables flagged by the alert to identify any malicious scripts or binaries. Remove or quarantine these files as necessary. +- Check for unauthorized changes in web server configurations or files within the working directories flagged by the alert. Restore any altered files from a known good backup. +- Review user accounts and permissions associated with the web server processes to ensure no unauthorized accounts or privilege escalations have occurred. Reset passwords and revoke unnecessary access. +- Monitor network traffic from the affected host for any signs of command and control communication, and block any identified malicious IP addresses or domains. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are 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 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] +---------------------------------- +from logs-endpoint.events.process-* metadata _id, _index, _version +| mv_expand event.action +| where + host.os.type == "linux" and + event.type == "start" and + event.action == "exec" and ( + ( + process.parent.name in ( + "apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "mongrel_rails", "gunicorn", + "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn", + "daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel", "php-cgi", + "php-fcgi", "php-cgi.cagefs", "catalina.sh", "hiawatha", "lswsctrl" + ) or + process.parent.name like "php-fpm*" or + user.name in ("apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9") or + user.id in ("33", "498", "48") or + (process.parent.name == "java" and process.parent.working_directory like "/u0?/*") or + process.parent.working_directory like "/var/www/*" + ) + ) and ( + process.name in ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "socat", "openssl", "busybox", + "nc", "ncat", "netcat", "nc.openbsd", "nc.traditional", "nohup", "setsid", "mkfifo", "mknod", + "node", "socket" + ) or + process.name like "python*" or + process.name like "php*" or + process.name like "perl" or + process.name like "ruby*" or + process.name like "lua*" or + process.executable like "/tmp/*" or + process.executable like "/var/tmp/*" or + process.executable like "/dev/shm/*" or + process.executable like "/var/log/*" or + process.executable like "/sys/*" or + process.executable like "/media/*" or + process.executable like "/proc/*" or + process.executable like "/var/backups/*" or + process.executable like "/var/mail/*" or + process.executable like "/var/spool/*" or + process.executable like "/var/www/*" or + process.executable like "./*" or + process.name like ".*" + ) and + not ( + process.working_directory like "/home/*" or + process.working_directory == "/" or + process.working_directory like "/var/www/*.ch" or + process.parent.executable like "/vscode/vscode-server/*" + ) + +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + process.parent.name, + user.name, + user.id, + process.working_directory, + process.parent.working_directory, + process.name, + process.executable, + process.command_line, + process.parent.executable, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by process.executable, process.working_directory, process.parent.executable + +| where + Esql.agent_id_count_distinct == 1 and + Esql.event_count < 5 +| sort Esql.event_count asc + +// Extract unique values to ECS fields for alerts exclusion +| eval agent.id = mv_min(Esql.agent_id_values), + host.name = mv_min(Esql.host_name_values) + +| keep agent.id, host.name, process.executable, process.working_directory, process.parent.executable, Esql.* + +---------------------------------- + +*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/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Sub-technique: +** Name: Lua +** ID: T1059.011 +** Reference URL: https://attack.mitre.org/techniques/T1059/011/ +* 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/rule-details/dumping-account-hashes-via-built-in-commands.asciidoc b/docs/detections/prebuilt-rules/rule-details/dumping-account-hashes-via-built-in-commands.asciidoc index 43821cda68..e550c5911c 100644 --- a/docs/detections/prebuilt-rules/rule-details/dumping-account-hashes-via-built-in-commands.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/dumping-account-hashes-via-built-in-commands.asciidoc @@ -33,7 +33,7 @@ Identifies the execution of macOS built-in commands used to dump user account ha * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 111 +*Version*: 112 *Rule authors*: @@ -131,8 +131,15 @@ 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 in ("defaults", "mkpassdb") and process.args like~ ("ShadowHashData", "-dump") +process where host.os.type == "macos" and event.type in ("start","process_started") and ( + (process.name == "defaults" and process.args like~ "ShadowHashData") or + (process.name == "mkpassdb" and process.args == "-dump") or + (process.name == "dscl" and process.args like~ "ShadowHashData") or + ( + process.name in ("plutil","cat","strings","xxd","head") and + process.args like "/var/db/dslocal/nodes/Default/users/*.plist" + ) +) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-device-registration-with-roadtools-default-os-build.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-device-registration-with-roadtools-default-os-build.asciidoc new file mode 100644 index 0000000000..8eea359975 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/entra-id-device-registration-with-roadtools-default-os-build.asciidoc @@ -0,0 +1,135 @@ +[[entra-id-device-registration-with-roadtools-default-os-build]] +=== Entra ID Device Registration with ROADtools Default OS Build + +Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19041.928" and the device display name follows the default "DESKTOP-" pattern. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and it is uncommon for the OS build to match the hardcoded value across an environment of otherwise patched hosts. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved provisioning tooling and device naming conventions before relying on it. + +*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://unit42.paloaltonetworks.com/roadtools-cloud-attacks/ +* https://github.com/dirkjanm/ROADtools +* https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/ + +*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 +* 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 Entra ID Device Registration with ROADtools Default OS Build* + + +ROADtools (roadtx) registers a device in Entra ID with a default cloud device OS build of `10.0.19041.928` and a default +display name of `DESKTOP-<8 random characters>`. This OS build is the current default value roadtx uses and +differs from the OS version of legitimate hosts, making the build a useful indicator of ROADtools device registration. +Rogue device registration is typically a precursor to Primary Refresh Token (PRT) acquisition, MFA/Conditional Access +bypass, and persistent token-based access. + +The matching Entra ID audit event is an `Add device` operation initiated by the `Device Registration Service`, where the +modified properties record the registered device characteristics: + +- `azure.auditlogs.properties.target_resources.0.modified_properties.3` (`CloudDeviceOSVersion`) = `10.0.19041.928` +- `azure.auditlogs.properties.target_resources.0.modified_properties.4` (`CloudDisplayName`) = `DESKTOP-*` + + +*Possible investigation steps* + + +- Confirm the registering identity via `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and determine +whether that user is expected to register a new device. +- Review `azure.auditlogs.identity` to confirm the `Device Registration Service` initiated the request, and use +`azure.correlation_id` to pivot across the full registration flow (`Add device`, `Add registered users to device`, +`Add registered owner to device`). +- Inspect the device name in `azure.auditlogs.properties.target_resources.0.display_name`; default `DESKTOP-` names that +do not match your naming convention are suspicious. +- Pivot to `azure.signinlogs` for the same user and timeframe and look for follow-on sign-ins where the incoming token +type is a `primaryRefreshToken`, or for risky/AiTM sign-ins immediately preceding the registration. +- Review `azure.auditlogs.properties.initiated_by.user.ipAddress` and geolocation for the registration source. Flag +unexpected IPs, hosting/VPS ASNs, or impossible-travel relative to the user's normal activity. +- Correlate with the user-agent-based device registration rules (e.g., `Dsreg/*`, `DeviceRegistrationClient`, +`Microsoft.OData.Client/*`) for the same user or correlation ID to strengthen attribution to ROADtools. + + +*False positive analysis* + + +- Unmanaged or imaged Windows 10 20H1 hosts may legitimately present the `10.0.19041.928` build with a default +`DESKTOP-` hostname. Validate against device inventory and known provisioning programs. +- Authorized security assessments using ROADtools will match. Document the engagement and add scoped exceptions. + + +*Response and remediation* + + +- If confirmed malicious, remove the registered device from Entra ID and revoke the user's refresh tokens and primary +refresh tokens. +- Disable the account or reset credentials per policy and review for additional persistence (added owners, app +registrations, or service principal credentials). +- Conduct historical analysis using `azure.correlation_id` and the registering user to determine scope of access. +- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices and +require MFA for registration). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.auditlogs" and event.action:"Add device" and + azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value:*10.0.19041.928* and + azure.auditlogs.properties.target_resources.0.modified_properties.4.new_value:*DESKTOP-* + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-device-with-roadtools-default-os-build-entity-analytics.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-device-with-roadtools-default-os-build-entity-analytics.asciidoc new file mode 100644 index 0000000000..a85c4df4ac --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/entra-id-device-with-roadtools-default-os-build-entity-analytics.asciidoc @@ -0,0 +1,131 @@ +[[entra-id-device-with-roadtools-default-os-build-entity-analytics]] +=== Entra ID Device with ROADtools Default OS Build (Entity Analytics) + +Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is `10.0.19041.928`. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and the OS build typically differs from the patched OS versions of legitimate hosts in the environment. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved device builds and naming conventions before relying on it. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-entityanalytics_entra_id.device-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-6h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/roadtools-cloud-attacks/ +* https://github.com/dirkjanm/ROADtools +* https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Entity Analytics +* Use Case: Asset Visibility +* 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 Entra ID Device with ROADtools Default OS Build (Entity Analytics)* + + +ROADtools (roadtx) registers a device in Entra ID with a default OS build of `10.0.19041.928` and a default name of +`DESKTOP-<8 random characters>`. This OS build is the current default value roadtx uses and differs from +the OS version of legitimate hosts, making the build a useful indicator of ROADtools device registration. This rule runs +against the Entra ID Entity Analytics device inventory and fires the first time a device matching this fingerprint +appears, so an alert generally represents a newly observed rogue device rather than a real-time registration event. +Rogue device registration is typically a precursor to Primary Refresh Token (PRT) acquisition, MFA/Conditional Access +bypass, and persistent token-based access. + + +*Possible investigation steps* + + +- Confirm the device identity via `host.name`, `host.os.version`, `entityanalytics_entra_id.device.display_name`, and +`entityanalytics_entra_id.device.id` (or `device.id`). Default `DESKTOP-` names that do not match your naming convention +are suspicious. +- Review `entityanalytics_entra_id.device.registration_date_time` and `entityanalytics_entra_id.device.trust_type` to +establish when and how the device was registered (e.g., Azure AD registered vs. joined). +- Identify the registered owner via `entityanalytics_entra_id.device.registered_owners.user_principal_name` and determine +whether that user is expected to register a new device. +- Check `entityanalytics_entra_id.device.is_managed` and `entityanalytics_entra_id.device.is_compliant`; ROADtools +devices are typically unmanaged and non-compliant. +- Pivot to `logs-azure.auditlogs-*` for the corresponding `Add device` event (initiated by the `Device Registration +Service`) and to `logs-azure.signinlogs-*` for sign-ins by the device owner where the incoming token type is a +`primaryRefreshToken`. +- Correlate with the companion audit-log rule "Entra ID Device Registration with ROADtools Default OS Build" +for the same device name to confirm registration-time activity. + + +*False positive analysis* + + +- Unmanaged or imaged Windows 10 20H1 hosts may legitimately report the `10.0.19041.928` build with a default +`DESKTOP-` host name. Validate against device inventory and patch baseline. +- Authorized security assessments using ROADtools will appear in inventory. Document the engagement and add scoped +exceptions. + + +*Response and remediation* + + +- If confirmed malicious, remove the device from Entra ID and revoke the owner's refresh tokens and primary refresh +tokens. +- Disable the account or reset credentials per policy and review for additional persistence (added owners, app +registrations, or service principal credentials). +- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices and +require MFA for registration). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"entityanalytics_entra_id.device" and + event.provider:"Microsoft Entra ID" and + host.name:DESKTOP-* and host.os.version:"10.0.19041.928" + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-kali365-default-user-agent-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-kali365-default-user-agent-detected.asciidoc new file mode 100644 index 0000000000..c4605c3977 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/entra-id-kali365-default-user-agent-detected.asciidoc @@ -0,0 +1,169 @@ +[[entra-id-kali365-default-user-agent-detected]] +=== Entra ID Kali365 Default User-Agent Detected + +Identifies the default user agent string associated with Kali365 (also referred to as Kali365 Live), a phishing-as-a-service (PhaaS) platform that automates OAuth 2.0 device code phishing and adversary-in-the-middle (AiTM) session capture against Microsoft 365 and Microsoft Entra ID. The Kali365 Electron desktop client identifies itself with the user agent `kali365-live/1.0.0` when polling for and replaying captured OAuth tokens, so its appearance in Entra ID sign-in logs, Entra ID audit logs, or the Microsoft 365 unified audit log indicates that an attacker-controlled Kali365 client is interacting with the tenant using stolen tokens. Unlike dual-use offensive tooling, Kali365 is a criminal service with no legitimate enterprise use, making this user agent a high-fidelity indicator of active account compromise. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* +* logs-azure.signinlogs-* +* 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://www.ic3.gov/PSA/2026/PSA260521 + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Data Source: Microsoft Entra ID Audit Logs +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Threat: Kali365 +* Tactic: Initial Access +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Kali365 Default User-Agent Detected* + + +Kali365 (Kali365 Live) is a phishing-as-a-service platform distributed via Telegram that provides affiliates with +AI-generated lures, automated device code phishing campaigns, target-tracking dashboards, and OAuth token capture. The +typical flow is: a lure delivers a Microsoft device code, the victim enters it on the legitimate Microsoft verification +page and unknowingly authorizes the attacker, Kali365 captures the resulting OAuth access and refresh tokens, and the +attacker uses those tokens for persistent, MFA-free access to Microsoft 365 (Outlook, Teams, OneDrive). + +The Kali365 desktop client presents the user agent `kali365-live/1.0.0`. This rule fires when that user agent is observed +in Entra ID sign-in logs, Entra ID audit logs, or the Microsoft 365 unified audit log. Because the user agent maps to a +criminal service with no legitimate use, an alert generally indicates that stolen tokens are already being replayed +against the tenant. + + +*Possible investigation steps* + + +- Confirm the tool and identify the affected identity. + - `user_agent.original` matches `kali365-live/*`. + - Pivot on `user.name`, `azure.signinlogs.properties.user_principal_name`, or the M365 audit `user.id`. +- Review the origin and compare against the user's normal sign-in behavior. + - `source.ip`, `source.geo.*`, and `source.as.organization.name`; flag hosting/VPS ASNs and unexpected geographies. + - Cross-reference published Kali365 infrastructure (`216.203.20.95`, `162.243.166.119`, `199.91.220.111`). +- Confirm the device code grant in sign-in logs. + - `azure.signinlogs.properties.authentication_protocol` is `deviceCode`. + - Review `app_id`/`app_display_name` and `resource_display_name` for the brokered mail or collaboration API. +- Scope follow-on access in the Microsoft 365 unified audit log for the same user and timeframe. + - Look for mailbox access, inbox rule creation, OneDrive/SharePoint downloads, or Teams activity from the same session or IP. +- Check the Entra ID audit log for a device registration by the same identity around the alert window. + - A `Register device` event by the identity paired (via `azure.correlation_id`) with an `Add device` event from the `Device Registration Service` indicates a Primary Refresh Token (PRT) was issued for persistence that survives password resets. + + +*False positive analysis* + + +- This user agent has no legitimate enterprise use. + - The only expected matches are authorized security research or red team exercises running the Kali365 client; validate and document before dismissing. + + +*Response and remediation* + + +- Remove rogue device registrations created by the user BEFORE revoking sessions. + - Device-bound PRTs survive `revokeSignInSessions`, so a device left in place re-establishes access. + - `GET /v1.0/users/{id}/registeredDevices` and `/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}` for unrecognized devices. +- Revoke refresh tokens and sessions, then reset credentials and re-register MFA. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the account if you need to halt activity during investigation. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Remove other attacker persistence: malicious inbox/forwarding rules, OAuth consents, and app passwords. +- Block or monitor Kali365 source IPs and infrastructure, and hunt for the user agent across other users and tenants. +- Apply Conditional Access to the device code grant. + - Require a managed/compliant device, or block the device-code flow outside approved app and user populations. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : ("azure.signinlogs" or "azure.auditlogs" or "o365.audit") and user_agent.original: kali365-live/* + +---------------------------------- + +*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: 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: 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-microsoft-authentication-broker-sign-in-with-non-standard-user-agent.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-microsoft-authentication-broker-sign-in-with-non-standard-user-agent.asciidoc new file mode 100644 index 0000000000..c98303145b --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/entra-id-microsoft-authentication-broker-sign-in-with-non-standard-user-agent.asciidoc @@ -0,0 +1,145 @@ +[[entra-id-microsoft-authentication-broker-sign-in-with-non-standard-user-agent]] +=== Entra ID Microsoft Authentication Broker Sign-In with Non-Standard User Agent + +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. + +*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/ +* https://any.run/malware-trends/tycoon/ + +*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: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Microsoft Authentication Broker Sign-In with Non-Standard User Agent* + + +Review `azure.signinlogs.properties.user_principal_name`, `user_agent.original`, +`azure.signinlogs.properties.resource_display_name`, `azure.signinlogs.properties.session_id`, `source.ip`, and +`source.as.organization.name`. + +Confirm whether the user or application intentionally used a non-browser client against the requested resource. + + +*Possible investigation steps* + + +- Inspect `user_agent.original` for automation libraries (for example `node`, `axios`, `python-requests`, `curl`). +- Correlate `azure.signinlogs.properties.session_id` with other sign-ins, device registration audit events, or Graph + activity in the same time window. +- Review conditional access outcomes and identity protection signals for the user. +- Compare `source.ip` and ASN against expected VPN, MDM, and developer egress. + + +*False positive analysis* + + +- Microsoft platform and mobile clients using Mozilla-, Dalvik-, CFNetwork-, or Windows-AzureAD-Authentication-Provider- + style user agents are excluded by design. +- First-party CLI tools and test harnesses that legitimately broker tokens may still match if they use uncommon user + agent strings. + + +*Response and remediation* + + +- If malicious, revoke refresh tokens for the user, review newly registered devices, and reset credentials per policy. +- Escalate when paired with suspicious ASN sign-ins, multi-IP OAuth flows, or follow-on Graph data access. + + +==== Setup + + +Microsoft Entra ID sign-in logs (`logs-azure.signinlogs-*`) must populate `user_agent.original`, +`azure.signinlogs.properties.app_display_name`, and `azure.signinlogs.properties.resource_display_name`. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.signinlogs" and event.action:"Sign-in activity" and event.outcome:(success or Success) and +(azure.signinlogs.properties.app_display_name:"Microsoft Authentication Broker" or azure.signinlogs.properties.app_id:"29d9ed98-a469-4536-ade2-f981bc1d605e") and +user_agent.original:(* and not (Mozilla* or Dalvik* or *CFNetwork* or Windows-AzureAD-Authentication-Provider* or Java*ThinkPad*)) and +azure.signinlogs.properties.resource_display_name:* + +---------------------------------- + +*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 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: 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: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc index c3877d98f8..989f0b9550 100644 --- a/docs/detections/prebuilt-rules/rule-details/entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc @@ -40,7 +40,7 @@ Identifies potential session hijacking or token replay in Microsoft Entra ID. Th * Tactic: Defense Evasion * Tactic: Initial Access -*Version*: 10 +*Version*: 11 *Rule authors*: @@ -133,8 +133,8 @@ from logs-azure.signinlogs-*, logs-azure.graphactivitylogs-* metadata _id, _vers data_stream.dataset == "azure.graphactivitylogs", "graph", "other" ), - Esql.signin_source_asn = case(data_stream.dataset == "azure.signinlogs", source.`as`.organization.name, null), - Esql.graph_source_asn = case(data_stream.dataset == "azure.graphactivitylogs", source.`as`.organization.name, null) + Esql.signin_source_asn = case(data_stream.dataset == "azure.signinlogs", source.`as`.organization.name), + Esql.graph_source_asn = case(data_stream.dataset == "azure.graphactivitylogs", source.`as`.organization.name) | where Esql.azure_signinlogs_properties_app_id_coalesce not in ( "4354e225-50c9-4423-9ece-2d5afd904870", // Augmentation Loop @@ -191,8 +191,8 @@ from logs-azure.signinlogs-*, logs-azure.graphactivitylogs-* metadata _id, _vers Esql.azure_signinlogs_properties_app_id_coalesce_count_distinct = count_distinct(Esql.azure_signinlogs_properties_app_id_coalesce), Esql.event_type_case_values = values(Esql.event_type_case), Esql.event_type_case_count_distinct = count_distinct(Esql.event_type_case), - Esql.signin_time_min = min(case(Esql.event_type_case == "signin", Esql.@timestamp, null)), - Esql.graph_time_min = min(case(Esql.event_type_case == "graph", Esql.@timestamp, null)), + Esql.signin_time_min = min(case(Esql.event_type_case == "signin", Esql.@timestamp)), + Esql.graph_time_min = min(case(Esql.event_type_case == "graph", Esql.@timestamp)), Esql.url_original_values = values(url.original), Esql.azure_graphactivitylogs_properties_scopes_values = values(azure.graphactivitylogs.properties.scopes), Esql.event_count = count() diff --git a/docs/detections/prebuilt-rules/rule-details/external-user-added-to-google-workspace-group.asciidoc b/docs/detections/prebuilt-rules/rule-details/external-user-added-to-google-workspace-group.asciidoc index 496292abb5..b0947642f9 100644 --- a/docs/detections/prebuilt-rules/rule-details/external-user-added-to-google-workspace-group.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/external-user-added-to-google-workspace-group.asciidoc @@ -8,7 +8,7 @@ Detects an external Google Workspace user account being added to an existing gro *Rule indices*: * filebeat-* -* logs-google_workspace* +* logs-google_workspace.admin-* *Severity*: medium @@ -32,9 +32,10 @@ Detects an external Google Workspace user account being added to an existing gro * Data Source: Google Workspace * Use Case: Identity and Access Audit * Tactic: Initial Access +* Tactic: Persistence * Resources: Investigation Guide -*Version*: 7 +*Version*: 8 *Rule authors*: @@ -123,7 +124,7 @@ The Google Workspace Fleet integration, Filebeat module, or similarly structured [source, js] ---------------------------------- iam where data_stream.dataset == "google_workspace.admin" and event.action == "ADD_GROUP_MEMBER" and - not endsWith(user.target.email, user.target.group.domain) + not endsWith(user.target.domain, user.target.group.domain) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/forwarded-google-workspace-security-alert.asciidoc b/docs/detections/prebuilt-rules/rule-details/forwarded-google-workspace-security-alert.asciidoc index 769bc10fe8..4bb7fa5cf2 100644 --- a/docs/detections/prebuilt-rules/rule-details/forwarded-google-workspace-security-alert.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/forwarded-google-workspace-security-alert.asciidoc @@ -7,14 +7,13 @@ Identifies the occurrence of a security alert from the Google Workspace alerts c *Rule indices*: -* filebeat-* -* logs-google_workspace* +* logs-google_workspace.alert-* *Severity*: high *Risk score*: 73 -*Runs every*: 10m +*Runs every*: 5m *Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) @@ -34,7 +33,7 @@ Identifies the occurrence of a security alert from the Google Workspace alerts c * Use Case: Threat Detection * Resources: Investigation Guide -*Version*: 7 +*Version*: 8 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-device-registration-burst-for-single-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-device-registration-burst-for-single-user.asciidoc new file mode 100644 index 0000000000..caf7f248b8 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-device-registration-burst-for-single-user.asciidoc @@ -0,0 +1,185 @@ +[[google-workspace-device-registration-burst-for-single-user]] +=== Google Workspace Device Registration Burst for Single User + +Detects bursts of Google Workspace device registration events for the same user, where three or more distinct "google_workspace.device.id" values are emitted in a one-minute window. Although "DEVICE_REGISTER_UNREGISTER_EVENT" fires routinely on session/sync registration and is not a true physical device enrollment, legitimate user activity typically produces fewer than three distinct device IDs in a single minute. A high-cardinality burst is the fingerprint behavior of AiTM phishing-kit relays (Tycoon2FA Google variant, EvilGinx phishlets) and stolen-OAuth-token replay tooling, both of which mint a new session attestation per relay or replay attempt. + +*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://developers.google.com/workspace/admin/reports/v1/appendix/activity/mobile +* https://any.run/malware-trends/tycoon/ +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Google Workspace +* Data Source: Google Workspace Device Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Tactic: Initial Access +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Device Registration Burst for Single User* + + +`DEVICE_REGISTER_UNREGISTER_EVENT` from the Google Workspace `mobile` provider does not represent a one-time physical device enrollment. The Reports API emits a fresh `google_workspace.device.id` on every session/sync registration, and a single physical device can produce multiple events per day as Workspace-aware apps independently attest. Legitimate activity, however, very rarely concentrates three or more distinct device IDs into a one-minute window for a single user. A burst of that shape is the fingerprint of either: + +- An AiTM phishing-kit relay session: the kit completes the victim's sign-in against Google, then attests one or more device contexts of its own, all from the same kit infrastructure within seconds. +- Token-replay tooling driving multiple sessions in quick succession against a stolen OAuth refresh token. + +In both cases the device fingerprint (OS, model) typically converges on a single value distinct from the victim's baseline (e.g., all "Windows" attestations for a known macOS user), and the burst events fire within a few seconds of each other rather than spread across minutes. + + +*Possible investigation steps* + + +- Identify the user (`user.email`, `user.id`) and inspect `Esql.host_os_version_values`, `Esql.device_type_values`, `Esql.device_model_values`. A homogeneous fingerprint (single OS, single model) across multiple device IDs in the burst window is highly suspicious. +- Cross-reference `logs-google_workspace.login` for `event.action: "login_success"` events from the same `user.email` in the 30 minutes preceding the burst. The kit-relay sign-ins should appear there. Inspect each sign-in's `source.geo.country_name`, `source.as.organization.name`, and `user_agent.original` for divergence from the user's baseline. Hosting-provider ASNs (Clouvider, Host Telecom, OVH, Alibaba, Vultr, DigitalOcean, M247) for interactive sign-ins are high-fidelity suspicious. +- Cross-reference `logs-google_workspace.token` for `event.action: "authorize"` events for the same user near the burst window. Each kit relay normally fires a corresponding OAuth grant within seconds, often to Google Chrome (`77185425430.apps.googleusercontent.com`) or another long-lived first-party client. +- Pull all `logs-google_workspace.device` events for the user across the 24 hours preceding the burst to characterize the user's normal device-event rate. A user who typically produces less than 1 event per hour suddenly emitting 3+ in a minute is a strong anomaly even before considering device fingerprints. +- Confirm with the user whether they were performing a new device setup, OS upgrade, or onboarding activity during the burst window. + + +*False positive analysis* + + +- New device setup where a user simultaneously enrolls multiple Workspace-aware apps (Gmail, Drive, Calendar, Meet) on first boot can produce a burst. Validate by checking whether the burst coincides with a known device refresh or onboarding event. +- Major OS upgrades that re-attest several apps concurrently can also produce a burst. The host OS version values will reflect the upgrade transition. +- Bulk MDM rollouts or fleet refreshes may produce bursts across many users at the same time. Consider rule suppression during planned rollouts. + + +*Response and remediation* + + +- Treat as likely AiTM compromise or token-replay activity until proven otherwise. Suspend the user, revoke all OAuth tokens (`DELETE /admin/directory/v1/users//tokens/`), reset the password, clear recovery email/phone, sign out all sessions. +- Audit `logs-google_workspace.token: authorize` events for kit-issued or replay-issued OAuth grants. Each grant maps to an independently replayable refresh token; revoking via the consent removes them all at once. +- Audit the device IDs surfaced in the burst via the Admin SDK Directory API and remove any that are confirmed adversary-controlled. +- If the tenant exposes GCP resources to the user, cross-check `logs-gcp.audit-*` for `authenticationInfo.principalEmail` matching the user from a non-baseline `callerIp` in the same window; token theft frequently extends to cross-cloud access. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-google_workspace.device-* +| where event.dataset == "google_workspace.device" + and event.action == "DEVICE_REGISTER_UNREGISTER_EVENT" + and google_workspace.device.account_state == "REGISTERED" + and user.email is not null + and google_workspace.device.id is not null + +| eval Esql.bucket_minute = date_trunc(1 minute, @timestamp) + +| stats + Esql.count_distinct_device_id = count_distinct(google_workspace.device.id), + Esql.device_id_values = values(google_workspace.device.id), + Esql.device_resource_id_values = values(google_workspace.device.resource.id), + Esql.device_type_values = values(google_workspace.device.type), + Esql.device_model_values = values(google_workspace.device.model), + Esql.device_account_state_values = values(google_workspace.device.account_state), + Esql.host_os_version_values = values(host.os.version), + Esql.event_provider_values = values(event.provider), + Esql.event_id_values = values(event.id), + Esql.google_workspace_actor_type_values = values(google_workspace.actor.type), + Esql.google_workspace_event_type_values = values(google_workspace.event.type), + Esql.organization_id_values = values(organization.id), + Esql.user_domain_values = values(user.domain), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp), + Esql.event_count = count(*) + by user.id, user.email, user.name, Esql.bucket_minute + +| where Esql.count_distinct_device_id >= 3 + +| keep user.id, + user.email, + user.name, + Esql.bucket_minute, + Esql.timestamp_first_seen, + Esql.timestamp_last_seen, + Esql.count_distinct_device_id, + Esql.event_count, + Esql.device_id_values, + Esql.device_resource_id_values, + Esql.device_type_values, + Esql.device_model_values, + Esql.device_account_state_values, + Esql.host_os_version_values, + Esql.event_provider_values, + Esql.event_id_values, + Esql.google_workspace_actor_type_values, + Esql.google_workspace_event_type_values, + Esql.organization_id_values, + Esql.user_domain_values + +---------------------------------- + +*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: 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: 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/ diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-drive-data-transfer-or-takeout-export-initiated.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-drive-data-transfer-or-takeout-export-initiated.asciidoc new file mode 100644 index 0000000000..f187a9b1ce --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-drive-data-transfer-or-takeout-export-initiated.asciidoc @@ -0,0 +1,160 @@ +[[google-workspace-drive-data-transfer-or-takeout-export-initiated]] +=== Google Workspace Drive Data Transfer or Takeout Export Initiated + +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. + +*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/1247799?hl=en +* https://support.google.com/a/answer/10276199 +* 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 +* Tactic: Exfiltration +* Resources: Investigation Guide + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Drive Data Transfer or Takeout Export Initiated* + + +Google Drive is a cloud storage service available to Google Workspace users. Administrators can bulk-transfer a +departing user's Drive files to another in-domain account, or create Customer Takeout exports that package user or +organizational data for download or transfer to an external destination (for example, another cloud provider). + +Adversaries with compromised administrator credentials may abuse these workflows to collect sensitive files without +relying on per-file sharing changes. This rule detects two related admin audit actions: + +- `CREATE_DATA_TRANSFER_REQUEST` with Drive application scope — ownership or bulk transfer to another user. +- `CUSTOMER_TAKEOUT_CREATED` — initiation of a Customer Takeout export job. + + +*Possible investigation steps* + + +- Review admin logs for involved user accounts. +- For data transfer requests, confirm the request initiator, source and destination users in `user.email`, `user.target.email`, and `google_workspace.admin.new_value`. +- For Customer Takeout events (`CUSTOMER_TAKEOUT_CREATED`): + - In Elasticsearch, pivot on `google_workspace.admin.OBFUSCATED_CUSTOMER_TAKEOUT_REQUEST_ID` to find related admin events for the same export job (for example completion or failure). The Admin console Data export UI does not expose or accept this ID for search. + - In the Admin console, go to Data > Data import & export > Data export and identify the export by correlating `@timestamp`, Set up by (`user.email`), and Last start date / Status. The export Name shown in the console is not present in Workspace admin logs. + - Open the matching row and select View archive to review exported data scope and where the archive is stored (Google-provided bucket or customer-owned Cloud Storage). +- Determine if involved user accounts are active. +- Check if involved user accounts were recently disabled, suspended, or scheduled for deletion. +- Review involved user accounts for potentially misconfigured permissions or roles. +- Review the involved shared drives, My Drive files, or export scope to determine if this action was expected. +- Triage potentially related alerts based on the users involved. + + +*False positive analysis* + + +- Drive data transfers require Google Workspace administration permissions. Confirm the transfer was planned during offboarding or role change and targets the correct receiver. +- Customer Takeout exports are common for compliance, migration, and departures. Validate the initiator is authorized and the export scope matches policy. + + +*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:"CREATE_DATA_TRANSFER_REQUEST" and google_workspace.admin.application.name:Drive*) or + event.action:"CUSTOMER_TAKEOUT_CREATED" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* 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: Remote Data Staging +** ID: T1074.002 +** Reference URL: https://attack.mitre.org/techniques/T1074/002/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-login-flagged-suspicious.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-login-flagged-suspicious.asciidoc new file mode 100644 index 0000000000..6809285527 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-login-flagged-suspicious.asciidoc @@ -0,0 +1,149 @@ +[[google-workspace-login-flagged-suspicious]] +=== Google Workspace Login Flagged Suspicious + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.login* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 60m + +*Searches indices from*: now-180m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://knowledge.workspace.google.com/admin/security/user-login-attempts-report +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one + +*Tags*: + +* 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 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Login Flagged Suspicious* + + +Google sets `google_workspace.login.is_suspicious: true` when its server-side risk engine identifies a sign-in event as anomalous for the user. Triggers commonly include: + +- Sign-in from an anonymizer (Tor exit, public VPN, etc.) +- Sign-in from a known-malicious IP range +- Atypical device fingerprint for the user +- Sign-in from a geography or ASN inconsistent with the user's history + +As a building block, this signal is intended for use alongside other detection rules. On its own it is medium-confidence. + + +*Possible investigation steps* + + +- Inspect `source.ip`, `source.as.organization.name`, `source.geo.country_name`. Classify the network: residential ISP, corporate VPN, hosting provider (high concern), anonymizer (high concern). +- Inspect `google_workspace.login.type`. `google_password` is an interactive sign-in (highest concern). `reauth` is a silent token refresh (lower concern unless paired with other signals). +- Inspect `google_workspace.login.challenge_method`. Whether 2FA was relayed or skipped factors into the kit-vs-traveler determination. +- Pull the user's recent sign-in history. Is this a one-off flag or a sustained pattern from a new network? +- Cross-reference `logs-google_workspace.token` for `event.action: "authorize"` events from the same `user.email` immediately following the suspicious sign-in. An OAuth grant minted seconds after a Google-flagged sign-in is the AiTM kit signature. +- Cross-reference `logs-google_workspace.device` for `DEVICE_REGISTER_UNREGISTER_EVENT` with `account_state: "REGISTERED"` near the same time. New device registration paired with `is_suspicious` is high-fidelity compromise. +- Confirm with the user whether the sign-in was theirs. + + +*False positive analysis* + + +- Travelers, VPN users, new-device sign-ins, and users returning from leave will all trip Google's risk engine occasionally. +- Building-block signals are not tuned for false-positive minimization at the source; they trade noise for coverage. Combine with other signals before treating as actionable. + + +*Response and remediation* + + +- This rule does not generate user-facing alerts by default. Use it as enrichment for higher-level correlation rules. +- If a correlation surfaces this signal alongside other indicators (atypical ASN, atypical country, OAuth grant, device registration), follow the response steps in those rules. + + +==== Setup + + + +*Setup* + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- Google Workspace Reports API ingestion lag commonly runs in the 30-minute to 3-hour range. This rule's 130-minute lookback gives partial coverage but will miss events delayed beyond that envelope. +- See https://support.google.com/a/answer/7061566 for Google's published guidance on event availability. +- Check your integration's Login lag time to ensure it is configured to meet the needs of this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "google_workspace.login" and + event.provider: "login" and + google_workspace.login.is_suspicious: true + +---------------------------------- + +*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: 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/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-suspended-user-account-renewed.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-suspended-user-account-renewed.asciidoc index e232a49df0..106b00638a 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-suspended-user-account-renewed.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-suspended-user-account-renewed.asciidoc @@ -8,7 +8,7 @@ Detects when a previously suspended user's account is renewed in Google Workspac *Rule indices*: * filebeat-* -* logs-google_workspace* +* logs-google_workspace.admin-* *Severity*: low @@ -32,9 +32,10 @@ Detects when a previously suspended user's account is renewed in Google Workspac * Data Source: Google Workspace * Use Case: Identity and Access Audit * Tactic: Initial Access +* Tactic: Persistence * Resources: Investigation Guide -*Version*: 8 +*Version*: 9 *Rule authors*: @@ -112,7 +113,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.action:UNSUSPEND_USER +data_stream.dataset: google_workspace.admin and google_workspace.event.type: "USER_SETTINGS" and event.action: "UNSUSPEND_USER" ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-user-login-with-unusual-asn.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-user-login-with-unusual-asn.asciidoc new file mode 100644 index 0000000000..51524b0f2d --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-user-login-with-unusual-asn.asciidoc @@ -0,0 +1,143 @@ +[[google-workspace-user-login-with-unusual-asn]] +=== Google Workspace User Login with Unusual ASN + +Detects the first time a Google Workspace user successfully signs in from a given source ASN within a 14-day historical window. Most users have a stable set of egress ASNs (home ISP, corporate VPN, mobile carrier). A new ASN for a user is a meaningful anomaly as it surfaces ISP changes and travel, but also catches AiTM phishing-kit relays whose egress ASN was never previously associated with the user. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-google_workspace.login* +* logs-google_workspace.token* + +*Severity*: low + +*Risk score*: 21 + +*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://any.run/malware-trends/tycoon/ +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one + +*Tags*: + +* 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 +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace User Login with Unusual ASN* + + +This rule emits when a user signs in successfully from an ASN that has not been observed for that user in the prior 14 days. Most legitimate users cluster around a small number of egress ASNs (corporate VPN, home ISP, primary mobile carrier). New ASNs are not all malicious, but new ASNs that match hosting providers, anonymization networks, or geographies inconsistent with the user's profile are high-fidelity suspicious. + + +*Possible investigation steps* + + +- Inspect `source.as.organization.name` and `source.as.number`. Categorize: residential ISP (low concern absent other indicators), corporate VPN (validate against tenant baseline), mobile carrier (validate by region), hosting provider / VPS (Clouvider, Host Telecom, Alibaba, OVH, M247, DigitalOcean, Vultr) - high concern for interactive sign-ins. +- Inspect `source.geo.country_name` and `source.geo.region_name`. New geo + known travel is fine. New geo + unexpected travel needs user confirmation. +- Pull the user's full `google_workspace.login` history across the lookback. Is this a one-off sign-in or sustained activity from the new ASN? +- Cross-reference `logs-google_workspace.token` for any `event.action: "authorize"` events from the same `user.email` immediately following the sign-in. An OAuth grant minted from the new ASN within seconds of sign-in is the AiTM kit signature. +- Cross-reference `logs-google_workspace.device` for any `DEVICE_REGISTER_UNREGISTER_EVENT` with `account_state: "REGISTERED"` from the same user near the same time. New device + new ASN is a stronger compromise signal than either alone. +- Confirm with the user whether they signed in from a new network intentionally. + + +*False positive analysis* + + +- Users on rotating VPN exits, hotspot sharing, or coffee-shop Wi-Fi will produce new ASNs legitimately. +- Mobile users in unfamiliar regions (travel, conference attendance) will geo-resolve to new ASNs. +- Engineering teams using cloud workstations (Cloud Workstations, Codespaces, etc.) will egress through hosting ASNs even for legitimate sign-ins. Tune by allowlisting your tenant's known cloud-workstation egress. +- For high-noise tenants, expand `history_window_start` to 14 days to reduce false-positive rate at the cost of slower-to-fire detection for genuinely new ASNs. + + +*Response and remediation* + + +- If the new ASN is a hosting provider and the user has not knowingly used such a network: treat as likely AiTM. Suspend user, revoke OAuth tokens, reset password, clear recovery info, sign out all sessions. +- If the new ASN is benign (verified ISP change, travel, new VPN): add to the user's baseline. Consider broader hardening (require MFA re-verification on new-network sign-in via Workspace Context-Aware Access). + + +==== Setup + + + +*Setup* + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- Google Workspace Reports API ingestion lag commonly runs in the 30-minute to 3-hour range. This rule's 130-minute lookback gives partial coverage but will miss events delayed beyond that envelope. +- See https://support.google.com/a/answer/7061566 for Google's published guidance on event availability. +- Check your integration's Login lag time to ensure it is configured to meet the needs of this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: ("google_workspace.login" or "google_workspace.token") and + event.action: ("login_success" or "authorize") and + source.as.number: * and + user.email: * + +---------------------------------- + +*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: 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/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-user-organizational-unit-changed.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-user-organizational-unit-changed.asciidoc index 49e59dd8f1..bb8eadefe0 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-user-organizational-unit-changed.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-user-organizational-unit-changed.asciidoc @@ -8,7 +8,7 @@ Users in Google Workspace are typically assigned a specific organizational unit *Rule indices*: * filebeat-* -* logs-google_workspace* +* logs-google_workspace.admin-* *Severity*: low @@ -32,9 +32,10 @@ Users in Google Workspace are typically assigned a specific organizational unit * Data Source: Google Workspace * Use Case: Configuration Audit * Tactic: Persistence +* Tactic: Privilege Escalation * Resources: Investigation Guide -*Version*: 111 +*Version*: 112 *Rule authors*: @@ -123,8 +124,7 @@ The Google Workspace Fleet integration, Filebeat module, or similarly structured [source, js] ---------------------------------- -data_stream.dataset:"google_workspace.admin" and event.type:change and event.category:iam - and google_workspace.event.type:"USER_SETTINGS" and event.action:"MOVE_USER_TO_ORG_UNIT" +data_stream.dataset:"google_workspace.admin" and google_workspace.event.type:"USER_SETTINGS" and event.action:"MOVE_USER_TO_ORG_UNIT" ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-user-sign-in-from-atypical-device-type.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-user-sign-in-from-atypical-device-type.asciidoc new file mode 100644 index 0000000000..f89e30c81d --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-user-sign-in-from-atypical-device-type.asciidoc @@ -0,0 +1,138 @@ +[[google-workspace-user-sign-in-from-atypical-device-type]] +=== Google Workspace User Sign-in from Atypical Device Type + +Detects the first time a Google Workspace user is observed authenticating from a device of a given type (e.g., WINDOWS, MAC, ANDROID, IOS, LINUX) within a historical window. Note that "DEVICE_REGISTER_UNREGISTER_EVENT" events do not represent one-time physical device enrollments; the Google Reports API emits a fresh "google_workspace.device.id" on each event, and the same physical device may produce multiple events per day as sessions/sync renewals occur. The rule therefore surfaces a user authenticating from a new device type, not a new physical device. This is still high-fidelity because adversaries who compromise a Workspace identity via AiTM kits or stolen OAuth refresh tokens frequently relay sessions from device types that diverge from the legitimate user's baseline (e.g., a WINDOWS session appearing for a known macOS user, or simultaneous WINDOWS+MAC sessions within minutes), which is the canonical kit fingerprint. Because the underlying token retains access after password rotation, treat unexpected device-type divergence as a compromise indicator and revoke tokens, not just credentials. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-google_workspace.device* + +*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://developers.google.com/workspace/admin/reports/v1/appendix/activity/mobile +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://any.run/malware-trends/tycoon/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Google Workspace +* Data Source: Google Workspace Device Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace User Sign-in from Atypical Device Type* + + +This rule emits when a user authenticates from a device whose type (`google_workspace.device.type`) has not been observed for that user in the prior 14 days. + +**Important: this is not a true "device enrollment" event.** Google's Reports API emits `DEVICE_REGISTER_UNREGISTER_EVENT` from the `mobile` provider on every session/sync registration, with a fresh `google_workspace.device.id` each time. A single physical device can produce many such events per day. The rule therefore identifies a *device-type-per-user* anomaly: a session originating from a class of device the user has not been seen on in the prior 14 days, not a one-time physical device join. + +The detection value remains high because adversaries who relay sessions via AiTM kits (Tycoon2FA Google variant, EvilGinx phishlets) or who replay stolen OAuth refresh tokens typically egress from device fingerprints that diverge from the victim's baseline. Two patterns are especially diagnostic: + +- A device type appearing for a user that does not match the user's known OS (e.g., WINDOWS sessions for a user whose corporate laptop is macOS). +- Simultaneous WINDOWS+MAC (or similar cross-type) sessions for the same user within a short window, indicating the kit and the victim are active at the same time. + +Because the underlying OAuth refresh token continues to grant access after a password reset, password rotation alone does not remediate this; only token revocation does. + + +*Possible investigation steps* + + +- Identify the user (`user.email`), the device type (`google_workspace.device.type`), and the device model and OS (`google_workspace.device.model`, `host.os.version`). +- Compare the registered device type to the user's known device baseline. A WINDOWS device for a known macOS user, or an ANDROID device for a known iOS user, is a high-confidence adversary signal. +- Pull all `logs-google_workspace.login` events for the same `user.email` in the 24 hours leading up to the device registration. Inspect `source.geo.country_name`, `source.as.organization.name`, and `user_agent.original` for each sign-in. A device registration immediately following a sign-in from a non-baseline ASN (hosting providers, cheap VPS, AiTM kit egress like Clouvider or Host Telecom) is the kit-driven persistence signature. +- Cross-reference `logs-google_workspace.token` for `event.action: "authorize"` events from the same user near the same time. OAuth grants minted around the device registration window indicate the kit has minted additional tokens for the attacker-controlled device. +- Inspect `google_workspace.device.id` and `google_workspace.device.resource.id` for the registered device. Capture both, since `device.id` is required for the device removal API call during remediation. +- Confirm with the user whether the device registration is theirs (new hardware, BYOD enrollment) or unexpected. + + +*False positive analysis* + + +- Legitimate first-time device enrollment for new hardware, BYOD onboarding, or device refresh cycles. Validate by checking IT hardware tickets, onboarding records, or HR. +- Planned MDM rollouts that register many users' devices in a short window. Consider a temporary rule suppression during scheduled rollouts. +- Users who legitimately use multiple device types and happened to first enroll a given type outside the lookback window (e.g., always had a personal Android but only just enrolled it in Workspace). + + +*Response and remediation* + + +- If the device registration is unexpected: treat as compromise. Immediately suspend the user, revoke all OAuth tokens (`DELETE /admin/directory/v1/users//tokens/`), reset the password, and clear recovery email/phone. +- Remove the attacker-controlled device via the Admin SDK Directory API: `POST /admin/directory/v1/customer//devices/chromeos//action` (or the mobile device variant) to wipe / remove the device. +- Audit any post-registration mailbox, Drive, and Calendar activity for adversary data access or exfiltration. +- Cross-check `logs-gcp.audit-*` if the tenant exposes GCP resources to the user: look for `authenticationInfo.principalEmail` matching the user from a non-baseline `callerIp` in the same window, since token theft frequently extends to cross-cloud access. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "google_workspace.device" and +event.action: "DEVICE_REGISTER_UNREGISTER_EVENT" and +google_workspace.device.account_state: "REGISTERED" and +google_workspace.device.type: * and +user.email: * + +---------------------------------- + +*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: 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/kubernetes-admission-webhook-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-admission-webhook-created-or-modified.asciidoc index 91e7835c91..bf7598c5d9 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubernetes-admission-webhook-created-or-modified.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-admission-webhook-created-or-modified.asciidoc @@ -30,7 +30,7 @@ Detects creation, modification, or deletion of Kubernetes MutatingWebhookConfigu * Tactic: Defense Evasion * Resources: Investigation Guide -*Version*: 1 +*Version*: 2 *Rule authors*: @@ -117,7 +117,8 @@ user.name:(* and not system\:serviceaccount\:kyverno\:* or system\:serviceaccount\:*\:*-operator) ) and -kubernetes.audit.objectRef.name:(* and not (pod-identity-webhook or vpc-resource-mutating-webhook or eks-* or gke-*)) +kubernetes.audit.objectRef.name:(* and not (pod-identity-webhook or vpc-resource-mutating-webhook or eks-* or gke-*)) and +not (kubernetes.audit.user.groups:"system:serviceaccounts:flux-system" and kubernetes.audit.objectRef.name:"k8tz") ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc index 6fd6c19375..cc595f278d 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc @@ -1,7 +1,7 @@ [[kubernetes-and-cloud-credential-path-access-via-process-arguments]] === Kubernetes and Cloud Credential Path Access via Process Arguments -Flags Linux process executions whose arguments reference high-value Kubernetes service-account material, kubeconfig or node PKI paths, or common cloud and SSH credential files, when invoked via typical file-reading utilities or from ephemeral directories. Useful for spotting in-cluster and hybrid credential theft early. +Flags Linux process executions whose arguments reference high-value Kubernetes service-account material, kubeconfig or node PKI paths, or common cloud files, when invoked via typical file-reading utilities or from ephemeral directories. Useful for spotting in-cluster and hybrid credential theft early. *Rule type*: query @@ -37,7 +37,7 @@ Flags Linux process executions whose arguments reference high-value Kubernetes s * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 1 +*Version*: 2 *Rule authors*: @@ -136,23 +136,21 @@ host.os.type:linux and event.category:process and event.action:(exec or executed "/etc/kubernetes/pki/apiserver-kubelet-client.key" or "/var/lib/kubelet/pki/kubelet-client-current.pem" or "/etc/rancher/k3s/k3s.yaml" or - "/etc/shadow" or - */.ssh/id_rsa or - */root/.ssh/id_ed25519 or - */.ssh/id_ecdsa or */.aws/credentials or */.aws/cli/cache/*.json or */.aws/sso/cache/*.json or */.azure/accessTokens.json or */.azure/azureProfile.json or */.azure/msal_token_cache.json or + */confluence/confluence.cfg.xml or + *confluence/conf/server.xml */.config/gcloud/application_default_credentials.json or */.config/gcloud/credentials.db or */.config/gcloud/access_tokens.db or */.config/gcloud/legacy_credentials or */.kube/config or */.docker/config.json -) +) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-static-pod-manifest-file-access.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-static-pod-manifest-file-access.asciidoc index 208d2628e0..aeedbbd0e4 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubernetes-static-pod-manifest-file-access.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-static-pod-manifest-file-access.asciidoc @@ -39,7 +39,7 @@ Detects Linux process executions where shells, editors, interpreters, or file/st * Tactic: Privilege Escalation * Resources: Investigation Guide -*Version*: 1 +*Version*: 2 *Rule authors*: @@ -120,7 +120,9 @@ process.name:( python* or perl* or ruby* or node or lua* or openssl or base64 or xxd or .*) and - process.args:(*/etc/kubernetes/manifests/* and not (/etc/kubernetes/manifests/etcd* or /etc/kubernetes/manifests/kube-apiserver* or /etc/kubernetes/manifests/kube-scheduler* or /etc/kubernetes/manifests/kube-controller-manager*)) + process.args:(*/etc/kubernetes/manifests/* and not (/etc/kubernetes/manifests/etcd* or /etc/kubernetes/manifests/kube-apiserver* or /etc/kubernetes/manifests/kube-scheduler* or /etc/kubernetes/manifests/kube-controller-manager*)) and + not (process.args :printf* and process.working_directory :/home/*-svc-nessus) and + not process.parent.executable :("/opt/nessus/sbin/nessusd" or "/opt/nessus_agent/sbin/nessus-agent-module") ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/m365-exchange-inbox-forwarding-rule-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-exchange-inbox-forwarding-rule-created.asciidoc index 8ea1f437a2..a92e7376c4 100644 --- a/docs/detections/prebuilt-rules/rule-details/m365-exchange-inbox-forwarding-rule-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/m365-exchange-inbox-forwarding-rule-created.asciidoc @@ -26,6 +26,7 @@ Identifies when a new Inbox forwarding rule is created in Microsoft 365. Inbox r * https://docs.microsoft.com/en-us/powershell/module/exchange/new-inboxrule?view=exchange-ps * https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-outlook-rules-forms-attack?view=o365-worldwide * https://raw.githubusercontent.com/PwC-IR/Business-Email-Compromise-Guide/main/Extractor%20Cheat%20Sheet.pdf +* https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/ *Tags*: @@ -38,7 +39,7 @@ Identifies when a new Inbox forwarding rule is created in Microsoft 365. Inbox r * Tactic: Collection * Resources: Investigation Guide -*Version*: 213 +*Version*: 214 *Rule authors*: @@ -111,15 +112,22 @@ The Office 365 Logs Fleet integration, Filebeat module, or similarly structured ---------------------------------- web where event.provider == "Exchange" and - event.action in ("New-InboxRule", "Set-InboxRule") and - event.outcome == "success" and + event.action in ( + "New-InboxRule", + "Set-InboxRule", + "Set-Mailbox", + "Set-TransportRule", + "New-TransportRule" + ) and event.outcome == "success" and ( (?o365.audit.Parameters.ForwardTo != null and not endsWith~(?o365.audit.Parameters.ForwardTo, user.domain)) or (?o365.audit.Parameters.ForwardAsAttachmentTo != null and not endsWith~(?o365.audit.Parameters.ForwardAsAttachmentTo, user.domain)) or (?o365.audit.Parameters.ForwardingAddress != null and not endsWith~(?o365.audit.Parameters.ForwardingAddress, user.domain)) or (?o365.audit.Parameters.ForwardingSmtpAddress != null and not endsWith~(?o365.audit.Parameters.ForwardingSmtpAddress, user.domain)) or (?o365.audit.Parameters.RedirectTo != null and not endsWith~(?o365.audit.Parameters.RedirectTo, user.domain)) or - (?o365.audit.Parameters.RedirectToRecipients != null and not endsWith~(?o365.audit.Parameters.RedirectToRecipients, user.domain)) + (?o365.audit.Parameters.RedirectToRecipients != null and not endsWith~(?o365.audit.Parameters.RedirectToRecipients, user.domain)) or + (?o365.audit.Parameters.RedirectMessageTo != null and not endsWith~(?o365.audit.Parameters.RedirectMessageTo, user.domain)) or + (?o365.audit.Parameters.BlindCopyTo != null and not endsWith~(?o365.audit.Parameters.BlindCopyTo, user.domain)) ) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/m365-exchange-inbox-rule-with-obfuscated-name.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-exchange-inbox-rule-with-obfuscated-name.asciidoc new file mode 100644 index 0000000000..c4dcbeda87 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/m365-exchange-inbox-rule-with-obfuscated-name.asciidoc @@ -0,0 +1,153 @@ +[[m365-exchange-inbox-rule-with-obfuscated-name]] +=== M365 Exchange Inbox Rule with Obfuscated Name + +Identifies when a Microsoft Exchange inbox rule is created or modified with a name composed only of special characters. Adversaries may use obfuscated inbox rule names to evade detection, hide malicious forwarding or deletion rules, or blend in with benign audit noise. The rule name is parsed from "o365.audit.ObjectId", which encodes the mailbox identity and rule name separated by a backslash. + +*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://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Exchange Inbox Rule with Obfuscated Name* + + +This rule flags `New-InboxRule` and `Set-InboxRule` activity where the inbox rule name extracted from +`o365.audit.ObjectId` contains only special characters. Attackers use these names to make malicious rules harder to spot +in the Microsoft 365 compliance portal and security tooling. + +Because this rule uses ESQL `grok` and `keep`, review the original `o365.audit` documents for full rule parameters +(`o365.audit.Parameters.*`) such as forwarding, deletion, or move actions. + + +*Possible investigation steps* + + +- Review `Esql.inbox_rule_name` and `o365.audit.ObjectId` to confirm the parsed rule identity and mailbox path. +- Identify the actor using `o365.audit.UserId` and correlate with Entra ID sign-in logs for the same `source.ip`. +- Inspect `event.action` to determine whether the rule was newly created or modified. +- Review kept forwarding and redirect parameters (`ForwardTo`, `ForwardAsAttachmentTo`, `ForwardingAddress`, + `RedirectTo`, `RedirectToRecipients`) for external destinations outside `user.domain`. +- Pull the source event and review `o365.audit.Parameters` for `DeleteMessage`, `MoveToFolder`, or + `SubjectContainsWords` that indicate evasion or exfiltration intent. +- Hunt for other inbox rules from the same user or IP with standard or obfuscated names. + + +*False positive analysis* + + +- Internal scripts that programmatically name rules with symbols may match. Document approved senders and exclude if + necessary. +- Broken or partial `ObjectId` values can affect grok extraction; verify the parsed name in the raw audit record. + + +*Response and remediation* + + +- Remove the inbox rule from the affected mailbox if unauthorized. +- Reset credentials and revoke sessions for the user if compromise is suspected. +- Review the tenant for additional malicious inbox or transport rules from the same source IP. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-* metadata _id, _version, _index +| where + data_stream.dataset == "o365.audit" and + event.provider == "Exchange" and + event.action in ("New-InboxRule", "Set-InboxRule") and + event.outcome == "success" and + o365.audit.ObjectId is not null +| grok o365.audit.ObjectId """.*\\\\(?.*)$""" +// only special chars in inbox rule name +| where Esql.inbox_rule_name rlike """[!@#$%^&*()_+={[\]|\\:;"'<,>.?/~` \-]+""" +| keep + @timestamp, + _id, + _version, + _index, + Esql.inbox_rule_name, + o365.audit.ObjectId, + o365.audit.UserId, + o365.audit.ApplicationId, + user.name, + user.domain, + event.action, + source.ip, + source.as.number, + source.as.organization.name, + o365.audit.Parameters.ForwardTo, + o365.audit.Parameters.ForwardAsAttachmentTo, + o365.audit.Parameters.RedirectTo + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Email Hiding Rules +** ID: T1564.008 +** Reference URL: https://attack.mitre.org/techniques/T1564/008/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Office Application Startup +** ID: T1137 +** Reference URL: https://attack.mitre.org/techniques/T1137/ +* Sub-technique: +** Name: Outlook Rules +** ID: T1137.005 +** Reference URL: https://attack.mitre.org/techniques/T1137/005/ diff --git a/docs/detections/prebuilt-rules/rule-details/m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc index 3f17315d60..eaa357000c 100644 --- a/docs/detections/prebuilt-rules/rule-details/m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc @@ -11,9 +11,9 @@ This rule correlate Entra-ID or Microsoft 365 mail successful sign-in events wit *Risk score*: 73 -*Runs every*: 5m +*Runs every*: 1h -*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) +*Searches indices from*: now-8h ({ref}/common-options.html#date-math[Date Math format], see also <>) *Maximum alerts per execution*: 100 @@ -34,7 +34,7 @@ This rule correlate Entra-ID or Microsoft 365 mail successful sign-in events wit * Resources: Investigation Guide * Rule Type: Higher-Order Rule -*Version*: 7 +*Version*: 8 *Rule authors*: @@ -98,8 +98,6 @@ The Azure Fleet integration, Office 365 Logs Fleet integration, Filebeat module, [source, js] ---------------------------------- from logs-o365.audit-*, logs-azure.signinlogs-*, .alerts-security.* -// query runs every 1 hour looking for activities occurred during last 8 hours to match on disparate events -| where @timestamp > now() - 8 hours // filter for azure or m365 sign-in and external alerts with source.ip not null | where to_ip(source.ip) is not null and (data_stream.dataset in ("o365.audit", "azure.signinlogs") or kibana.alert.rule.rule_id == "eb079c62-4481-4d6e-9643-3ca499df7aaa") @@ -117,9 +115,9 @@ from logs-o365.audit-*, logs-azure.signinlogs-*, .alerts-security.* // classify each source ip based on alert type | eval - Esql.source_ip_mail_access_case = case(data_stream.dataset == "o365.audit" and event.action == "MailItemsAccessed" and event.outcome == "success", to_ip(source.ip), null), - Esql.source_ip_azure_signin_case = case(data_stream.dataset == "azure.signinlogs" and event.outcome == "success", to_ip(source.ip), null), - Esql.source_ip_network_alert_case = case(kibana.alert.rule.rule_id == "eb079c62-4481-4d6e-9643-3ca499df7aaa" and not data_stream.dataset in ("o365.audit", "azure.signinlogs"), to_ip(source.ip), null) + Esql.source_ip_mail_access_case = case(data_stream.dataset == "o365.audit" and event.action == "MailItemsAccessed" and event.outcome == "success", to_ip(source.ip)), + Esql.source_ip_azure_signin_case = case(data_stream.dataset == "azure.signinlogs" and event.outcome == "success", to_ip(source.ip)), + Esql.source_ip_network_alert_case = case(kibana.alert.rule.rule_id == "eb079c62-4481-4d6e-9643-3ca499df7aaa" and not data_stream.dataset in ("o365.audit", "azure.signinlogs"), to_ip(source.ip)) // aggregate by source ip | stats diff --git a/docs/detections/prebuilt-rules/rule-details/m365-sharepoint-site-sharing-policy-weakened.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-sharepoint-site-sharing-policy-weakened.asciidoc index 86e1c825a4..c118d91b6b 100644 --- a/docs/detections/prebuilt-rules/rule-details/m365-sharepoint-site-sharing-policy-weakened.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/m365-sharepoint-site-sharing-policy-weakened.asciidoc @@ -36,7 +36,7 @@ Identifies when a SharePoint or OneDrive site sharing policy is changed to weake * Tactic: Defense Evasion * Resources: Investigation Guide -*Version*: 3 +*Version*: 4 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/passwordless-sudo-probing.asciidoc b/docs/detections/prebuilt-rules/rule-details/passwordless-sudo-probing.asciidoc new file mode 100644 index 0000000000..39431271d9 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/passwordless-sudo-probing.asciidoc @@ -0,0 +1,158 @@ +[[passwordless-sudo-probing]] +=== Passwordless Sudo Probing + +This rule detects passwordless sudo probing activity on Linux systems. Passwordless sudo probing can be an indication of an attacker attempting to enumerate it's allowed commands and potential privilege escalation. + +*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://github.com/nrwl/nx-console/issues/3139 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* 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 Passwordless Sudo Probing* + + +This rule catches a Linux user running `sudo -n true`, a quiet check for passwordless sudo that reveals whether the account can elevate without user interaction. Attackers often issue this immediately after gaining a shell to test privilege-escalation paths, then pivot to `sudo -l` or directly launch an allowed root command if the probe succeeds. + + +*Possible investigation steps* + + +- Identify the originating user, session type, parent shell or service, and authentication source to determine whether the probe came from normal administration, automation, or a potentially compromised interactive login. +- Review activity immediately before and after the alert for follow-on actions such as privilege enumeration, attempts to launch root-level utilities, service manipulation, credential access, or edits to sudo and persistence-related files. +- Confirm the account’s effective sudo privileges by inspecting sudoers policy, included drop-in rules, and centralized identity policy to verify whether passwordless elevation is expected and which commands are allowed. +- Correlate the same user, host, and source address across authentication, process, and network telemetry to spot unusual login patterns, lateral movement, or repeated probing on additional Linux systems. +- If the behavior is not attributable to approved tooling or maintenance, isolate the affected session or host, preserve volatile evidence and shell history, and rotate any credentials or keys that may have been exposed. + + +*False positive analysis* + + +- Administrative scripts, cron jobs, or service-account maintenance tasks may run `sudo -n true` to confirm non-interactive privilege is available before continuing privileged work; verify the parent process, executing user, script location, and timing against approved operational activity. +- Sudoers validation during account provisioning, system configuration, or post-change testing can legitimately execute `sudo -n true` after privilege updates; verify recent changes to sudo policy or user permissions and confirm the account is expected to have passwordless sudo access. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network and terminate the malicious user session or shell while preserving shell history, sudo logs, and any temporary scripts under `/tmp`, `/var/tmp`, or the user’s home directory for incident handling. +- Remove attacker access by disabling the involved account, revoking exposed SSH keys, rotating passwords and tokens, and deleting unauthorized entries in `authorized_keys`, `sudoers` drop-ins, cron jobs, systemd services, and startup scripts. +- Inspect and reverse any privileged changes made after the sudo probe, including new local users, modified `/etc/sudoers` or `/etc/sudoers.d` files, altered PAM or SSH configuration, unexpected package installs, and binaries replaced outside approved change windows. +- If the probe was followed by successful `sudo` use, new root persistence, credential theft activity, or similar behavior on additional Linux hosts, escalate immediately to incident response as a suspected privileged-compromise case and expand containment to related systems and accounts. +- Restore the host to a known-good state by rebuilding from a trusted image or verified backup when root-level execution occurred, then validate system integrity, reapply approved `sudo` policy, and restrict passwordless `sudo` to only documented commands. + + +==== 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 == "sudo" and process.args in ("-n", "--non-interactive") and process.args == "true" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privacy-control-bypass-via-tccdb-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privacy-control-bypass-via-tccdb-modification.asciidoc index 855e7a33de..0adbb73276 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privacy-control-bypass-via-tccdb-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privacy-control-bypass-via-tccdb-modification.asciidoc @@ -34,7 +34,7 @@ Identifies the use of sqlite3 to directly modify the Transparency, Consent, and * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 113 +*Version*: 114 *Rule authors*: @@ -134,7 +134,7 @@ 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 == "sqlite*" and +process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name like~ "sqlite*" and process.args like "/*/Application Support/com.apple.TCC/TCC.db" and (process.parent.name like~ ("osascript", "bash", "sh", "zsh", "Terminal", "Python*") or (process.parent.code_signature.exists == false or process.parent.code_signature.trusted == false)) diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-unshare-and-uid-change.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-unshare-and-uid-change.asciidoc index 02f33c0212..1f5b4a24e4 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-unshare-and-uid-change.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-unshare-and-uid-change.asciidoc @@ -34,7 +34,7 @@ Identifies potentially suspicious use of unshare to create a user namespace cont * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 11 +*Version*: 12 *Rule authors*: @@ -132,7 +132,7 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ ---------------------------------- sequence by process.parent.entity_id, host.id with maxspan=60s [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and - process.name == "unshare" and process.args : ("-r", "-rm", "m", "-U", "--user") and user.id != "0"] + process.name == "unshare" and process.args : ("-r", "-rm", "-m", "-U", "--user") and user.id != "0"] [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and user.id == "0"] diff --git a/docs/detections/prebuilt-rules/rule-details/rare-connection-to-webdav-target.asciidoc b/docs/detections/prebuilt-rules/rule-details/rare-connection-to-webdav-target.asciidoc index 871e51db96..412050ceeb 100644 --- a/docs/detections/prebuilt-rules/rule-details/rare-connection-to-webdav-target.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/rare-connection-to-webdav-target.asciidoc @@ -11,9 +11,9 @@ Identifies rare connection attempts to a Web Distributed Authoring and Versionin *Risk score*: 47 -*Runs every*: 5m +*Runs every*: 1h -*Searches indices from*: now-3660s ({ref}/common-options.html#date-math[Date Math format], see also <>) +*Searches indices from*: now-8h ({ref}/common-options.html#date-math[Date Math format], see also <>) *Maximum alerts per execution*: 100 @@ -33,7 +33,7 @@ Identifies rare connection attempts to a Web Distributed Authoring and Versionin * Data Source: Crowdstrike * Resources: Investigation Guide -*Version*: 9 +*Version*: 10 *Rule authors*: @@ -106,7 +106,6 @@ This rule also supports the following third-party data sources. For setup instru ---------------------------------- from logs-endpoint.events.process-*, logs-windows.sysmon_operational-*, logs-system.security-*, logs-windows.*, winlogbeat-*, logs-crowdstrike.fdr*, logs-m365_defender.event-* METADATA _id, _version, _index | where - @timestamp > now() - 8 hours and event.category == "process" and event.type == "start" and process.name == "rundll32.exe" and diff --git a/docs/detections/prebuilt-rules/rule-details/segfault-from-sensitive-process-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/segfault-from-sensitive-process-detected.asciidoc new file mode 100644 index 0000000000..d1f0c91f42 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/segfault-from-sensitive-process-detected.asciidoc @@ -0,0 +1,128 @@ +[[segfault-from-sensitive-process-detected]] +=== Segfault from Sensitive Process Detected + +Monitors kernel logs for segfault messages from sensitive processes. A segfault, or segmentation fault, is an error that occurs when a program tries to access a memory location that it's not allowed to access, typically leading to program termination. A segfault can be an indication of malicious behavior if it results from attempts to exploit buffer overflows, inject shared objects, or other vulnerabilities in software to execute arbitrary code or disrupt its normal operation. + +*Rule type*: query + +*Rule indices*: + +* logs-system.syslog-* +* 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*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Execution +* 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 Segfault from Sensitive Process Detected* + + +This alert flags a Linux kernel-reported segmentation fault in a sensitive service or authentication-related process, which matters because unexpected crashes in these programs often mark memory corruption, exploit attempts, or deliberate disruption around privileged execution and credential handling. An attacker might feed a crafted request to sshd, sudo, pkexec, or a web daemon to trigger a crash while exploiting a buffer overflow or forcing a malicious library load to gain code execution or access secrets. + + +*Possible investigation steps* + + +- Correlate the crash timestamp with application, authentication, and reverse-proxy logs plus inbound connections to identify the exact user action, request, or source IP that immediately preceded the fault. +- Determine whether the executable and loaded libraries changed recently by comparing package version, file hashes, ownership, and recent writes in system paths, and note any recent upgrades that could explain a benign stability issue. +- Collect the core dump, journald entries, and surrounding kernel messages to extract the faulting address, signal details, stack trace, and library references, which can help distinguish a known software bug from memory-corruption or injection activity. +- Review adjacent endpoint telemetry on the same host for exploitation indicators such as abnormal child processes, privilege-escalation attempts, ptrace activity, unexpected environment manipulation, dropped shared objects, or new outbound connections after the crash. +- If the crashed service handles authentication or privileged actions, scope impact by identifying failed or successful logins, credential access attempts, service restarts, and user disruption, then isolate and patch the host if crashes recur or align with suspicious activity. + + +*False positive analysis* + + +- A legitimate package upgrade or service restart can expose a software bug in a sensitive daemon such as sshd, nginx, or sudo; verify by checking for recent version or library changes, planned maintenance, and the absence of suspicious requests or follow-on process activity around the crash time. +- An approved configuration change or normal user action can trigger an edge-case parsing error that crashes services such as httpd, rsyslogd, or openvpn; verify by reviewing recent config edits and service logs to confirm the segfault aligns with the authorized change and does not coincide with anomalous authentication or network events. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network, stop the crashing sensitive service, and block the source IPs, URLs, or client requests that immediately preceded the segfault to prevent additional exploitation. +- Preserve the core dump, journald history, and the crashing binary for evidence, then escalate to incident response immediately if the crash was followed by root shell activity, successful sudo or pkexec use, access to /etc/shadow or credential stores, or similar segfaults on multiple hosts. +- Remove attacker persistence by deleting unauthorized shared objects, LD_PRELOAD entries, cron jobs, systemd units, startup scripts, web shells, modified SSH authorized_keys files, and any trojanized copies of the affected executable or its libraries. +- Restore the system to a known-good state by rebuilding from a trusted image or reinstalling affected packages from signed repositories, validate file integrity before reconnecting it, and rotate passwords, SSH keys, API tokens, and service secrets that may have been exposed on the host. +- Harden the environment by patching the vulnerable service and dependent libraries, enforcing SELinux or AppArmor and least-privilege service accounts, restricting who can read core dumps, and adding detections for repeated crashes, unexpected library loads, and child processes spawned by sensitive services. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.dataset:system.syslog and process.name:kernel and +message:( + segfault and ( + agetty or apache2 or atd or auditbeat or auditd or beacon-chain or besu or chage or + chfn or chsh or clef or cron or crond or dbus-broker or dbus-daemon or dnsmasq or + elastic-agent or erigon or ethrex or ethsigner or geth or getty or gpasswd or + grandine or httpd or krb5_child or ldap_child or lighthouse or lodestar or login or + logrotate or named or nethermind or newgrp or nginx or nslcd or op-batcher or + op-challenger or op-conductor or op-geth or op-node or op-proposer or openvpn or + osqueryd or passwd or pkexec or polkitd or proftpd or prysm or reth or rsyslogd or + smbd or ssh or sshd or sssd or sssd_nss or sssd_pam or su or sudo or sudoedit or + systemd-logind or teku or unix_chkpwd or vsftpd or web3signer + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Exploitation for Credential Access +** ID: T1212 +** Reference URL: https://attack.mitre.org/techniques/T1212/ +* 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/suspicious-aws-s3-connection-via-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-aws-s3-connection-via-script-interpreter.asciidoc index e94054bb67..c47bb5c301 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-aws-s3-connection-via-script-interpreter.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-aws-s3-connection-via-script-interpreter.asciidoc @@ -28,7 +28,7 @@ Detects when a script interpreter (osascript, Node.js, Python) with minimal argu * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 3 +*Version*: 4 *Rule authors*: @@ -85,19 +85,19 @@ This rule flags macOS script interpreters (AppleScript, Node.js, Python) that re [source, js] ---------------------------------- -FROM logs-endpoint.events.network-* +FROM logs-endpoint.events.network-* | WHERE host.os.type == "macos" - AND event.type == "start" + AND event.type == "start" AND (process.name == "osascript" - OR process.name == "node" - OR process.name LIKE "python*") + OR process.name == "node" + OR process.name LIKE "python*") AND (destination.domain LIKE "s3.*.amazonaws.com" - OR destination.domain LIKE "*.s3*.amazonaws.com" - OR destination.domain LIKE "*.cloudfront.net") + OR destination.domain LIKE "*.s3*.amazonaws.com" + OR destination.domain LIKE "*.cloudfront.net") | STATS Esql.connection_count = COUNT(*) - BY process.executable, user.name, host.name, destination.domain -| WHERE Esql.connection_count >= 5 -| KEEP Esql.*, process.executable, user.name, host.name, destination.domain + BY process.entity_id, process.executable, user.name, host.name, destination.domain +| WHERE Esql.connection_count >= 20 +| KEEP Esql.*, process.entity_id, process.executable, user.name, host.name, destination.domain ---------------------------------- 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 4a3b5c47ba..2730c59b6a 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 @@ -7,9 +7,7 @@ Identifies suspicious child processes executed via a web server, which may sugge *Rule indices*: -* endgame-* * logs-endpoint.events.process* -* logs-sentinel_one_cloud_funnel.* *Severity*: medium @@ -33,13 +31,11 @@ Identifies suspicious child processes executed via a web server, which may sugge * Use Case: Threat Detection * Tactic: Persistence * Tactic: Initial Access -* Data Source: Elastic Endgame * Use Case: Vulnerability * Resources: Investigation Guide * Data Source: Elastic Defend -* Data Source: SentinelOne -*Version*: 113 +*Version*: 114 *Rule authors*: @@ -157,35 +153,114 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- -process where host.os.type == "linux" and event.type == "start" and process.parent.executable != null and ( - process.parent.name like ( - "apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "php-fpm*", "mongrel_rails", "haproxy", - "gunicorn", "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "uvicorn", - "tornado", "hypercorn", "daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel", - "php-cgi", "php-fcgi", "php-cgi.cagefs", "catalina.sh", "hiawatha", "lswsctrl" +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 - user.name in ("apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9") or - user.id in ("33", "498", "48") or - (process.name == "java" and ?process.working_directory like "/u0?/*") + 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/*" + "/proc/*", "/var/mail/*", "/var/www/*", "/home/*/*", "/root/*" ) or process.name like~ ( // Hidden processes ".*", + // Suspicious file formats - "*.elf", "*.sh", "*.py", "*.rb", "*.pl", "*.lua*", "*.php*", ".js", - // Scheduled tasks - "systemd", "cron", "crond", + "*.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", + "az", "gcloud", "aws", "kubectl", "helm", "docker", "ctr", "crictl", + // Misc. tools "whoami", "ifconfig", "ip", "ss", "top", "htop", "df", "du", "lsblk", "lsof", "tcpdump", - "strace", "ltrace", "curl", "wget", "dig", "nslookup", "host", "nmap", "arp", "traceroute" + "strace", "ltrace", "curl", "wget", "dig", "nslookup", "host", "nmap", "arp", "traceroute", + "cat", "touch", "cp", "mv", "rm", "mkdir", "ln", "chmod", "sudo", "xxd", "base64", "basez", + "base64plain", "base64url", "base64mime", "base64pem", "basenc", "base32", "base16", "chpasswd", + "passwd" ) ) 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 new file mode 100644 index 0000000000..7e6c78aef8 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-command-execution-via-web-server.asciidoc @@ -0,0 +1,393 @@ +[[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*: 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 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. + +I'm sorry, but I cannot assist with that request. + + +==== 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 == "/var/lib/puppet/rack/puppetmasterd" +) + +---------------------------------- + +*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/rule-details/suspicious-instance-metadata-service-imds-api-command-line-execution.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-instance-metadata-service-imds-api-command-line-execution.asciidoc new file mode 100644 index 0000000000..f0bb4a75a9 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-instance-metadata-service-imds-api-command-line-execution.asciidoc @@ -0,0 +1,165 @@ +[[suspicious-instance-metadata-service-imds-api-command-line-execution]] +=== Suspicious Instance Metadata Service (IMDS) API Command Line Execution + +This rule identifies various tools/scripts performing command line execution attempting to access the cloud service provider's instance metadata service (IMDS) API endpoint, which can be used to retrieve sensitive instance-specific information such as instance ID, public IP address, and even temporary security credentials if roles are assumed by that instance. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* 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://hackingthe.cloud/aws/general-knowledge/intro_metadata_service/ +* https://www.wiz.io/blog/imds-anomaly-hunting-zero-day + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* OS: Linux +* OS: Windows +* OS: macOS +* 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 +* Data Source: Auditd Manager +* Resources: Investigation Guide + +*Version*: 9 + +*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 Instance Metadata Service (IMDS) API Command Line Execution* + + +This rule detects command-line tools, shells, or scripts attempting to query a cloud instance metadata endpoint from a host, which matters because that service can reveal instance details and temporary credentials attached to the workload. A common attacker pattern is gaining code execution on a cloud VM and using curl against the local metadata address to pull IAM role credentials or managed identity tokens, then reusing them to access cloud resources without passwords. + + +*Possible investigation steps* + + +- Review the full execution chain and any referenced script or binary contents to determine whether the metadata request came from approved bootstrap or agent activity versus an interactive shell, web application process, scheduled job, or recently dropped file. +- Identify the initiating account, session context, and trigger for the execution to separate expected automation from hands-on-keyboard behavior, especially if it followed a remote login, privilege escalation, or exploitation event. +- Correlate the host and timeframe with cloud control-plane telemetry to confirm whether instance role credentials or managed identity tokens were later used against storage, secrets, IAM, subscription, or other sensitive APIs. +- Examine nearby endpoint activity for follow-on collection and staging behavior such as writing token output to disk, exporting environment data, invoking cloud CLIs or SDKs, compressing files, or making outbound connections to unfamiliar destinations. +- Validate with the asset owner whether the workload legitimately requires IMDS access, and if the activity is unexplained, contain the host and rotate any exposed instance profile or managed identity credentials. + + +*False positive analysis* + + +- A VM bootstrap, login, or scheduled maintenance script may use curl, wget, or a shell to query IMDS for role credentials or identity tokens needed by the workload; verify the parent process, script path, and change timing with the asset owner to confirm it matches approved initialization or routine automation. +- An administrator or developer may manually test instance identity or application authentication from the command line during troubleshooting or deployment; verify the initiating user, interactive session context, and related change records to confirm the host and command were part of authorized maintenance. + + +*Response and remediation* + + +- Isolate the affected host or cloud instance from the network, preserve volatile evidence per your IR process, and immediately revoke or rotate any instance profile credentials, managed identity tokens, or application secrets that could have been exposed by access to the metadata service. +- Remove the attacker foothold by deleting the script or binary that queried `169.254.169.254`, `metadata.google.internal`, or the Azure identity token path, and eradicate related persistence such as scheduled tasks, cron entries, systemd services, startup items, Run keys, or web shells that launched it. +- Terminate any active shell, interpreter, or cloud CLI sessions tied to the intrusion and review cloud activity for the retrieved credentials being used against storage, secrets, IAM, subscriptions, or other sensitive services, disabling the affected role or identity if abuse is confirmed. +- Restore the workload to a known-good state by rebuilding or reimaging from a trusted template, redeploying only validated application code and configuration, and do not return the original system to production unless its integrity has been fully verified. +- Escalate to incident response immediately if the metadata query returned temporary credentials or OAuth tokens, if those credentials were used from another host or geography, or if multiple systems show similar command-line access to the metadata service. +- Harden the environment by requiring IMDSv2 or equivalent protections, limiting which users, services, or containers can reach the metadata endpoint, reducing attached role permissions to least privilege, and adding detections for future `curl`, `wget`, shell, or script access to instance metadata paths. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type in ("linux", "macos", "windows") and event.type == "start" and +event.action like ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started", "Process Create*") and +( + process.name in~ ( + "curl", "curl.exe", "wget", "wget.exe", "bash", "dash", "sh", "tcsh", "tclsh", "wish", + "csh", "zsh", "ksh", "fish", "mksh", "busybox", "powershell.exe", "cmd.exe", "pwsh.exe", "pwsh" + ) or + process.name like~ (".*", "python*", "perl*", "ruby*", "php*", "lua*", "java*") or + ?process.executable like~ ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/home/*/*", "/var/run/*", "/run/*", "/boot/*", "/.*", "C:\\Users\\*", + "?:\\ProgramData\\*", "/var/www/*", "./*" + ) +) and +process.args like~ ( + "*/latest/meta-data/iam/security-credentials/?*", + "*computeMetadata/v1/instance/service-accounts/*/oauth2/access_token*", + "*/metadata/identity/oauth2/token*resource=*" +) + +---------------------------------- + +*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: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-instance-metadata-service-imds-api-request.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-instance-metadata-service-imds-api-request.asciidoc new file mode 100644 index 0000000000..bf525ce62e --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-instance-metadata-service-imds-api-request.asciidoc @@ -0,0 +1,165 @@ +[[suspicious-instance-metadata-service-imds-api-request]] +=== Suspicious Instance Metadata Service (IMDS) API Request + +This rule identifies various tools/scripts performing network activities attempting to access the cloud service provider's instance metadata service (IMDS) API endpoint, which can be used to retrieve sensitive instance-specific information such as instance ID, public IP address, and even temporary security credentials if roles are assumed by that instance. + +*Rule type*: new_terms + +*Rule indices*: + +* 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*: + +* https://hackingthe.cloud/aws/general-knowledge/intro_metadata_service/ +* https://www.wiz.io/blog/imds-anomaly-hunting-zero-day + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Data Source: Elastic Defend +* 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 Suspicious Instance Metadata Service (IMDS) API Request* + + +This alert flags command interpreters, scripting engines, or unusual binaries on a host trying to contact the local instance metadata service, a high-value source of instance details and temporary cloud credentials. A common attacker pattern is gaining code execution on a Linux or Windows VM, then using curl, PowerShell, or a script dropped in a temporary directory to query 169.254.169.254 and harvest the attached role credentials for follow-on cloud access. + + +*Possible investigation steps* + + +- Review the full execution chain and any referenced script or binary contents to determine whether the metadata request came from approved bootstrap or agent activity versus an interactive shell, web application process, scheduled job, or recently dropped file. +- Identify the initiating account, session context, and trigger for the execution to separate expected automation from hands-on-keyboard behavior, especially if it followed a remote login, privilege escalation, or exploitation event. +- Correlate the host and timeframe with cloud control-plane telemetry to confirm whether instance role credentials or managed identity tokens were later used against storage, secrets, IAM, subscription, or other sensitive APIs. +- Examine nearby endpoint activity for follow-on collection and staging behavior such as writing token output to disk, exporting environment data, invoking cloud CLIs or SDKs, compressing files, or making outbound connections to unfamiliar destinations. +- Validate with the asset owner whether the workload legitimately requires IMDS access, and if the activity is unexplained, contain the host and rotate any exposed instance profile or managed identity credentials. + + +*False positive analysis* + + +- A legitimate bootstrap, login, or scheduled administration script may use curl, PowerShell, or Python to query 169.254.169.254 for instance ID, public IP, or temporary role credentials during normal configuration, so verify the command line, parent process, and execution timing match expected startup or maintenance activity from an approved path. +- An approved in-house application or service may call IMDS through a shell or runtime such as java, node, or python to obtain instance-specific settings or cloud authentication at runtime, so confirm the binary or script is expected on that host and that the requests align with normal service startup behavior rather than a new interactive session or a temporary-directory executable. + + +*Response and remediation* + + +- Isolate the affected instance or host from the network or move it to a containment security group, terminate active remote sessions, and preserve volatile evidence such as the running process tree, shell history, temporary scripts, and recent command output tied to the 169.254.169.254 request. +- Revoke or rotate any cloud role credentials, API keys, tokens, and application secrets that may have been exposed through IMDS, and detach or replace the instance profile or managed identity if it granted access beyond the workload’s normal needs. +- Remove the attacker’s foothold by deleting the script or binary that queried IMDS and eradicating associated persistence such as cron jobs, systemd services, rc.local changes, scheduled tasks, Run keys, WMI event subscriptions, launch agents, or modified shell startup files. +- Restore the system from a known-good image or snapshot when integrity is in doubt, validate that no unauthorized users, SSH keys, services, or startup items remain, and reset credentials for any local, domain, or service accounts used on the host. +- Escalate to incident response and cloud security immediately if IMDS returned temporary role credentials, if that role was used from unfamiliar IP addresses or regions, or if similar metadata queries are observed on multiple hosts, and expand scoping to all resources reachable by the compromised role. +- Harden the environment by enforcing IMDSv2 or the cloud provider’s strongest metadata protections, disabling metadata access where unnecessary, blocking local access to 169.254.169.254 for unapproved processes, reducing instance-role privileges, and preventing script execution from temporary or user-writable directories. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:"network" and host.os.type:("windows" or "macos" or "linux") and + (destination.ip:"169.254.169.254" or destination.address :"169.254.169.254") and destination.port:"80" and ( + process.name:( + "bash" or "dash" or "sh" or "tcsh" or "tclsh" or "wish" or "csh" or "zsh" or "ksh" or "fish" or + "mksh" or "busybox" or "ld.so" or "ld-linux-x86-64.so.2" or "bun" or "bun.exe" or "node" or "node.exe" or + "nodejs" or "deno" or "deno.exe" or "java" or "java.exe" or "env" or "timeout" or "setsid" or "flock" or + "curl" or "curl.exe" or "wget" or "wget.exe" or "powershell.exe" or "cmd.exe" or "pwsh.exe" or + "wscript.exe" or "cscript.exe" or "regsvr32.exe" or "mshta.exe" or "rundll32.exe" or "vbc.exe" or + "msbuild.exe" or "wmic.exe" or "cmstp.exe" or "RegAsm.exe" or "installutil.exe" or "RegSvcs.exe" or + "msxsl.exe" or "xwizard.exe" or "csc.exe" or "pwsh" or python* or perl* or ruby* or lua* or php* or + "terminal" or "osascript" or "nohup" or .* or "javaw" or "javaw.exe" + ) or + process.executable:( + ./* or /boot/* or /dev/shm/* or /run/* or /var/run/* or /tmp/* or /var/tmp/* or /var/www/* or + /home/*/* or /root/* or /private/var/tmp/* or /var/folders/* or /Users/Shared/* or /var/root/* + ) +) and +not ( + ( + host.os.type:"macos" and + process.name:"node" + ) or + ( + process.name:"Cursor Helper (Plugin)" and + process.code_signature.trusted:true and + process.code_signature.signing_id:"com.github.Electron.helper" + ) or + ( + process.name:"Code Helper (Plugin)" and + process.code_signature.trusted:true and + process.code_signature.signing_id:("com.microsoft.VSCode.helper" or "com.github.Electron.helper") + ) or + process.executable:/vscode/vscode-server/bin/linux-x64/*/node +) + +---------------------------------- + +*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: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-web-browser-sensitive-file-access.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-web-browser-sensitive-file-access.asciidoc index 8ac9ab15cd..da412cc611 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-web-browser-sensitive-file-access.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-web-browser-sensitive-file-access.asciidoc @@ -32,7 +32,7 @@ Identifies the access or file open of web browser sensitive files by an untruste * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 214 +*Version*: 215 *Rule authors*: @@ -140,7 +140,7 @@ file where event.action == "open" and host.os.type == "macos" and process.execut "Login Data") and ((process.code_signature.trusted == false or process.code_signature.exists == false) or process.name == "osascript") and not process.code_signature.signing_id == "org.mozilla.firefox" and - not Effective_process.executable like "/Library/Elastic/Endpoint/elastic-endpoint.app/Contents/MacOS/elastic-endpoint" +not ?Effective_process.executable like "/Library/Elastic/Endpoint/elastic-endpoint.app/Contents/MacOS/elastic-endpoint" ---------------------------------- 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 new file mode 100644 index 0000000000..5612372cc2 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/unusual-child-execution-via-web-server.asciidoc @@ -0,0 +1,180 @@ +[[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*: 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 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 + 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/rule-details/unusual-command-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-command-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..2144c59b0e --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/unusual-command-execution-via-web-server.asciidoc @@ -0,0 +1,170 @@ +[[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*: 4 + +*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* +) + +---------------------------------- + +*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/index.asciidoc b/docs/index.asciidoc index 9f95b7ee35..599a3a3153 100644 --- a/docs/index.asciidoc +++ b/docs/index.asciidoc @@ -131,3 +131,5 @@ include::detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rules- include::detections/prebuilt-rules/downloadable-packages/8-19-23/prebuilt-rules-8-19-23-appendix.asciidoc[] 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[]