diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-abnormally-large-dns-response.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-abnormally-large-dns-response.asciidoc new file mode 100644 index 0000000000..55869735db --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-abnormally-large-dns-response.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-33-abnormally-large-dns-response]] +=== Abnormally Large DNS Response + +Specially crafted DNS requests can manipulate a known overflow vulnerability in some Windows DNS servers, resulting in Remote Code Execution (RCE) or a Denial of Service (DoS) from crashing the service. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.* +* logs-panw.panos* +* logs-zeek.* +* logs-corelight.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/ +* https://msrc-blog.microsoft.com/2020/07/14/july-2020-security-update-cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/ +* https://github.com/maxpl0it/CVE-2020-1350-DoS +* https://www.elastic.co/security-labs/detection-rules-for-sigred-vulnerability + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Impact +* Resources: Investigation Guide +* Use Case: Vulnerability +* Data Source: Corelight +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: Zeek + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Abnormally Large DNS Response* + + +Detection alerts from this rule indicate possible anomalous activity around large byte DNS responses from a Windows DNS server. This detection rule was created based on activity represented in exploitation of vulnerability (CVE-2020-1350) also known as https://www.elastic.co/blog/detection-rules-for-sigred-vulnerability[SigRed] during July 2020. + + +*Possible investigation steps* + + +- This specific rule is sourced from network log activity such as DNS or network level data. It's important to validate the source of the incoming traffic and determine if this activity has been observed previously within an environment. +- Activity can be further investigated and validated by reviewing any associated Intrusion Detection Signatures (IDS) alerts. +- Further examination can include a review of the `dns.question_type` network fieldset with a protocol analyzer, such as Zeek, Packetbeat, or Suricata, for `SIG` or `RRSIG` data. +- Validate the patch level and OS of the targeted DNS server to validate the observed activity was not large-scale internet vulnerability scanning. +- Validate that the source of the network activity was not from an authorized vulnerability scan or compromise assessment. + + +*False positive analysis* + + +- Based on this rule, which looks for a threshold of 65k bytes, activity below this value is expected to be legitimate. In packet capture files received by the https://isc.sans.edu/forums/diary/PATCH+NOW+SIGRed+CVE20201350+Microsoft+DNS+Server+Vulnerability/26356/[SANS Internet Storm Center], byte responses in observed attacks were all greater than 65k bytes. +- This activity can be triggered by compliance/vulnerability scanning or compromise assessment; it's important to determine the source of the activity and potentially allowlist the source host. +- Network security devices such as PAN-OS firewalls, Fortinet, and NetFlow exporters, as well as Zeek/Corelight connection summary records, record `destination.bytes` as the total bytes across an entire session rather than a single DNS response. Long-lived flow or connection records (`event.duration` > 60 seconds) are excluded to reduce this noise. Duration is used rather than packet count because a genuine SigRed TCP exchange completes in seconds and cannot be made to exceed 60 seconds by an attacker continuing to use the connection. + + +*Related rules* + + +- Unusual Child Process of dns.exe - 8c37dc0e-e3ac-4c97-8aa0-cf6a9122de45 +- Unusual File Modification by dns.exe - c7ce36c0-32ff-4f9a-bfc2-dcb242bf99f9 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Ensure that you have deployed the latest Microsoft https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350[Security Update] (Monthly Rollup or Security Only) and restarted the patched machines. If unable to patch immediately, Microsoft https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability[released] a registry-based workaround that doesn’t require a restart. This can be used as a temporary solution before the patch is applied. +- Maintain backups of your critical systems to aid in quick recovery. +- Perform routine vulnerability scans of your systems, monitor https://us-cert.cisa.gov/ncas/current-activity[CISA advisories] and patch identified vulnerabilities. +- If you observe a true positive, implement a remediation plan and monitor host-based artifacts for additional post-exploitation behavior. + + +==== Rule query + + +[source, js] +---------------------------------- +((event.category:(network or network_traffic) and destination.port:53) + or network.protocol:"dns" + or data_stream.dataset:(network_traffic.dns or zeek.dns) + or (event.module:corelight and event.dataset:dns)) + and destination.bytes >= 65000 + and event.type:("allowed" or "end" or "protocol" or "start") +and not ( + event.duration > 60000000000 + and ( + event.action:("flow_terminated" or "network_flow") + or data_stream.dataset:zeek.connection + or (event.module:corelight and event.dataset:conn) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Exploitation of Remote Services +** ID: T1210 +** Reference URL: https://attack.mitre.org/techniques/T1210/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Endpoint Denial of Service +** ID: T1499 +** Reference URL: https://attack.mitre.org/techniques/T1499/ +* Sub-technique: +** Name: Application or System Exploitation +** ID: T1499.004 +** Reference URL: https://attack.mitre.org/techniques/T1499/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-accepted-default-telnet-port-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-accepted-default-telnet-port-connection.asciidoc new file mode 100644 index 0000000000..b68c42732d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-accepted-default-telnet-port-connection.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-33-accepted-default-telnet-port-connection]] +=== Accepted Default Telnet Port Connection + +This rule detects network events that may indicate the use of Telnet traffic. Telnet is commonly used by system administrators to remotely control older or embedded systems using the command line shell. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. As a plain-text protocol, it may also expose usernames and passwords to anyone capable of observing the traffic. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.panos* +* logs-fortinet_fortigate.log-* +* logs-pfsense.log-* +* logs-sonicwall_firewall.log-* +* logs-suricata.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Lateral Movement +* Tactic: Initial Access +* Data Source: Fortinet +* Data Source: PAN-OS +* Data Source: pfSense +* Data Source: SonicWall +* Data Source: Suricata +* Resources: Investigation Guide + +*Version*: 117 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Accepted Default Telnet Port Connection* + + +Telnet, a protocol for remote command-line access, is often used in legacy systems. Its lack of encryption makes it vulnerable, allowing attackers to intercept credentials or use it as a backdoor. The detection rule identifies unencrypted Telnet traffic on port 23, flagging connections that bypass typical security measures, thus highlighting potential unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify the source IP address associated with the Telnet connection on port 23. Determine if the source IP is internal or external to the organization. +- Check the destination IP address to ascertain if it belongs to a critical system or a legacy device that might still use Telnet for management purposes. +- Investigate the timeline of the connection event to see if there are any patterns or repeated attempts, which could indicate a persistent threat or automated attack. +- Analyze any associated user accounts or credentials used during the Telnet session to verify if they are legitimate and authorized for remote access. +- Correlate the Telnet connection event with other security alerts or logs to identify any related suspicious activities, such as failed login attempts or unusual data transfers. +- Assess the network segment where the Telnet traffic was detected to determine if it is appropriately segmented and secured against unauthorized access. +- Consider implementing network security measures, such as disabling Telnet on devices or replacing it with secure alternatives like SSH, to prevent future unauthorized access attempts. + + +*False positive analysis* + + +- Legacy systems or devices that require Telnet for management may trigger alerts. To manage this, create exceptions for specific IP addresses or subnets known to host these systems. +- Internal network monitoring tools that use Telnet for legitimate purposes might be flagged. Identify these tools and exclude their traffic from the rule to prevent unnecessary alerts. +- Lab environments or test networks where Telnet is used for educational or testing purposes can cause false positives. Implement network segmentation and apply exceptions to these environments to reduce noise. +- Automated scripts or maintenance tasks that utilize Telnet for routine operations may be mistakenly identified. Document these tasks and whitelist their associated traffic patterns to avoid false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active Telnet sessions on the affected system to disrupt potential attacker activities. +- Conduct a thorough review of system logs and network traffic to identify any unauthorized access or data manipulation that may have occurred. +- Change all credentials that may have been exposed through Telnet traffic, prioritizing those with administrative privileges. +- Implement network segmentation to restrict Telnet access to only necessary internal systems, ensuring it is not exposed to the internet. +- Deploy encryption protocols such as SSH to replace Telnet for remote command-line access, enhancing security for remote management. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for additional security measures. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset:(fortinet_fortigate.log or network_traffic.flow + or panw.panos or pfsense.log or sonicwall_firewall.log or suricata.eve) + or event.category:(network or network_traffic)) + and event.type:(connection and not (denied or end)) + and not event.action:(Reject or client-rst or connection-denied or + connection-end or denied or deny or flow_denied or flow_dropped or + flow_terminated or network_flow or server-rst or timeout) + and not (event.action:netflow_flow and not network.packets > 1) + and not network.application:(stretchoid-scanning or traceroute) + and destination.port:23 + and (network.protocol:(telnet or not *) or data_stream.dataset:fortinet_fortigate.log) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc new file mode 100644 index 0000000000..f542121fd6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-33-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*: 3 + +*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*)) and + not ( + user.id:( + *oic.prod-aks.azure.com* or + *container.googleapis.com* + ) and + source.as.organization.name:("Microsoft Corporation" or "Google LLC") +) and +not user.id:((*oidc.s3* and *ocp*) or (*s3* and *amazonaws.com* and *oidc*)) + +---------------------------------- + +*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-33/prebuilt-rule-8-19-33-aws-backup-resource-enumeration-via-long-term-access-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-backup-resource-enumeration-via-long-term-access-key.asciidoc new file mode 100644 index 0000000000..8f1e7472ca --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-backup-resource-enumeration-via-long-term-access-key.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-33-aws-backup-resource-enumeration-via-long-term-access-key]] +=== AWS Backup Resource Enumeration via Long-Term Access Key + +Detects enumeration of AWS Backup resources using long-term IAM access keys (AKIA* prefix). AWS Backup protects EC2 instances, EBS volumes, RDS databases, DynamoDB tables, EFS file systems, and S3 buckets. An adversary who obtains long-term access keys may enumerate backup vaults, backup plans, and protected resources as a precursor to ransomware. Identifying which resources have recent backups (indicating high-value data) and what vault access policies can be modified to delete or corrupt the backups before encrypting the primary data. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListBackupVaults.html +* https://hackingthe.cloud/aws/enumeration/enumerate_services_via_aws_backup/ + +*Tags*: + +* Domain: Cloud +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Backup +* Rule Type: Custom Query (KQL) +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Backup Resource Enumeration via Long-Term Access Key* + + +AWS Backup vaults and plans are the last line of recovery for ransomware victims. Adversaries performing ransomware preparation systematically enumerate backup vaults to locate recovery points, assess vault lock configuration, and identify which vaults can be deleted or which backup plans can be disabled before encrypting the primary data stores. + +Long-term access keys (AKIA* prefix) are the most commonly exfiltrated credential type, appearing in source code, .env files, and CI/CD configurations. Their use for backup enumeration is particularly suspicious because backup management is almost never performed by individual IAM users with static keys in modern environments. + + +*Possible investigation steps* + + +- Identify the IAM user from aws.cloudtrail.user_identity.arn and confirm whether this user should have backup management access. +- Review source.ip and source.as.organization.name against known infrastructure. Backup enumeration from an unexpected IP with a long-term key is a high-risk indicator. +- Query for subsequent backup write operations by this key: DeleteBackupVault, DeleteRecoveryPoint, DeleteBackupPlan, UpdateRegionSettings. +- Correlate with other enumeration activity from the same access key: EC2 Describe calls, S3 ListBuckets, RDS DescribeDBInstances — broad enumeration suggests ransomware reconnaissance. +- Determine whether Vault Lock is enabled on critical backup vaults (GetBackupVaultLockConfiguration). + + +*Response and remediation* + + +- Immediately deactivate the long-term access key. +- Enable Vault Lock (WORM) on critical backup vaults to prevent deletion for a compliance period. +- Review all backup vault access policies for unauthorized modifications. +- Enable AWS Backup audit manager reports to detect future unauthorized backup modifications. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. AWS Backup management events are logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "backup.amazonaws.com" + and event.action: ( + "ListBackupVaults" or + "ListBackupJobs" or + "ListBackupPlans" or + "ListProtectedResources" or + "ListRecoveryPointsByBackupVault" or + "GetBackupPlan" or + "GetBackupVaultAccessPolicy" or + "DescribeBackupJob" or + "DescribeRecoveryPoint" + ) + and event.outcome: "success" + and aws.cloudtrail.user_identity.access_key_id: AKIA* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-lateral-movement-from-kubernetes-sa-via-assumerolewithwebidentity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-lateral-movement-from-kubernetes-sa-via-assumerolewithwebidentity.asciidoc new file mode 100644 index 0000000000..78eda97c23 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-lateral-movement-from-kubernetes-sa-via-assumerolewithwebidentity.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-33-aws-lateral-movement-from-kubernetes-sa-via-assumerolewithwebidentity]] +=== AWS Lateral Movement from Kubernetes SA via AssumeRoleWithWebIdentity + +Detects when credentials issued through `AssumeRoleWithWebIdentity` for a Kubernetes service account identity are later used for several distinct AWS control-plane actions on the same session access key. Workloads that use EKS IAM Roles for Service Accounts routinely exchange a projected service-account token for short-lived IAM credentials; this rule highlights sessions where that exchange is followed by a spread of sensitive APIs—reconnaissance, secrets and parameter access, IAM changes, or compute creation—beyond what routine pod traffic usually shows. High-volume S3 object reads and writes are excluded from the correlation set to reduce noise from normal data-plane work. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-1h ({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 +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS IAM +* Data Source: AWS STS +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Discovery +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lateral Movement from Kubernetes SA via AssumeRoleWithWebIdentity* + + +The rule output is already aggregated per session key. Start from **`aws.cloudtrail.user_identity.access_key_id`**, then +use the bundled fields to scope time, identity, and network context before drilling into raw CloudTrail. + +**What to review first** + +- **`Esql.first_seen` / `Esql.last_seen`**: time window for the whole session; pull raw CloudTrail for this key between + those timestamps and confirm ordering (assume before follow-ons). +- **`Esql.assume_count`**: should be at least 1; verify the assume row is `AssumeRoleWithWebIdentity` with a Kubernetes + service account in **`Esql.user_name_values`** (`system:serviceaccount:*`). +- **`Esql.post_exploit_count`**, **`Esql.event_action_values`**, **`Esql.attack_phases`**: which distinct APIs fired on the + same key; flag unexpected IAM, secrets, or `RunInstances` alongside recon. +- **`Esql.total_calls`**: volume beyond “three distinct actions”—helps separate quick probes from sustained abuse. +- **`source.ip`**, **`source.as.organization.name`**, **`Esql.user_agent_original_values`**: compare to known cluster egress, + NAT, or approved automation; divergent ASNs or clients can indicate token use off-cluster. + +**Next pivots** + +- In CloudTrail assume events for this key: role ARN, OIDC provider, and `sub` / `aud` in `request_parameters` and + `resources`. +- In Kubernetes: map `Esql.user_name_values` to namespace and workload; check audit logs around `Esql.first_seen` for + `exec`, secret reads, or new RBAC. + + +*False positive analysis* + + +- In-cluster operators (GitOps, scanners, backups) can still satisfy the distinct-action bar; validate workload image, + schedule, and approved IRSA role scope. +- Sessions that barely exceed the distinct-action threshold: use **`Esql.total_calls`** and IAM impact of + **`Esql.event_action_values`** to decide urgency. + + +*Response and remediation* + + +- Revoke or constrain the IAM role session; tighten OIDC trust conditions; rotate or patch the affected workload; reduce + service account permissions and egress where abuse is confirmed. + + +*Additional information* + + +- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html[IAM OIDC identity provider] +- https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html[EKS IAM roles for service accounts] +- https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html[AssumeRoleWithWebIdentity] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* +| WHERE (event.action == "AssumeRoleWithWebIdentity" AND user.name like "system:serviceaccount:*") + // S3 PutObject/GetObject is too common in legit pod SA behavior + OR (event.action IN ("ListBuckets", "DescribeInstances", "GetCallerIdentity", + "ListUsers", "ListRoles", "ListAttachedRolePolicies", "GetRolePolicy", + "GetSecretValue", "ListSecrets", + "GetParameters", "DescribeParameters", "ListKeys", "Decrypt", + "ListFunctions", "GetAuthorizationToken", + "SendCommand", "StartSession", + "CreateUser", "CreateAccessKey", "AttachRolePolicy", "CreateRole", + "PutRolePolicy", "UpdateAssumeRolePolicy", + "UpdateFunctionCode", "UpdateFunctionConfiguration", "ModifyInstanceAttribute", + "StopLogging", "DeleteTrail") + AND aws.cloudtrail.user_identity.type == "AssumedRole") +| GROK aws.cloudtrail.response_elements "accessKeyId=%{NOTSPACE:issued_key_id}," +| EVAL access_key = COALESCE(issued_key_id, aws.cloudtrail.user_identity.access_key_id) +| EVAL is_assume = CASE(event.action == "AssumeRoleWithWebIdentity", 1, 0) +| EVAL is_post_exploit = CASE(event.action != "AssumeRoleWithWebIdentity", 1, 0) +| EVAL phase = CASE( + event.action == "AssumeRoleWithWebIdentity", "initial_access", + event.action IN ("ListBuckets", "DescribeInstances", "ListUsers", "ListRoles", + "GetCallerIdentity", "ListAttachedRolePolicies", "GetRolePolicy", + "ListFunctions"), "recon", + event.action IN ("GetSecretValue", "ListSecrets", "GetParameters", + "GetAuthorizationToken", "Decrypt"), "credential_access", + event.action IN ("SendCommand", "StartSession"), "lateral_movement", + event.action IN ("CreateUser", "CreateAccessKey", "AttachRolePolicy", + "CreateRole", "PutRolePolicy", "UpdateAssumeRolePolicy", + "UpdateFunctionCode", "UpdateFunctionConfiguration", + "ModifyInstanceAttribute"), "persistence", + event.action IN ("StopLogging", "DeleteTrail"), "defense_evasion" + ) +| STATS + Esql.assume_count = SUM(is_assume), + Esql.post_exploit_count = COUNT_DISTINCT(event.action), + Esql.attack_phases = VALUES(phase), + Esql.event_action_values = VALUES(event.action), + Esql.user_name_values = VALUES(user.name), + Esql.user_agent_original_values = VALUES(user_agent.original), + Esql.cloud_account_id_values = VALUES(cloud.account.id), + Esql.data_stream_namespace_values = VALUES(data_stream.namespace), + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp), + Esql.total_calls = COUNT(*) + BY access_key, source.ip, source.`as`.number, source.`as`.organization.name +| WHERE access_key is not null and Esql.assume_count >= 1 AND Esql.post_exploit_count >= 3 +| EVAL aws.cloudtrail.user_identity.access_key_id = MV_FIRST(access_key) +| KEEP aws.cloudtrail.user_identity.access_key_id, source.ip, source.`as`.number, source.`as`.organization.name, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Cloud Services +** ID: T1021.007 +** Reference URL: https://attack.mitre.org/techniques/T1021/007/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-organizations-delegated-administrator-registered.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-organizations-delegated-administrator-registered.asciidoc new file mode 100644 index 0000000000..d29f190ccb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-organizations-delegated-administrator-registered.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-33-aws-organizations-delegated-administrator-registered]] +=== AWS Organizations Delegated Administrator Registered + +Detects when an AWS member account is registered as a delegated administrator for an AWS service via the RegisterDelegatedAdministrator API. Delegated administrators receive service-level administrative access across the entire organization without being the management account. An attacker who compromises a principal with organizations permissions can abuse overly permissive managed policies to register a member account they control as a delegated administrator, then use that privileged access to escalate privileges organization-wide and compromise all member accounts. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/organizations/latest/APIReference/API_RegisterDelegatedAdministrator.html +* https://cymulate.com/blog/aws-delegated-admin-org-takeover/ + +*Tags*: + +* Domain: Cloud +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Organizations +* Rule Type: Custom Query (KQL) +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Organizations Delegated Administrator Registered* + + +AWS allows organizations to delegate service-level administrative access to a member account via RegisterDelegatedAdministrator. The delegated account gains organization-wide administrative privileges for the specified service without being the management account. Adversaries who compromise a principal in the management account with overly permissive Organizations policies can register an attacker-controlled member account as a delegated administrator, then use that foothold to escalate privileges across all accounts in the organization. + +This technique was documented by Cymulate, who found that AmazonGuardDutyFullAccess v1 (before AWS corrected it) granted organizations:RegisterDelegatedAdministrator without resource restrictions, allowing any principal with that policy to elevate a member account to organization-wide admin for sensitive services such as Identity Center or CloudFormation StackSets. + + +*Possible investigation steps* + + +- Identify the caller in aws.cloudtrail.user_identity.arn and user.name. Verify they are an authorized cloud platform administrator. +- Review aws.cloudtrail.request_parameters for the servicePrincipal (which AWS service was delegated) and accountId (which member account was elevated). Confirm the member account belongs to your organization's account inventory. +- Determine whether this delegation was planned. Compare against your organization's current delegated administrator configuration via organizations:ListDelegatedAdministrators. +- Check whether the newly elevated member account subsequently made cross-account API calls or modified permission sets, IAM roles, or CloudFormation stacks. +- Review which managed policies are attached to the calling principal. Policies with broad organizations:* grants without resource restrictions may be exploited for this technique. + + +*Response and remediation* + + +- If unauthorized, deregister the delegated administrator with organizations:DeregisterDelegatedAdministrator. +- Revoke active sessions for the calling identity and audit all management account activity. +- Review and tighten IAM policies attached to principals in the management account — ensure organizations:RegisterDelegatedAdministrator is restricted to a dedicated, MFA-required role. +- Enumerate all delegated administrators in the organization to identify any additional unauthorized delegations. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. Organizations management events are logged in the organization management account by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "organizations.amazonaws.com" + and event.action: "RegisterDelegatedAdministrator" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* 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: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-root-console-login-password-spraying.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-root-console-login-password-spraying.asciidoc new file mode 100644 index 0000000000..6ebcdd9a0d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-root-console-login-password-spraying.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-33-aws-root-console-login-password-spraying]] +=== AWS Root Console Login Password Spraying + +Identifies failed authentication attempts against the AWS Management Console root user from the same source IP address targeting multiple AWS accounts. Password spraying uses few attempts per target across many accounts to avoid lockout, making per-account volume an unreliable signal. This rule detects the cross-account breadth pattern: a single source IP generating root ConsoleLogin failures across two or more distinct AWS accounts. Requires an AWS Organizations-level CloudTrail trail aggregating events from member accounts. + +*Rule type*: threshold + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-1h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://securitylabs.datadoghq.com/articles/aws-root-user-bruteforce-campaign/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Platform: AWS +* Data Source: AWS CloudTrail +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Rule Type: Threshold +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Root Console Login Password Spraying* + + +Password spraying is a credential access technique where an attacker tries a small number of commonly used or leaked passwords across many accounts. Unlike brute force, the per-account attempt count is intentionally low — often 2–8 attempts — to stay below lockout thresholds and evade high-volume detections. Attackers targeting AWS root accounts typically hold a pre-enumerated list of root account email addresses and route attempts through proxy or residential IP infrastructure. + +This rule fires when a single source IP generates failed root `ConsoleLogin` events against two or more distinct AWS accounts within a 1 hour window, requiring an AWS Organizations-level CloudTrail trail. The cross-account breadth is the defining spray signal; brute force against a single account is covered by a separate rule. + + +*Possible investigation steps* + + +- **Assess the source IP.** +Determine whether the IP belongs to a known corporate range, VPN, or expected admin location. Use threat intelligence tools to check if it is flagged as a proxy, Tor exit node, or residential proxy service. + +- **Review the user agent string.** +Outdated browser user agents (for example, Chrome 85 or Firefox 120) are common indicators of spray-campaign tooling. Cross-reference `user_agent.original` across the contributing events in Timeline. + +- **Check for a subsequent successful login.** +Query CloudTrail for a `ConsoleLogin` success for the root identity in the same timeframe. A success immediately after failures indicates the spray succeeded — escalate immediately. + +- **Examine follow-on API calls.** +If a successful login did occur, review high-risk API calls that followed: `CreateUser`, `CreateAccessKey`, `AttachRolePolicy`, `DeleteTrail`, or `StopLogging`. + +- **Widen the scope across accounts.** +If your organization uses AWS Organizations, check whether the same source IP triggered root login failures in other member accounts during the same window. + + +*False positive analysis* + + +- **Mistyped credentials.** A root credential custodian mistyping the password multiple times is the most likely benign cause. Confirm whether the source IP is a known admin location and whether a successful login followed shortly after. +- **Stale automation.** Misconfigured scripts or browser sessions with cached root credentials may retry on failure. Check whether the user agent matches known internal tooling. + + +*Response and remediation* + + +- **If no successful root login is found:** + - Rotate the root password to a strong, unique credential stored in an offline vault. + - Confirm MFA is enabled and enforced on the root account. + - Block the source IP at AWS WAF or network ACLs if confirmed malicious. + +- **If a successful root login is found:** + - Treat as Priority-1 account compromise and immediately follow the *AWS Management Console Root Login* investigation guide. + - Initiate an emergency root password reset and MFA re-enrollment. + - Preserve all CloudTrail events from ±1 hour around the login in an immutable evidence bucket. + - Audit all API calls made during the session for persistence: new users, access keys, policy changes. + + +*Additional information* + + +- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html[AWS root user best practices] +- https://github.com/aws-samples/aws-incident-response-playbooks[AWS IR Playbooks — Credential Compromise] + + +==== Setup + + + +*Setup* + + +This rule requires an AWS Organizations-level CloudTrail trail that aggregates management events from all member accounts into a single destination. A single-account trail will only ever contain one `cloud.account.id` value and the cross-account cardinality signal will never fire. + +To configure an org-level trail: in the AWS CloudTrail console, create a trail scoped to your AWS Organization and enable it in all regions. Ensure the Elastic AWS integration is ingesting from the aggregated trail destination. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and +event.provider:signin.amazonaws.com and +event.action:ConsoleLogin and +aws.cloudtrail.user_identity.type:Root and +event.outcome:failure + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-s3-bucket-mfa-delete-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-s3-bucket-mfa-delete-disabled.asciidoc new file mode 100644 index 0000000000..4e2d43d677 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-s3-bucket-mfa-delete-disabled.asciidoc @@ -0,0 +1,110 @@ +[[prebuilt-rule-8-19-33-aws-s3-bucket-mfa-delete-disabled]] +=== AWS S3 Bucket MFA Delete Disabled + +Detects when MFA Delete is disabled on an Amazon S3 bucket. MFA Delete is an additional layer of security for versioned S3 buckets that requires multi-factor authentication to permanently delete object versions or disable versioning. When MFA Delete is disabled, an adversary with S3 write access and a compromised long-term access key can permanently delete object versions, a critical step in ransomware attacks that target S3 versioning as a backup mechanism. MFA Delete is configured via PutBucketVersioning with the MfaDelete parameter set to Disabled. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketVersioning.html +* https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/ +* https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c + +*Tags*: + +* Domain: Cloud +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 +* Rule Type: Custom Query (KQL) +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket MFA Delete Disabled* + + +MFA Delete protects versioned S3 buckets by requiring MFA authentication to permanently delete object versions or change the versioning state. This protection is specifically designed to prevent ransomware from destroying version history after encrypting the current object copies. Disabling MFA Delete removes this safeguard and is a recognized ransomware preparation step. + +Importantly, only the AWS account root user can enable or disable MFA Delete. A `PutBucketVersioning` call disabling MFA Delete from a non-root identity is a strong indicator of root credential compromise or unauthorized use. + + +*Possible investigation steps* + + +- Identify the caller from `aws.cloudtrail.user_identity.type`. If this is not a `Root` identity, treat it as high-confidence unauthorized access. +- Check `aws.cloudtrail.request_parameters` to confirm `VersioningConfiguration={... MfaDelete=Disabled}` is present. +- Review all API calls by the same identity in the surrounding window for other data-destruction or encryption-related actions. +- Check whether object versioning remains enabled on the affected bucket. If both versioning and MFA Delete are disabled, the bucket has no object-level recovery protection. +- Investigate whether MFA was presented (`aws.cloudtrail.additional_eventdata` contains MFA information for requests that required it). + + +*Response and remediation* + + +- If unauthorized, immediately re-enable MFA Delete using root credentials and verify that object version history is intact. +- Rotate all credentials associated with the calling identity. +- Review S3 object versions for any permanent deletions that occurred after MFA Delete was disabled. +- Enable AWS Config rules to detect versioning and MFA Delete configuration changes. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. S3 management events are logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "s3.amazonaws.com" + and event.action: "PutBucketVersioning" + and event.outcome: "success" + and aws.cloudtrail.flattened.request_parameters.VersioningConfiguration.MfaDelete: "Disabled" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-security-hub-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-security-hub-disabled.asciidoc new file mode 100644 index 0000000000..2fb6eb2a5d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-security-hub-disabled.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-33-aws-security-hub-disabled]] +=== AWS Security Hub Disabled + +Detects when AWS Security Hub is disabled in a region. Security Hub aggregates security findings from AWS services (GuardDuty, Inspector, Macie, IAM Access Analyzer) and third-party tools into a single pane of glass. Disabling it suppresses centralized finding aggregation and compliance checks, removing visibility into threats across the account. This action is a documented pre-ransomware and pre-exfiltration defense evasion technique. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-disable.html + +*Tags*: + +* Domain: Cloud +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Security Hub +* Rule Type: Custom Query (KQL) +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Security Hub Disabled* + + +AWS Security Hub aggregates security findings from GuardDuty, Inspector, IAM Access Analyzer, Macie, and partner products. Disabling it is a one-API-call action (DisableSecurityHub) that immediately stops new findings from appearing in the hub and breaks compliance posture checks (CIS, PCI DSS, AWS Foundational Security Best Practices). Threat actors performing pre-ransomware activity commonly disable security services to reduce detection during the exfiltration and encryption phases. + + +*Possible investigation steps* + + +- Identify the caller in aws.cloudtrail.user_identity.arn and user.name. Determine whether this is a human operator, a CI/CD service role, or an automated account lifecycle script. +- Check source.ip against known office CIDRs, VPN endpoints, and CI/CD runner IPs. A call from an unexpected geography or cloud provider IP is a strong indicator of credential compromise. +- Query CloudTrail for all API calls from this identity in the same time window. Look for co-occurring DeleteDetector or UpdateDetector with enable false (GuardDuty), DisableMacie or UpdateMacieSession with status PAUSED (Macie), DeleteTrail, StopLogging, PutEventSelectors (reducing event selectors), or DeleteFlowLogs calls — a multi-service security teardown is high confidence ransomware/wiperware preparation. +- Determine whether Security Hub was re-enabled shortly after (indicating a momentary operational toggle) or remained disabled. +- Check whether this corresponds to a known change window or approved infrastructure operation. + + +*False positive analysis* + + +- Regional decommissioning: teams shutting down an AWS region may disable Security Hub as part of account cleanup. Validate against a change management ticket. +- Cost optimization: Security Hub has a cost per finding. Some teams disable it in non-production accounts. If this fires in a dev/test account with known cost controls, correlate with account tags. + + +*Response and remediation* + + +- If unauthorized, re-enable Security Hub immediately and review all findings that were suppressed during the disabled period using the Security Hub finding history API. +- Revoke active sessions for the calling identity. +- Review other security services (GuardDuty, Macie, Inspector) to confirm they remain enabled. +- Enable AWS Config rule securityhub-enabled to detect future disablement automatically. +- If the caller was a compromised IAM user, rotate all access keys and review all actions in the compromised session. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. No additional CloudTrail data event selectors are required — `securityhub:DisableSecurityHub` is a management-plane API logged by default in any CloudTrail trail with management event logging enabled. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "securityhub.amazonaws.com" + and event.action: "DisableSecurityHub" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-service-quota-increase-requested-by-rare-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-service-quota-increase-requested-by-rare-identity.asciidoc new file mode 100644 index 0000000000..1a3f4c3936 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-service-quota-increase-requested-by-rare-identity.asciidoc @@ -0,0 +1,105 @@ +[[prebuilt-rule-8-19-33-aws-service-quota-increase-requested-by-rare-identity]] +=== AWS Service Quota Increase Requested by Rare Identity + +Detects the first time an AWS identity requests a service quota increase via the AWS Service Quotas API within a 7-day history window. Service quota increases are submitted to AWS Support and, when approved, raise the limits on EC2 instances, Lambda concurrency, VPC resources, and other services. An adversary who obtains AWS credentials may request quota increases as infrastructure preparation for large-scale cryptomining, DDoS amplification, phishing campaigns, or data exfiltration operations that require compute or network resources beyond the account's current limits. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/servicequotas/2019-06-24/apireference/API_RequestServiceQuotaIncrease.html +* https://www.rapid7.com/blog/post/dr-threat-actors-aws-workmail-phishing-campaigns/ + +*Tags*: + +* Domain: Cloud +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Service Quotas +* Rule Type: New Terms +* Tactic: Resource Development +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Service Quota Increase Requested by Rare Identity* + + +AWS Service Quotas (formerly Service Limits) cap how many resources of each type an account can create. Default limits exist to prevent accidental runaway provisioning, but an adversary who requests an increase can scale operations far beyond what the default limits allow: requesting 1000 EC2 On-Demand vCPUs enables cryptomining at industrial scale; requesting higher SES sending limits enables large-scale phishing campaigns; requesting higher Lambda concurrency enables large-scale credential-stuffing operations. + + +*Possible investigation steps* + + +- Identify the caller from aws.cloudtrail.user_identity.arn and user.name. +- Review aws.cloudtrail.request_parameters for the serviceCode (which AWS service), the quotaCode (which specific limit), and the requested value. +- Determine whether the requested quota increase aligns with a known infrastructure project. +- Check whether the same identity has recently created resources in the service being scaled (EC2 RunInstances, Lambda CreateFunction, SES SendEmail). +- Review whether this is the first quota increase request for this service from this identity or a continuation of a known capacity planning effort. + + +*Response and remediation* + + +- If unauthorized, submit a cancellation request to AWS Support for the quota increase. +- Revoke active sessions for the requesting identity. +- Apply an SCP restricting servicequotas:RequestServiceQuotaIncrease to approved cloud-operations roles that require prior approval. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. Service Quotas management events are logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "servicequotas.amazonaws.com" + and event.action: "RequestServiceQuotaIncrease" + and event.outcome: "success" + and not user_agent.original: (*Terraform* or *Pulumi* or *Ansible* or "cloudformation.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Acquire Infrastructure +** ID: T1583 +** Reference URL: https://attack.mitre.org/techniques/T1583/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-ses-account-email-sending-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-ses-account-email-sending-enabled.asciidoc new file mode 100644 index 0000000000..01bc1e7898 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-ses-account-email-sending-enabled.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-33-aws-ses-account-email-sending-enabled]] +=== AWS SES Account Email Sending Enabled + +Detects when account-level email sending is explicitly enabled in Amazon SES, via the v1 UpdateAccountSendingEnabled API with Enabled: true or the v2 PutAccountSendingAttributes API with SendingEnabled: true. Account-level sending is commonly paused by an administrator, or by automation wired to CloudWatch reputation alarms when bounce or complaint rates rise. An attacker who compromises an AWS account may re-enable sending to restore a paused capability as part of phishing infrastructure setup, allowing bulk email under the victim organization's trusted sending domain. Neither API can resume sending that AWS itself has paused. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/ses/latest/APIReference/API_UpdateAccountSendingEnabled.html +* https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_PutAccountSendingAttributes.html +* https://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/ +* https://www.rapid7.com/blog/post/dr-threat-actors-aws-workmail-phishing-campaigns/ + +*Tags*: + +* Domain: Cloud +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS SES +* Rule Type: Custom Query (KQL) +* Tactic: Resource Development +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SES Account Email Sending Enabled* + + +ses:UpdateAccountSendingEnabled (v1) and ses:PutAccountSendingAttributes (v2) both control whether the entire AWS account can send email in the current region, and both log under event.provider ses.amazonaws.com, so a caller can reach the same outcome through either API version. Enabling account-level sending is a one-step action that lifts a pause set by an administrator or by CloudWatch-driven automation. Per the v2 documentation neither API can resume sending that AWS has paused, so this is not a path out of an AWS enforcement action. In normal operations these APIs are rarely called. An attacker with SES permissions may call either one to restore paused sending capability, or to enable sending in a region where it was not previously active. + + +*Possible investigation steps* + + +- Identify the caller in aws.cloudtrail.user_identity.arn and user.name. Determine whether this is a known SES administrator or an anomalous identity. +- Verify whether account-level sending was previously disabled (ses:GetAccountSendingEnabled in v1, or ses:GetAccount returning SendingEnabled false in v2) and cross-reference prior CloudTrail events for both APIs. +- Query CloudTrail for co-occurring events from the same identity: IAM privilege escalation (AttachUserPolicy, AttachRolePolicy), SES identity creation (VerifyEmailIdentity, CreateEmailIdentity), or SES template/suppression-list manipulation. +- Check the account's SES sending statistics for any unusual spike in sent email volume following this event. +- Determine whether this corresponds to a legitimate remediation of a bounce/complaint rate issue with a change management ticket. + + +*False positive analysis* + + +- Legitimate SES operations teams re-enabling sending after a planned suspension will trigger this rule. These events are rare; validate against change records. + + +*Response and remediation* + + +- If unauthorized, disable account-level sending immediately via ses:UpdateAccountSendingEnabled with Enabled: false, or ses:PutAccountSendingAttributes with SendingEnabled: false. +- Revoke active sessions for the calling identity. +- Review SES send statistics for unauthorized email activity during the enabled window. +- Check all SES email identities and sending authorization policies for unauthorized entries. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. No additional data event selectors are required — `ses:UpdateAccountSendingEnabled` and `ses:PutAccountSendingAttributes` are management-plane APIs logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ses.amazonaws.com" + and event.action: ("UpdateAccountSendingEnabled" or "PutAccountSendingAttributes") + and event.outcome: "success" + and aws.cloudtrail.request_parameters: (*enabled=true* or *Enabled=true*) + and not user_agent.original: (*Terraform* or *terraform* or *Pulumi* or *pulumi* or *Ansible* or "batch.amazonaws.com" or "cloudformation.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Stage Capabilities +** ID: T1608 +** Reference URL: https://attack.mitre.org/techniques/T1608/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-ses-enumeration-via-long-term-access-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-ses-enumeration-via-long-term-access-key.asciidoc new file mode 100644 index 0000000000..7c57373b05 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-aws-ses-enumeration-via-long-term-access-key.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-33-aws-ses-enumeration-via-long-term-access-key]] +=== AWS SES Enumeration via Long-Term Access Key + +Detects enumeration of Amazon Simple Email Service (SES) resources using long-term IAM access keys (AKIA* prefix). Long-term access keys are associated with IAM users and are the credential type most commonly exfiltrated from repositories, configuration files, and environment variables. An adversary who obtains a long-term key may enumerate SES to discover verified email identities, sending quotas, and DKIM/MAIL FROM domain configurations as a precursor to phishing or spam campaigns launched from the compromised account's verified domains. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/ses/latest/APIReference/API_ListIdentities.html +* https://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/ +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.discovery.ses-enumerate/ + +*Tags*: + +* Domain: Cloud +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS SES +* Rule Type: Custom Query (KQL) +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SES Enumeration via Long-Term Access Key* + + +Amazon SES verified identities (email addresses and domains) are the sending credentials that allow SES to send email on behalf of a domain. Adversaries who exfiltrate long-term IAM keys may enumerate SES to identify available verified domains for phishing, discover DKIM configurations, or check sending limits before launching a bulk email campaign. + +Long-term keys (AKIA* prefix) are lower-security than assumed-role credentials: they do not expire and are frequently exposed in source code, .env files, CI/CD configuration, and developer workstations. This makes them the most common compromised credential type in cloud environments. + + +*Possible investigation steps* + + +- Identify the IAM user behind the long-term key from aws.cloudtrail.user_identity.arn. +- Check whether this access key has been rotated recently (GetAccessKeyLastUsed, ListAccessKeys). Confirm the user who owns the key initiated this activity. +- Review source.ip and source.as.organization.name against known developer or automation infrastructure. API calls from unexpected geographies using a long-term key are high-risk. +- Query CloudTrail for subsequent SES write operations (SendEmail, SendRawEmail, VerifyEmailIdentity, UpdateAccountSendingEnabled) using the same access key. +- Check GitHub, GitLab, and CI/CD logs for any public exposure of this key. + + +*Response and remediation* + + +- Immediately deactivate the long-term access key (UpdateAccessKey --status Inactive). +- Rotate all credentials associated with the IAM user. +- Review all SES quotas and sending history to determine whether unauthorized email was sent. +- Migrate automation that used this key to IAM roles with short-lived assumed-role credentials. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. SES management APIs are logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ses.amazonaws.com" + and event.action: ( + "ListIdentities" or + "GetAccountSendingEnabled" or + "GetSendQuota" or + "ListEmailIdentities" or + "GetEmailIdentity" or + "DescribeActiveReceiptRuleSet" or + "ListReceiptRuleSets" + ) + and event.outcome: "success" + and aws.cloudtrail.user_identity.access_key_id: AKIA* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-azcopy-or-azure-storage-explorer-usage-on-unusual-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-azcopy-or-azure-storage-explorer-usage-on-unusual-host.asciidoc new file mode 100644 index 0000000000..0e6cb17f95 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-azcopy-or-azure-storage-explorer-usage-on-unusual-host.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-33-azcopy-or-azure-storage-explorer-usage-on-unusual-host]] +=== AzCopy or Azure Storage Explorer Usage on Unusual Host + +Identifies the first time, in a historical window, a host runs AzCopy copy or sync to Azure Blob, Data Lake, or File storage, or starts Azure Storage Explorer. These Microsoft utilities are legitimate data-transfer tools; ransomware and cloud-ransomware operators drop portable copies and use SAS-authenticated jobs to pull data from victim storage and push it to attacker-controlled accounts. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* 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://www.cisa.gov/news-events/cybersecurity-advisories/aa23-319a +* https://www.cisa.gov/sites/default/files/2025-04/aa23-319a-stopransomware-rhysida-ransomware_2.pdf +* https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10 +* https://learn.microsoft.com/en-us/azure/storage/storage-explorer/vs-azure-tools-storage-explorer-blobs +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Platform: Windows +* Use Case: Threat Detection +* Tactic: Exfiltration +* Tactic: Collection +* Tactic: Execution +* Rule Type: New Terms +* Threat: Rhysida +* Use Case: Ransomware +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AzCopy or Azure Storage Explorer Usage on Unusual Host* + + +AzCopy and Azure Storage Explorer are Microsoft utilities for moving data to and from Azure Storage. Threat actors abuse them as living-off-the-land binaries: they run `azcopy copy` with SAS URLs against `*.blob.core.windows.net` (GetBlob from a victim account, PutBlob to an attacker account, or Blob-to-Blob between them) and launch Storage Explorer to browse or move the same data. CISA's Rhysida advisory is one example of that tradecraft. + +This is a new-terms rule: it alerts the first time a `host.id` matches in the history window (7 days). AzCopy `copy`/`sync` whose command line includes an Azure Storage hostname, or Storage Explorer (`StorageExplorer.exe`, `StorageExplorer-windows-x64.exe`, `StorageExplorer-windows-arm64.exe`, `StorageExplorer-windowsx64.exe`), fires once per host. Recurring use on the same host will not re-alert until the history window expires. + + +*Possible investigation steps* + + +- Confirm which utility fired the alert. For AzCopy, inspect `process.command_line` for `copy` vs `sync`, `--from-to` (`BlobLocal`, `LocalBlob`, `BlobBlob`), and the SAS URL host, container, and `sp`/`se` parameters. For Storage Explorer, note the installer vs application name and silent-install flags such as `/VERYSILENT`. +- Identify source and destination. AzCopy command lines often contain a local path and one or two `https://.blob.core.windows.net/...` URLs. Treat Blob-to-Blob copies as direct tenant-to-attacker movement even when no files touch disk. +- Check `process.executable` and `process.parent.executable`. A copy from a user-writable or staging path, especially spawned by PowerShell or a scripting host, is more suspicious than a packaged install. +- Compare `process.name` with `process.pe.original_file_name` and `process.code_signature.subject_name`. A Microsoft-signed binary from an unusual path is still the Rhysida/Storm-0501 tradecraft; a renamed unsigned copy is additional evasion. +- Pivot to Azure Storage diagnostic logs for the same window: GetBlob, PutBlob, and BlobBlob with user agent `AzCopy*` or `Microsoft Azure Storage Explorer*` and SAS authentication. Correlate with the SIEM rule "Azure Storage Blob Retrieval via AzCopy". +- Review network telemetry from the same `process.entity_id` to `*.blob.core.windows.net` or `*.dfs.core.windows.net` and estimate volume. +- Hunt sibling activity on the host: other Azure LOLBINs, rclone, or bulk archive creation preceding the copy. + + +*False positive analysis* + + +- Authorized AzCopy migrations and first-time Storage Explorer use on a host will match. This rule alerts only the first time a given `host.id` matches within 7 days; allowlist by host, user, or approved destination if that first alert is expected. +- Do not treat a trusted Microsoft signature as benign by itself; CISA's Rhysida advisory describes the official AzCopy and Storage Explorer binaries. + + +*Response and remediation* + + +- If exfiltration is confirmed, isolate the host, stop AzCopy and Storage Explorer processes, and preserve the command line (SAS URLs are credentials). +- Revoke the SAS tokens and account keys that appear in the command line; rotate storage account keys and any related Entra ID credentials. +- Identify which blobs were read or written (GetBlob/PutBlob/ListBlobs for the same account and time window) and assess data exposure. +- Remove staged binaries under unusual paths and investigate how they were delivered. +- Hunt for additional AzCopy, Storage Explorer, or rclone activity on other hosts in the same window. + + +*Related rules* + + +- Azure Storage Blob Retrieval via AzCopy: cloud-side GetBlob with AzCopy user agent and SAS authentication. +- Potential Data Exfiltration via Rclone: similar endpoint abuse of a different cloud-sync utility. + + +==== 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] + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:process and event.type:start and +( + ( + (process.name:"azcopy.exe" or process.pe.original_file_name:"azcopy.exe") and + process.args:("copy" or "sync") and + process.command_line:(*blob.core.windows.net* or *dfs.core.windows.net* or *file.core.windows.net* or *blob.storage.azure.net*) + ) or + process.name:("StorageExplorer.exe" or "StorageExplorer-windows-x64.exe" or "StorageExplorer-windows-arm64.exe" or "StorageExplorer-windowsx64.exe") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* 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: 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/ +* 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: Cloud API +** ID: T1059.009 +** Reference URL: https://attack.mitre.org/techniques/T1059/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-azure-storage-anonymous-blob-access-to-unusual-resource.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-azure-storage-anonymous-blob-access-to-unusual-resource.asciidoc new file mode 100644 index 0000000000..7a576bed89 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-azure-storage-anonymous-blob-access-to-unusual-resource.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-33-azure-storage-anonymous-blob-access-to-unusual-resource]] +=== Azure Storage Anonymous Blob Access to Unusual Resource + +Identifies the first time an Azure Storage resource receives an anonymous data-plane read (GetBlob and related Get or List operations). Anonymous requests are used to probe public containers and to test stolen blob URLs before a SAS is appended. First-seen resource ID keeps volume down while still covering WireServer-related probes of status or extension blobs. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.platformlogs-* + +*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/azure/azure-monitor/reference/tables/storagebloblogs +* https://learn.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent +* https://cybercx.com.au/blog/azure-ssrf-metadata/ +* https://www.netspi.com/blog/technical-blog/cloud-pentesting/decrypting-vm-extension-settings-with-azure-wireserver/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure Platform Logs +* Platform: Azure +* Service: Azure Storage +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Storage Anonymous Blob Access to Unusual Resource* + + +StorageRead platform logs record `AuthenticationType` as Anonymous when no SAS, OAuth, or account key is presented. +A first-seen `azure.resource.id` (typically the blob service +`/subscriptions/.../storageAccounts//blobServices/default`) means this resource has not had anonymous Get or +List traffic in the history window. + +WireServer SAS-replay chains often start with an anonymous GetBlob (HTTP 409/403) against the same object, then a +SAS 200. This rule does not require guest-agent path strings; those lab container names are not production +observables. + +`source.ip` is often empty. Use `source.address` (`ip:port`). + + +*Possible investigation steps* + + +- Review `event.action`, `azure.platformlogs.statusCode`, and `azure.platformlogs.uri`. +- HTTP 200 with Anonymous means the container or blob is publicly readable. HTTP 409/403 is a probe. +- Identify the account from `azure.resource.id` / `azure.resource.name` and check whether public access is intended. +- Search for SAS-authenticated GetBlob to the same account from the same source shortly after. +- If the URI contains `/$system/` or `md-hdd-`, correlate with WireServer access on VMs in the subscription. + + +*False positive analysis* + + +- Public blob websites and CDN origins. Exclude the `azure.resource.id` for approved public accounts. +- New accounts that enable StorageRead for the first time will alert on the first scanner hit. + + +*Response and remediation* + + +- Disable anonymous public access on accounts that should be private. +- If a follow-on SAS read exists, revoke that SAS and review how the URL was obtained. +- Keep StorageRead diagnostic logs enabled on storage accounts of interest. + + +==== Setup + + + +*Required Azure Storage Diagnostic Logs* + + +Enable StorageRead diagnostic logs on Azure Storage Accounts and stream them to the Event Hub used by the Azure +integration. Anonymous vs SAS is `azure.platformlogs.identity.type`. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.platformlogs and + azure.platformlogs.identity.type: Anonymous and + event.action: ( + GetBlob or GetBlobMetadata or GetBlobProperties or GetBlockList or + GetPageRanges or QueryBlobContents or ListBlobs or + GetContainerProperties or GetContainerMetadata or GetContainerAcl + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ +* 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-33/prebuilt-rule-8-19-33-azure-wireserver-http-request-from-unexpected-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-azure-wireserver-http-request-from-unexpected-user-agent.asciidoc new file mode 100644 index 0000000000..02e0de65fe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-azure-wireserver-http-request-from-unexpected-user-agent.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-33-azure-wireserver-http-request-from-unexpected-user-agent]] +=== Azure WireServer HTTP Request from Unexpected User Agent + +Identifies HTTP requests to Azure WireServer (168.63.129.16) for GoalState, certificates, versions, or HostGAPlugin vmSettings that do not use a known guest-agent user agent. These requests retrieve transport certificates and extension protectedSettings, including embedded SAS URLs. Azure Linux Agent, Windows guest agent, and related platform UAs are excluded. Requests with no user agent are also excluded; that pattern is common for the Windows guest agent. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.http* + +*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://cybercx.com.au/blog/azure-ssrf-metadata/ +* https://www.netspi.com/blog/technical-blog/cloud-pentesting/decrypting-vm-extension-settings-with-azure-wireserver/ +* https://cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services +* https://learn.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16 + +*Tags*: + +* Domain: Cloud +* Domain: Network +* OS: Linux +* OS: Windows +* Platform: Azure +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Data Source: Network Packet Capture +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure WireServer HTTP Request from Unexpected User Agent* + + +Network Packet Capture with HTTP decoding on ports 80 and 32526 shows the URI that Elastic Defend network events +lack. The match is the WireServer path or query, not a scripting-tool user-agent allowlist. + +- `url.query` contains `comp=versions` (discovery) +- `url.query` contains `comp=goalstate` (incarnation, container, extension list, statusUploadBlob pointer) +- `url.query` contains `comp=certificates` (often with request header `x-ms-guest-agent-public-x509-cert`) +- `destination.port == 32526` and `url.path` in `/versions`, `/vmSettings` + +Excluded user agents from lab guest-agent traffic: `WALinuxAgent/*`, `VMAgent/*`, `Python-urllib/*`, +`cpprestsdk/*`, `ACMS/*`, and a missing user agent (Windows guest agent). Curl and Windows PowerShell are not +excluded and will fire. + +`/vmSettings` response bodies are often dropped when they exceed keyword `ignore_above`. The URI, port, and user +agent are sufficient. Do not enable body capture to chase this rule. + + +*Possible investigation steps* + + +- Confirm `url.path`, `url.query`, `destination.port`, and `user_agent.original`. +- GoalState (`comp=goalstate`) is reconnaissance; `comp=certificates` means the client presented a transport + certificate. Look on the host for `openssl req ... LinuxTransport` or a stolen `.crt`/`.key`. +- Correlate with endpoint network events from the same `host.name` to `168.63.129.16` and process start events for + openssl cms decrypt. +- Search StorageRead platform logs for anonymous or SAS GetBlob against the same storage account after the scrape. + + +*False positive analysis* + + +- Administrative curl or other non-agent clients against WireServer during incident response. Exclude the specific + user agent or host after the change window. +- A new Microsoft guest-agent build with an unfamiliar user agent will fire until that UA is excluded. +- Omitting the user agent looks like the Windows guest agent and is not matched. Do not treat a missing UA as + suspicious on its own. + + +*Response and remediation* + + +- Isolate the VM, rotate secrets recovered from vmSettings, and review extension protectedSettings. +- Enable Metadata Security Protocol in audit or enforce mode to restrict WireServer callers. + + +==== Setup + + + +*Setup* + + +Deploy the https://www.elastic.co/docs/reference/integrations/network_traffic[Network Packet Capture] integration +via Fleet on Azure virtual machines. Default HTTP port lists do not include HostGAPlugin. + +Required integration settings: + +- Enable **Capture HTTP Traffic**. +- Set HTTP ports to include **80** (WireServer GoalState, versions, certificates) and **32526** (HostGAPlugin + `/versions`, `/vmSettings`). Without 32526, HostGAPlugin requests are invisible. +- Enable **Monitor Processes** so HTTP events include `process.*` when available. +- Optional: **Send all headers** to retain `x-ms-version` and `x-ms-guest-agent-public-x509-cert` for investigation. + The rule matches URI, port, and user agent, not the certificate PEM. +- Do not enable request or response body capture for this rule. `/vmSettings` bodies are large and often dropped; + other WireServer XML is not required for the match. + + +==== Rule query + + +[source, js] +---------------------------------- +network where event.module == "network_traffic" and +destination.ip == "168.63.129.16" and +user_agent.original != null and +not user_agent.original : ( + "WALinuxAgent*", + "VMAgent*", + "Python-urllib*", + "cpprestsdk*", + "ACMS/*" +) and +( + url.query : ("*comp=versions*", "*comp=goalstate*", "*comp=certificates*") or + (destination.port == 32526 and url.path : ("/versions", "/vmSettings")) +) + +---------------------------------- + +*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 Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-azure-wireserver-openssl-certificate-decrypt-or-linuxtransport-generation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-azure-wireserver-openssl-certificate-decrypt-or-linuxtransport-generation.asciidoc new file mode 100644 index 0000000000..8cd7565180 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-azure-wireserver-openssl-certificate-decrypt-or-linuxtransport-generation.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-33-azure-wireserver-openssl-certificate-decrypt-or-linuxtransport-generation]] +=== Azure WireServer OpenSSL Certificate Decrypt or LinuxTransport Generation + +Identifies OpenSSL generating a CN=LinuxTransport certificate or decrypting CMS/PKCS7 payloads with a key that is not the Azure Linux Agent certificate under /var/lib/waagent. Adversaries can scrape WireServer certificates, mint a LinuxTransport identity, and decrypt extension protectedSettings with openssl cms -decrypt or smime -decrypt. + +*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://cybercx.com.au/blog/azure-ssrf-metadata/ +* https://www.netspi.com/blog/technical-blog/cloud-pentesting/decrypting-vm-extension-settings-with-azure-wireserver/ +* https://cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services +* https://gtfobins.github.io/gtfobins/openssl/ + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* OS: Linux +* Use Case: Threat Detection +* Platform: Azure +* Platform: Linux +* Tactic: Credential Access +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure WireServer OpenSSL Certificate Decrypt or LinuxTransport Generation* + + +CyberCX-style WireServer abuse on Linux generates `openssl req -x509 -subj /CN=LinuxTransport`, posts the public +certificate to WireServer `comp=certificates`, then runs `openssl cms -decrypt` or `openssl smime -decrypt` with +`temp.key`, `wireserver.key`, or another non-waagent key to unwrap protectedSettings. + +Benign Azure Linux Agent activity looks like: + +`openssl cms -inform DER -decrypt -recip /var/lib/waagent/.crt -inkey /var/lib/waagent/.prv` + +The Azure Linux Agent is excluded by certificate path in process arguments (`/var/lib/waagent/*`) and by +parent executables `/usr/sbin/waagent` and `/usr/bin/waagent`. This does not exclude Python or +`run-command-extension` as parents because attacker scripts invoked via Run Command use those parents +with a non-waagent key. The agent itself also runs `openssl req ... /CN=LinuxTransport` with output +under `/var/lib/waagent/`; that argument path exclusion covers it. + + +*Possible investigation steps* + + +- Review `process.command_line` and `process.args` for `LinuxTransport`, `wireserver.key`, `temp.key`, `payload.p7m`, + or `payload.pfx`. +- Inspect parent and grandparent: Run Command (`/var/lib/waagent/run-command/`) or an interactive shell is higher + risk than a one-off admin session with a ticket. +- Correlate with network events from curl to `168.63.129.16` ports 80 and 32526 on the same host. +- Search StorageRead logs for anonymous or SAS GetBlob of the same storage account after the decrypt. +- Hunt for the generated key files (`temp.key`, `wireserver.key`) on disk and in `/tmp`. + + +*False positive analysis* + + +- The Azure Linux Agent decrypt path under `/var/lib/waagent/` and waagent parent executables + (`/usr/sbin/waagent`, `/usr/bin/waagent`) are excluded. +- Legitimate certificate tooling that uses `-subj /CN=LinuxTransport` is unexpected; treat as suspicious until proven + otherwise. + + +*Response and remediation* + + +- Isolate the VM, delete attacker-generated keys and decrypted payloads, and rotate secrets that were in + protectedSettings (SAS, connection strings, CSE script contents). +- Rotate the VM managed identity and review extension configuration. +- Revoke any SAS that was replayed from the decrypted settings. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start") and process.name == "openssl" and +( + ( + process.args in ("cms", "smime") and process.args == "-decrypt" + ) or + ( + process.args == "req" and process.args : "*LinuxTransport*" + ) +) and +not process.args like "/var/lib/waagent/*" and +not process.parent.executable like ( + "/usr/sbin/waagent", + "/usr/bin/waagent" +) + +---------------------------------- + +*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: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-azure-wireserver-unusual-process-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-azure-wireserver-unusual-process-connection.asciidoc new file mode 100644 index 0000000000..d912dea9d7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-azure-wireserver-unusual-process-connection.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-33-azure-wireserver-unusual-process-connection]] +=== Azure WireServer Unusual Process Connection + +Identifies shells, LOLBins, GTFOBins, and scripting runtimes connecting to the Azure WireServer / HostGAPlugin address 168.63.129.16 on ports 80 or 32526. The guest agent uses this fabric endpoint for GoalState, certificates, and vmSettings. Adversaries with code execution on an Azure VM (including via Run Command) use curl, PowerShell, openssl, bun, or similar tools to enumerate versions, pull transport certificates, and read HostGAPlugin /vmSettings. Azure guest-agent binaries and system python used by waagent are excluded. Descendants of the guest agent are not excluded: Run Command payloads execute in that tree. + +*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://www.netspi.com/blog/technical-blog/cloud-pentesting/decrypting-vm-extension-settings-with-azure-wireserver/ +* https://cybercx.com.au/blog/azure-ssrf-metadata/ +* https://cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services +* https://learn.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16 + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* OS: Linux +* OS: Windows +* Platform: Azure +* Platform: Windows +* 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* + + + +*Investigating Azure WireServer Unusual Process Connection* + + +`168.63.129.16` is the Azure host-only WireServer (TCP 80) and HostGAPlugin (TCP 32526) address. Elastic Defend +network events record the destination IP, port, and initiating process. They do not include the HTTP path; pair this +alert with Network Packet Capture HTTP events when available (`comp=certificates`, `/vmSettings`, `/versions`). + +Do not treat "child of waagent / WindowsAzureGuestAgent" as benign. Azure Run Command and Custom Script Extension +launch attacker scripts as descendants of those agents. Exclude only the agent binaries themselves, which this query +already omits by matching curl, PowerShell, and similar tools. + +`process.Ext.ancestry` is often empty on these network events, so EQL `descendant of` is not reliable here. + + +*Possible investigation steps* + + +- Review `process.name`, `process.executable`, and `process.command_line` on nearby process start events. Look for + `comp=certificates`, `32526`, `vmSettings`, `LinuxTransport`, or `openssl cms -decrypt`. +- Note `destination.port`: 32526 from curl or PowerShell is uncommon for legitimate guest-agent traffic (agents use + `WaAppAgent.exe`, `WindowsAzureGuestAgent.exe`, `CollectGuestLogs.exe`, or `/usr/bin/python3.10` / waagent). +- Correlate with `169.254.169.254` IMDS access from the same process, especially `/metadata/v1/instanceinfo` (no + Metadata header) or `/metadata/identity/oauth2/token`. +- Check Azure Activity Logs for `runCommand/action` or extensions/write against this VM. +- Search StorageRead platform logs for subsequent SAS GetBlob of vmsettings or cse objects. + + +*False positive analysis* + + +- In-house monitoring that wraps curl to WireServer. Exclude by `process.executable` or a signed parent after + validating the script contents. +- Do not exclude all children of the guest agent; that hides Run Command abuse. + + +*Response and remediation* + + +- Isolate the VM, rotate its managed identity and any SAS recovered from vmSettings, and review extension + protectedSettings for injected configuration. +- Remove unauthorized Run Command resources and Custom Script extensions. +- Consider Azure Metadata Security Protocol (audit/enforce) to restrict which processes may call WireServer. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category: network and host.os.type: (linux or windows) and + destination.ip: "168.63.129.16" and destination.port: (80 or 32526) and + ( + process.name: ( + bash or dash or sh or tcsh or csh or zsh or ksh or fish or mksh or busybox or + bun or bun.exe or node or node.exe or nodejs or deno or deno.exe or + java or java.exe or javaw or javaw.exe or + curl or curl.exe or wget or wget.exe or + powershell.exe or pwsh.exe or pwsh or cmd.exe or + certutil.exe or bitsadmin.exe or mshta.exe or rundll32.exe or + wscript.exe or cscript.exe or regsvr32.exe or + openssl or openssl.exe or nc or ncat or netcat or socat or + python.exe or pythonw.exe or perl or perl.exe or ruby or ruby.exe or + php or php.exe or lua or lua.exe + ) or + process.executable: ( + ./* or /tmp/* or /var/tmp/* or /dev/shm/* or /run/* or /var/run/* or + /home/*/* or /root/* or *\:\\Users\\* or *\:\\ProgramData\\* + ) + ) and + not process.executable: ( + /usr/sbin/waagent or /usr/bin/waagent or /usr/bin/python3* or + /usr/lib/systemd/systemd-resolved or /lib/systemd/systemd-resolved or + *\:\\WindowsAzure\\Packages\\* or *\:\\WindowsAzure\\GuestAgent*\\* or + *\:\\WindowsAzure\\SecAgent\\* + ) + +---------------------------------- + +*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 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-33/prebuilt-rule-8-19-33-elastic-defend-and-network-security-alerts-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-elastic-defend-and-network-security-alerts-correlation.asciidoc new file mode 100644 index 0000000000..9a95442023 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-elastic-defend-and-network-security-alerts-correlation.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-33-elastic-defend-and-network-security-alerts-correlation]] +=== Elastic Defend and Network Security Alerts Correlation + +This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto Networks (PANW), Fortinet Fortigate and Suricata by host.ip and source.ip. This may indicate that this host is compromised and triggering multi-datasource alerts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Fortinet +* Data Source: PAN-OS +* Data Source: Suricata + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Elastic Defend and Network Security Alerts Correlation* + + +This rule correlate any Elastic Defend alert with suspicious events from Network Security datasources like Palo Alto Networks (PANW), Fortinet Fortigate and Suricata by host.ip and source.ip. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host and users involved. +- Investiguate the network alerts by destination.ip and message. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- IP address ranges overlap where the host.ip value from the Elastic Defend alert is unrelated to the source.ip value from the Network Security alert. +- Alerts from routine administrative tasks may trigger multiple alerts. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Setup + + + +*Setup* + + +This rule requires the `host.ip` field to be populated. +For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**. + +If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the +https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-* metadata _id +| WHERE + // Elastic Defend Alerts + (event.module == "endpoint" and data_stream.dataset == "endpoint.alerts") or + + // PANW suspicious events + (data_stream.dataset == "panw.panos" and + event.action in ("virus_detected", "wildfire_virus_detected", "c2_communication", "spyware_detected", "large_upload", "denied", "exploit_detected")) or + + // Fortigate suspicious events + (data_stream.dataset == "fortinet_fortigate.log" and + (event.action in ("outbreak-prevention", "infected", "blocked") or message like "backdoor*" or message like "Proxy*" or message like "anomaly*" or message like "P2P*" or message like "misc*" or message like "DNS.Over.HTTPS" or message like "Remote.Access")) or + + // Suricata + (data_stream.dataset == "suricata.eve" and message in ("Command and Control Traffic", "Potentially Bad Traffic", "A Network Trojan was detected", "Detection of a Network Scan", "Domain Observed Used for C2 Detected", "Malware Command and Control Activity Detected")) + +// extract source.ip from PANW, Fortigate or Suricata events and host.ip from Elastic Defend alert +|eval fw_alert_source_ip = CASE(data_stream.dataset in ("panw.panos", "fortinet_fortigate.log", "suricata.eve"), source.ip, null), + elastic_defend_alert_host_ip = CASE(event.module == "endpoint" and data_stream.dataset == "endpoint.alerts", host.ip, null) +| eval Esql.source_ip = COALESCE(fw_alert_source_ip, elastic_defend_alert_host_ip) +| where Esql.source_ip is not null + +// group by host_source_ip shared between FG/PANW/Suricata and Elastic Defend +| stats Esql.alerts_count = COUNT(*), + Esql.event_module_distinct_count = COUNT_DISTINCT(event.module), + Esql.message_values_distinct_count = COUNT_DISTINCT(message), + Esql.event_module_values = VALUES(event.module), + Esql.message_values = VALUES(message), + Esql.event_action_values = VALUES(event.action), + Esql.process_executable_values = VALUES(process.executable), + Esql.process_hash_sha256_values = VALUES(process.hash.sha256), + Esql.process_cmdline_values = VALUES(process.command_line), + Esql.file_path_values = VALUES(file.path), + Esql.file_hash_sha256_values = VALUES(file.hash.sha256), + Esql.host_id_values = VALUES(host.id), + Esql.user_name_values = VALUES(user.name), + Esql.destination_ip_values = VALUES(destination.ip) + by Esql.source_ip +| where Esql.event_module_distinct_count >= 2 AND Esql.message_values_distinct_count >= 2 +| eval concat_module_values = MV_CONCAT(Esql.event_module_values, ",") +// Make sure an endpoint alert is present along one of the network ones +| where concat_module_values like "*endpoint*" + +// Move single values to their corresponding ECS fields for alerts exclusion +| eval source.ip = mv_min(Esql.source_ip), + host.id = mv_min(Esql.host_id_values), + user.name = mv_min(Esql.user_name_values) + +| keep source.ip, host.id, user.name, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-entra-id-device-bound-prt-from-unusual-device-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-entra-id-device-bound-prt-from-unusual-device-ip.asciidoc new file mode 100644 index 0000000000..48dcf10e03 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-entra-id-device-bound-prt-from-unusual-device-ip.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-33-entra-id-device-bound-prt-from-unusual-device-ip]] +=== Entra ID Device-Bound PRT from Unusual Device IP + +Detects a first-party FOCI tooling client (Azure CLI, PowerShell, VS Code, Graph CLI, Azure AD PowerShell, or Visual Studio) redeeming a device-bound Primary Refresh Token (PRT) for Microsoft Graph, SharePoint/OneDrive, or Exchange Online from a source IP that has not been seen with that deviceid. Replay events are limited to compliant or Intune-managed devices. Adversaries who steal a WAM PRT SSO cookie replay it off-box; the token keeps the workstation deviceid, so this pair is new even when Windows Sign-In for that device is outside a correlation window. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* 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.armadin.com/blog-posts/prtremote-extract-prt-cookies-remotely-with-interactivetoken-scheduled-task +* https://github.com/armadin-public/PRTremote +* https://github.com/dmcxblue/ANIMO/blob/master/helpers/scripts/GrabTokenAzureAD/PrtExtractor.cs +* https://github.com/rvrsh3ll/TokenTactics +* https://github.com/Gerenios/AADInternals + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Platform: Entra ID +* Tactic: Credential Access +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Rule Type: New Terms + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Device-Bound PRT from Unusual Device IP* + + +This rule fires when a tooling FOCI client redeems a device-bound PRT from a `source.ip` that has not appeared with that `device_id` in the prior 5 days. Unlike **Entra ID Device-Bound PRT Replay via First-Party App from Unusual IP**, it does not need a Windows Sign-In or WAM event in the same window — so a workstation that last signed in yesterday still alerts when the cookie is redeemed from a new address. + +PRTremote and similar harvest tools steal a WAM PRT SSO cookie and POST it from attacker infrastructure. The issued token keeps the *workstation* deviceid, so Conditional Access that requires a compliant device can succeed. Replay events must be `is_compliant` or `is_managed`. The stolen cookie nonce is typically valid for about five minutes; that is the attacker’s redeem window, not this rule’s history. + +This is not ConsentFix / OAuth-code phishing. Those flows show `OAuth2:Authorize` with `Redirect` and often lack a bound compliant device. + + +*Possible investigation steps* + + +- Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.device_detail.device_id`, `azure.signinlogs.properties.device_detail.display_name`, and `source.ip`. Confirm `incoming_token_type` is `primaryRefreshToken` and `device_detail.is_compliant` / `is_managed` are true. +- Compare `azure.signinlogs.properties.app_display_name` and `user_agent.original` with the resource (`resource_display_name`). A cookie POST through WAM can show a Trident/MSIE user agent on the Azure CLI client ID; that is the same IE stack legitimate Windows `az login` uses when it brokers through WAM, so it is triage context, not a detection key. TokenTactics commonly presents as Microsoft Office (that client is omitted here; hunt it separately if harvest is already confirmed). +- Hunt prior Windows Sign-In / `Windows-AzureAD-Authentication-Provider/1.0` events for the same deviceid. If those IPs differ from `source.ip`, treat this as the same story as the ES|QL companion. A Microsoft-owned ASN (including 8075) does not clear the alert. +- Hunt endpoint telemetry for the same user or device display name as `host.name`: InteractiveToken scheduled tasks, `svchost.exe` (Schedule) → `cmd.exe` → `BrowserCore.exe`, or files `formatted_nonce.txt` / `prt_cookie.txt`. +- Review Graph, SharePoint, and mailbox activity after the sign-in for directory, file, or mail enumeration. + + +*False positive analysis* + + +- Developers who run Azure CLI, Graph CLI, or VS Code from a new network while WAM still attaches the workstation deviceid. Exception known Cloud Shell / jump-host IPs after confirming the client actually ran there. +- First use of a tooling client on a new device, or the first time a laptop appears on a new ISP, will fire once per `(device_id, source.ip)` pair and then age out of novelty. +- Hybrid-joined workstations that report both `is_compliant` and `is_managed` as false (no Intune) will not match. Hunt those deviceids separately if harvest is already confirmed. +- Microsoft Teams, Office, OneDrive SyncEngine, Authentication Broker, Outlook Mobile, Bing, Azure Portal, and Office 365 Management are excluded. Do not treat their absence as a miss. + + +*Response and remediation* + + +- Contact the user to confirm whether they ran the first-party client from `source.ip`. +- If unauthorized, revoke refresh tokens and primary refresh tokens for the user. The deviceid on the token is often the *legitimate* workstation — do not delete that device as if it were a ROADtx registration until you confirm otherwise. +- Isolate the workstation, hunt for InteractiveToken scheduled tasks and BrowserCore harvest, and treat the admin identity that registered the task as a second compromised principal. + + +==== Setup + + +The Azure Fleet integration (or Filebeat Azure module) with Microsoft Entra ID sign-in logs is required. Ingest `SignInLogs` and `NonInteractiveUserSignInLogs` into `logs-azure.signinlogs-*`. + +See https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins[Microsoft Entra ID sign-in logs] and the https://docs.elastic.co/integrations/azure[Azure integration]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.signinlogs and + event.outcome: success and + azure.signinlogs.properties.status.error_code: 0 and + azure.signinlogs.properties.incoming_token_type: "primaryRefreshToken" and + azure.signinlogs.properties.device_detail.device_id: * and + source.ip: * and + ( + azure.signinlogs.properties.device_detail.is_compliant: true or + azure.signinlogs.properties.device_detail.is_managed: true + ) and azure.signinlogs.properties.app_id: ( + "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or + "1950a258-227b-4e31-a9cf-717495945fc2" or + "aebc6443-996d-45c2-90f0-388ff96faa56" or + "14d82eec-204b-4c2f-b7e8-296a70dab67e" or + "1b730954-1685-4b74-9bfd-dac224a7b894" or + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" + ) and azure.signinlogs.properties.resource_id: ( + "00000003-0000-0000-c000-000000000000" or + "00000003-0000-0ff1-ce00-000000000000" or + "6a9b9266-8161-4a7b-913a-a9eda19da220" or + "00000002-0000-0ff1-ce00-000000000000" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-entra-id-device-bound-prt-replay-via-first-party-app-from-unusual-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-entra-id-device-bound-prt-replay-via-first-party-app-from-unusual-ip.asciidoc new file mode 100644 index 0000000000..3d94c72d48 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-entra-id-device-bound-prt-replay-via-first-party-app-from-unusual-ip.asciidoc @@ -0,0 +1,226 @@ +[[prebuilt-rule-8-19-33-entra-id-device-bound-prt-replay-via-first-party-app-from-unusual-ip]] +=== Entra ID Device-Bound PRT Replay via First-Party App from Unusual IP + +Detects a first-party FOCI tooling client (Azure CLI, PowerShell, VS Code, Graph CLI, Azure AD PowerShell, or Visual Studio) redeeming a device-bound Primary Refresh Token (PRT) for Microsoft Graph, SharePoint/OneDrive, or Exchange Online from an IP that is not among that user and device's Windows Sign-In or WAM addresses. Replay events are limited to compliant or Intune-managed devices: the stolen cookie keeps the workstation deviceid, so compliant-device Conditional Access can succeed off-box. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-24h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.armadin.com/blog-posts/prtremote-extract-prt-cookies-remotely-with-interactivetoken-scheduled-task +* https://github.com/armadin-public/PRTremote +* https://github.com/dmcxblue/ANIMO/blob/master/helpers/scripts/GrabTokenAzureAD/PrtExtractor.cs +* https://github.com/rvrsh3ll/TokenTactics +* https://github.com/Gerenios/AADInternals + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Platform: Entra ID +* Tactic: Credential Access +* Tactic: Defense Evasion +* Tactic: Initial Access +* Resources: Investigation Guide +* Rule Type: ESQL + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Device-Bound PRT Replay via First-Party App from Unusual IP* + + +Adversaries who steal a WAM PRT SSO cookie (BrowserCore / InteractiveToken harvest) redeem it off-box for Microsoft Graph, SharePoint/OneDrive, or Exchange Online using a first-party FOCI client. PRTremote uses Azure CLI (`04b07795-8ddb-461a-bbee-02f9e1bf7b46`); TokenTactics and AADInternals can use Azure AD PowerShell (`1b730954-1685-4b74-9bfd-dac224a7b894`) or Microsoft Office (`d3590ed6-52b3-4102-aeff-aad2292ab01c`) when refreshing a PRT into a Graph, Outlook, or SharePoint token. This rule keys on CLI / PowerShell / VS Code / Visual Studio, not Teams, Office, OneDrive SyncEngine, Authentication Broker, Outlook Mobile, Bing, or Azure Portal — those clients routinely egress on a different IP than Windows Sign-In. Hunt Office-client PRT separately if harvest is already confirmed. The issued access token carries the *workstation* `deviceid`, so Conditional Access policies that require a compliant device can succeed even though the redeeming IP is not the device. Replay events must be `is_compliant` or `is_managed` so the join tracks a stolen enrolled workstation PRT, not an unmanaged ROADtx device. + +This is not ConsentFix / OAuth-code phishing. Those flows show `OAuth2:Authorize` with `Redirect` and often lack a bound compliant device on the Graph token. Do not close this alert by following the first-party OAuth phishing playbook alone. + + + +*Possible investigation steps* + + +- Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.device_detail.device_id`, and `source.ip`. Confirm `incoming_token_type` on the replay events is `primaryRefreshToken` and `device_detail.is_compliant` / `is_managed` are true. `Esql.resource_display_name_values` should be Microsoft Graph, Office 365 SharePoint Online, OneDrive for Business, and/or Office 365 Exchange Online. +- Treat `Esql.source_ip_device_values` as the workstation (Windows Sign-In / `Windows-AzureAD-Authentication-Provider/1.0`) — the device the PRT was bound to, and the likely theft origin. Treat `source.ip` / `Esql.source_ip_replay_values` as Graph / SharePoint / Exchange PRT IPs that are not in that device-session set (the replay actor). On-box FOCI from the workstation IP is excluded from the replay set. The harvest emulation showed workstation public IP versus attacker SNAT — including Azure ASN 8075, so a Microsoft-owned ASN does not clear the alert. The stolen PRT cookie nonce is typically valid for about five minutes; that is the attacker’s redeem window, not this rule’s lookback. The workstation may have signed in hours earlier, so the query correlates 24 hours of Windows Sign-In / WAM IPs with the replay. +- Inspect `Esql.app_display_name_values` and `Esql.user_agent_original_values`. A cookie POST through WAM can show a Trident/MSIE user agent on the Azure CLI client ID; that is the same IE stack legitimate Windows `az login` uses when it brokers through WAM, so it is triage context, not a detection key. TokenTactics Graph refresh commonly presents as Microsoft Office (omitted here). A follow-on `python-requests/*` Graph token from the same session is tooling, not the first-party binary on the workstation. +- Hunt endpoint telemetry for the same user or `device_detail.display_name` as `host.name`: `svchost.exe` (Schedule) → `cmd.exe` → `BrowserCore.exe` with `<` / `>` redirection, or files `formatted_nonce.txt` / `prt_cookie.txt`. +- Intune audit (`create-clientcertificate`) is enrollment context only; it will not fire on the harvest. Use it as optional join on user OID, not as coverage. +- Review Graph, SharePoint, and mailbox activity after the replay for directory, file, or mail enumeration. + + +*False positive analysis* + + +- Developers who run Azure CLI, Graph CLI, or VS Code from a different egress than Windows Sign-In while WAM still attaches the workstation deviceid. Exception known Cloud Shell / jump-host IPs after confirming the client actually ran there. +- Microsoft Teams, Office, OneDrive SyncEngine, Authentication Broker, Outlook Mobile, Bing, Azure Portal, and Office 365 Management Graph PRT are excluded. Do not treat their absence as a miss; they are omitted because split-tunnel M365 egress is routine. +- First sign-in of a new device can have sparse Windows Sign-In history in the 24-hour window; widen the hunt before responding. +- Hybrid-joined workstations that report both `is_compliant` and `is_managed` as false (no Intune) will not match the replay branch. Hunt those deviceids separately if harvest is already confirmed. + + +*Response and remediation* + + +- Contact the user to confirm whether they ran the first-party client in `Esql.app_display_name_values` from the replay IP. +- If unauthorized, revoke refresh tokens and primary refresh tokens for the user. The deviceid on the token is often the *legitimate* workstation — do not delete that device as if it were a ROADtx registration until you confirm otherwise. +- Isolate the workstation, hunt for InteractiveToken scheduled tasks and BrowserCore harvest, and treat the admin identity that registered the task as a second compromised principal. + + +==== Setup + + +The Azure Fleet integration (or Filebeat Azure module) with Microsoft Entra ID sign-in logs is required. Ingest `SignInLogs` and `NonInteractiveUserSignInLogs` into `logs-azure.signinlogs-*` so Windows Sign-In / WAM device activity and FOCI Graph, SharePoint, and Exchange token issuance are both available for the join. + +See https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins[Microsoft Entra ID sign-in logs] and the https://docs.elastic.co/integrations/azure[Azure integration]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-* +// find successful sign-in events where a managed device exists +| where event.dataset == "azure.signinlogs" + and azure.signinlogs.properties.status.error_code == 0 + and azure.signinlogs.properties.device_detail.device_id is not null + +// filter for device sign-in events from Windows Sign-In or WAM (login session) +| eval Esql.is_device_session = azure.signinlogs.properties.app_display_name == "Windows Sign In" + or user_agent.original == "Windows-AzureAD-Authentication-Provider/1.0" + +// filter for tooling FOCI clients that can redeem a PRT (replay) +| eval Esql.is_prt_replay = azure.signinlogs.properties.app_id in ( + "04b07795-8ddb-461a-bbee-02f9e1bf7b46", // Microsoft Azure CLI + "1950a258-227b-4e31-a9cf-717495945fc2", // Microsoft Azure PowerShell + "aebc6443-996d-45c2-90f0-388ff96faa56", // Visual Studio Code + "14d82eec-204b-4c2f-b7e8-296a70dab67e", // Microsoft Graph Command Line Tools + "1b730954-1685-4b74-9bfd-dac224a7b894", // Azure Active Directory PowerShell + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" // Visual Studio + ) + + // target resource are common adversary targets for access + and azure.signinlogs.properties.resource_id in ( + "00000003-0000-0000-c000-000000000000", // Microsoft Graph + "00000003-0000-0ff1-ce00-000000000000", // Office 365 SharePoint Online + "6a9b9266-8161-4a7b-913a-a9eda19da220", // OneDrive for Business + "00000002-0000-0ff1-ce00-000000000000" // Office 365 Exchange Online + ) + and azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken" + and ( + azure.signinlogs.properties.device_detail.is_compliant == true + or azure.signinlogs.properties.device_detail.is_managed == true + ) + +// device session or PRT replay event have to exist +| where Esql.is_device_session or Esql.is_prt_replay + +// aggregate entities for both device session and PRT replay events +// aggregate by user and device +| stats + Esql.source_ip_device_values = values(source.ip) where Esql.is_device_session, + Esql.source_ip_replay_values = values(source.ip) where Esql.is_prt_replay, + Esql.event_count_replay = count(*) where Esql.is_prt_replay, + Esql.event_count_device_session = count(*) where Esql.is_device_session, + Esql.user_principal_name_values = values(azure.signinlogs.properties.user_principal_name), + Esql.app_display_name_values = values(azure.signinlogs.properties.app_display_name) where Esql.is_prt_replay, + Esql.resource_id_values = values(azure.signinlogs.properties.resource_id) where Esql.is_prt_replay, + Esql.resource_display_name_values = values(azure.signinlogs.properties.resource_display_name) where Esql.is_prt_replay, + Esql.device_display_name_values = values(azure.signinlogs.properties.device_detail.display_name), + Esql.user_agent_original_values = values(user_agent.original) where Esql.is_prt_replay, + Esql.device_is_compliant_values = values(azure.signinlogs.properties.device_detail.is_compliant) where Esql.is_prt_replay, + Esql.device_is_managed_values = values(azure.signinlogs.properties.device_detail.is_managed) where Esql.is_prt_replay, + Esql.authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement) where Esql.is_prt_replay, + Esql.conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status) where Esql.is_prt_replay, + Esql.earliest_timestamp = min(@timestamp), + Esql.latest_timestamp = max(@timestamp) + by azure.signinlogs.properties.user_id, azure.signinlogs.properties.device_detail.device_id + +// filter for PRT replay events that have at least one replay IP +| where Esql.event_count_replay > 0 + and Esql.event_count_device_session > 0 + and Esql.source_ip_replay_values is not null + and Esql.source_ip_device_values is not null + +// expand the replay IP list and keep only IPs that are not in the device-session set +| mv_expand Esql.source_ip_replay_values +| where not mv_contains(Esql.source_ip_device_values, Esql.source_ip_replay_values) +| eval Esql.source_ip_replay = Esql.source_ip_replay_values, + user.id = azure.signinlogs.properties.user_id, + source.ip = Esql.source_ip_replay_values +| keep + user.id, + source.ip, + azure.signinlogs.properties.user_id, + azure.signinlogs.properties.device_detail.device_id, + Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-entra-id-windows-hello-for-business-credential-registered.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-entra-id-windows-hello-for-business-credential-registered.asciidoc new file mode 100644 index 0000000000..c06182842a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-entra-id-windows-hello-for-business-credential-registered.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-33-entra-id-windows-hello-for-business-credential-registered]] +=== Entra ID Windows Hello for Business Credential Registered + +Identifies the first-seen registration of a Windows Hello for Business (WHfB) credential for a Microsoft Entra ID user from a given source ASN in a tenant, based on a prefixed historic window. Enrollment is commonly part of legitimate onboarding or passwordless rollout and is not inherently malicious. Adversaries who have obtained a token that satisfies fresh (NGC) multi-factor authentication, for example by borrowing an existing WHfB key or passkey, can also enroll their own WHfB credential to establish durable, phishing-resistant persistence that survives password resets and standard session revocation. Correlate first-seen enrollments with the sign-in and device state that preceded them. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.auditlogs-* + +*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://dirkjanm.io/borrowing-windows-hello-keys/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Platform: Entra ID +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Persistence +* Rule Type: New Terms +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Windows Hello for Business Credential Registered* + + +This is a first-seen (new_terms) signal: a WHfB credential was registered for a tenant/user/source-ASN combination not observed in the prior 14 days. Enrollment is often legitimate onboarding, but adversaries abuse the same action as persistence - after borrowing an existing WHfB key or passkey to satisfy fresh MFA, they enroll their own credential, which survives password resets and ordinary session revocation. + + +*Possible investigation steps* + +- Identify the target (`target_resources.0.user_principal_name`) and initiator (`initiated_by.user.userPrincipalName`), confirm whether WHfB enrollment was expected, and check whether the source ASN is new for that user. +- Correlate with `azure.signinlogs` shortly before for a deviceless WHfB/passkey sign-in, device-code flow, or attacker device registration/PRT issuance; an additional credential from a new ASN on an established account is more suspicious. Examine the preceding sign-in's source IP/geo and user agent for automation or hosting/VPS origins. + + +*False positive analysis* + +- First-time WHfB enrollment during onboarding/passwordless rollout is expected; repeat enrollments from the same tenant/user/ASN within 14 days don't fire. +- Users traveling or switching ISP/VPN may appear as a new ASN - validate against known networks before treating as suspicious. + + +*Response and remediation* + +- If unauthorized, delete the WHfB credential and any attacker-registered device via Graph or the Entra portal, revoke sessions and refresh tokens (delete devices first, to break device-bound PRT persistence), reset credentials, and re-enroll from a trusted device. +- Review the sign-in that authorized the enrollment to determine the initial access vector. + + +==== Setup + + + +*Required Microsoft Entra ID Audit Logs* + +This rule requires the Azure integration with Microsoft Entra ID Audit logs enabled and collected via Azure Event Hub. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" and + azure.auditlogs.operation_name: "Add Windows Hello for Business credential" and + event.outcome: ("Success" or "success") and + azure.tenant_id: * and + azure.auditlogs.properties.initiated_by.user.userPrincipalName: * and + source.as.number: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-entra-id-windows-hello-or-passkey-sign-in-from-unregistered-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-entra-id-windows-hello-or-passkey-sign-in-from-unregistered-device.asciidoc new file mode 100644 index 0000000000..845aa7ccd7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-entra-id-windows-hello-or-passkey-sign-in-from-unregistered-device.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-33-entra-id-windows-hello-or-passkey-sign-in-from-unregistered-device]] +=== Entra ID Windows Hello or Passkey Sign-in from Unregistered Device + +Identifies a Microsoft Entra ID sign-in that is satisfied by a phishing-resistant, device-bound credential (Windows Hello for Business, FIDO2 security key, or passkey) while carrying no device identifier. Windows Hello for Business (WHfB) and passkey credentials are bound to a device's TPM, so a genuine sign-in with one of these methods is normally accompanied by the registered device it lives on. A WHfB or passkey assertion that authenticates with an empty `device_detail.device_id` indicates the underlying key material is being used away from its bound device, for example by an adversary who extracted the key (or signed an assertion with it) and replayed it from attacker infrastructure to mint device-agnostic tokens. This is the core primitive of the "borrowing Windows Hello keys" technique and is a strong precursor to attacker device registration and Primary Refresh Token (PRT) issuance. Cross-tenant (B2B) sign-ins are excluded because they are a common benign source of empty device identifiers. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.signinlogs-* + +*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://dirkjanm.io/borrowing-windows-hello-keys/ +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Platform: Entra ID +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Initial Access +* Rule Type: New Terms +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Windows Hello or Passkey Sign-in from Unregistered Device* + + +WHfB and passkey credentials are bound to a device's TPM, so a legitimate sign-in with one of these methods is normally accompanied by its registered device. A same-tenant sign-in with an empty `device_detail.device_id` means the key material is being used away from its bound device - the core signal of the "borrowing Windows Hello keys" technique, where an adversary replays a WHfB/NGC key or passkey to mint device-agnostic tokens from their own infrastructure. + + +*Possible investigation steps* + +- Identify the user via `user_principal_name` and confirm `authentication_details.authentication_method` is WHfB, FIDO2, or a passkey with `device_detail.device_id` empty (a `device_id` present on an unmanaged device is a different, noisier condition, not this rule). +- Review `app_id`/`resource_display_name` for Graph or Device Registration Service access right after, check `source.ip`, `source.geo.*`, and `user_agent.original` for automation (python-requests) or hosting/VPS ASNs (ROADtools/roadtx), and pivot on `user_id` in `azure.auditlogs` for a subsequent "Register device" or "Add Windows Hello for Business credential" event; if the user didn't enroll a new key/passkey, treat it as compromised. + + +*False positive analysis* + +- Initial passwordless onboarding can briefly produce this sign-in before device registration completes; correlate with the registration timeline. + + +*Response and remediation* + +- Treat the key/passkey as compromised: delete the credential and any attacker-registered device via Graph/the Entra portal, revoke sessions/refresh tokens (delete devices first, since that breaks device-bound PRT persistence), and re-enroll from a trusted device. +- Hunt for device registrations and PRT issuance after the sign-in, and consider Conditional Access requiring device compliance for sensitive resources. + + +==== Setup + + + +*Required Microsoft Entra ID Sign-In Logs* + +This rule requires the Azure integration with Microsoft Entra ID Sign-In logs to be enabled and configured to collect sign-in logs via Azure Event Hub. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and + event.category: "authentication" and + azure.signinlogs.result_signature: "SUCCESS" and + azure.signinlogs.properties.user_type: "Member" and + azure.signinlogs.properties.authentication_details.authentication_method: ( + "Windows Hello for Business" or *passkey* or FIDO2* or *Passkey* + ) and + azure.signinlogs.properties.device_detail.device_id: ("" or not *) and + azure.signinlogs.properties.cross_tenant_access_type: "none" and + azure.signinlogs.properties.user_principal_name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* 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-33/prebuilt-rule-8-19-33-file-with-suspicious-double-extension-created-by-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-file-with-suspicious-double-extension-created-by-web-server.asciidoc new file mode 100644 index 0000000000..e3c77b32f6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-file-with-suspicious-double-extension-created-by-web-server.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-33-file-with-suspicious-double-extension-created-by-web-server]] +=== File with Suspicious Double Extension Created by Web Server + +This rule detects when a web server process creates a file with a double extension, where the real extension is a non-web extension. This is a common technique used by attackers to bypass security measures and to hide the true nature of the file. + +*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*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Persistence +* Tactic: Initial Access +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Rule Type: Event Correlation (EQL) +* 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 File with Suspicious Double Extension Created by Web Server* + + +This rule identifies Linux web server processes creating files whose names combine a web-executable suffix with a misleading image, archive, script, or binary extension, a pattern often used to conceal malicious content and bypass upload controls. For example, an attacker exploiting an upload endpoint may write `shell.php.jpg` into a served directory, then rely on a permissive or manipulated server configuration to execute it as a web shell for persistent remote access. + + +*Possible investigation steps* + + +- Record the file’s full path, ownership, permissions, timestamps, cryptographic hash, MIME type, and magic bytes, then safely inspect its contents for obfuscated code, command execution, credential theft, or web-shell functionality. +- Review virtual-host, handler, rewrite, and directory configuration to determine whether the file is web-accessible or interpreted as executable content despite its final extension. +- Correlate the creation time with HTTP access, application, proxy, and authentication logs to identify the originating request, source address, user session, upload endpoint, and related reconnaissance or exploitation attempts. +- Examine the creating process lineage and subsequent activity for spawned shells, interpreters, system utilities, outbound connections, privilege escalation, persistence changes, or additional file writes. +- Hunt across endpoints and web logs for the file hash, naming pattern, source address, request indicators, and similar artifacts, and isolate the server while preserving evidence if malicious activity is confirmed. + + +*False positive analysis* + + +- A legitimate upload or content-management workflow may preserve a user-supplied filename such as `template.php.jpg`; verify the associated HTTP request, authenticated user, expected upload path, file MIME type, and application behavior. +- A deployment, backup, or testing process run through a web application may generate files such as `page.jsp.zip` or `handler.cgi.sh`; verify the change record, process lineage, file contents, ownership, and whether the destination is expected and non-executable. + + +*Response and remediation* + + +- Isolate the affected web server from untrusted networks, restrict administrative access, preserve the suspicious file and relevant logs, and block identified source addresses, hashes, domains, and URLs. +- Remove the double-extension file and any related web shells, unauthorized accounts, SSH keys, cron jobs, systemd units, startup scripts, modified web-server handlers, and attacker-created files after preserving forensic copies. +- Rotate exposed application, database, service-account, API, and administrative credentials, revoke active sessions and tokens, and replace potentially compromised TLS or SSH keys. +- Escalate immediately to incident response if the web server spawned shells, made suspicious outbound connections, accessed credentials, gained elevated privileges, or produced evidence of lateral movement or additional compromised hosts. +- Rebuild the server from a known-good image or restore verified clean application content and configuration, patch the exploited web application or server component, and validate integrity before returning it to service. +- Prevent recurrence by enforcing upload allowlists and content validation, storing uploads outside executable web roots, disabling script execution in upload directories, applying least-privilege permissions, and monitoring for similar filenames and web-process child activity. + + +==== 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] +---------------------------------- +file where host.os.type == "linux" and event.action != "deletion" and +( + process.name in ( + "nginx", "apache2", "httpd", "caddy", "lighttpd", "httpd.worker", "httpd-worker", "httpd-prefork", + "php-cgi", "php-fcgi", "php-cgi.cagefs", "frankenphp", "lshttpd", "litespeed", "openlitespeed", + "fcgiwrap", "uwsgi", "daphne", "uvicorn", "hypercorn", "granian", "waitress-serve", "flask", "puma", + "unicorn", "unicorn_rails", "thin", "rackup", "mongrel_rails", "starman", "plackup", "twiggy", + "hypnotoad", "starlet", "unitd", "unitd-debug", "java", "node", "nodejs", "varnishd" + ) or + process.name like ( + "php-fpm*", "lsphp*", "gunicorn*", "*.cgi", "*.fcgi", "mono*", "xsp*", "mod-mono-server*", + "fastcgi-mono-server*", "python*", "ruby*", "perl*", "lua*" + ) +) and +file.name like~ ( + "*.php.*", "*.php3.*", "*.php4.*", "*.php5.*", "*.php7.*", "*.php8.*", "*.phtml.*", "*.pht.*", + "*.asp.*", "*.aspx.*", "*.ashx.*", "*.asmx.*", "*.jsp.*", "*.jspx.*", "*.cfm.*", "*.cfc.*", + "*.cshtml.*", "*.razor.*", "*.cgi.*", "*.fcgi.*", "*.php;*", "*.asp;*", "*.aspx;*", "*.jsp;*" +) and +file.extension in~ ( + "jpg", "jpeg", "png", "gif", "webp", "bmp", "ico", "tif", "tiff", "svg", "zip", + "sh", "elf" +) + +---------------------------------- + +*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: 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-first-seen-network-flow-exporter-followed-by-suspicious-source-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-first-seen-network-flow-exporter-followed-by-suspicious-source-activity.asciidoc new file mode 100644 index 0000000000..c35fc38523 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-first-seen-network-flow-exporter-followed-by-suspicious-source-activity.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-33-first-seen-network-flow-exporter-followed-by-suspicious-source-activity]] +=== First Seen Network Flow Exporter Followed by Suspicious Source Activity + +Identifies a newly observed NetFlow, IPFIX, or sFlow exporter IP followed by another detection alert with medium-or-higher severity or an elevated risk score, where that exporter IP is the source of the detected activity in the same data stream namespace. This correlation adds behavioral evidence that can help distinguish routine exporter onboarding from a potentially unauthorized or compromised exporter introduced as part of defense evasion. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/solutions/security/detect-and-alert/about-building-block-rules +* https://www.elastic.co/docs/reference/integrations/netflow +* https://www.elastic.co/docs/reference/integrations/goflow2 +* https://datatracker.ietf.org/doc/html/rfc7011 +* https://sflow.org/sflow_version_5.txt + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Rule Type: Higher-Order Rule +* Data Source: Elastic Security +* Data Source: NetFlow +* Data Source: GoFlow2 +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Seen Network Flow Exporter Followed by Suspicious Source Activity* + + +This higher-order rule correlates the building-block alert "First Seen Network Flow Exporter" with a later detection +alert that has medium-or-higher severity or an elevated risk score within 30 minutes. The new exporter's `observer.ip` +must equal the later alert's `source.ip`, and both alerts must share the same `data_stream.namespace`. + +This relationship provides stronger evidence than suspicious flows merely reported by the exporter. It indicates that +the exporter address itself was subsequently identified as the source of separately detected activity. It does not by +itself prove telemetry injection, exporter compromise, or the addition of a rogue collector. A rogue collector receives +flow exports and generally requires network-device configuration or audit telemetry to detect directly. + + +*Possible investigation steps* + + +- Review the `observer.ip`, `source.ip`, correlation timestamps, and suspicious rule names and IDs surfaced in the + alert. Pivot to the contributing alerts to review their risk score, destination, host, and user context. +- Confirm that `observer.ip` belongs to the newly observed exporter and that NAT, shared addressing, or stale asset + records did not cause the correlation. +- Examine the second alert's rule name and determine what behavior associated the exporter address with `source.ip`. +- Verify the exporter's owner, device type, software version, management plane, recent configuration changes, and + approved collector destinations. +- Review authentication, process, network-device audit, and configuration telemetry for the exporter around the + correlation window. +- Compare observation domains, exporter version, uptime, sequence values, templates, sampling configuration, and flow + volume with established exporters. +- Search for additional alerts involving the exporter address and for malformed, implausible, or conflicting flow + records received from it. + + +*False positive analysis* + + +- Validate recent device onboarding, migrations, disaster-recovery activation, penetration tests, vulnerability scans, + and monitoring validation. +- Determine whether `source.ip` represents the exporter itself or a shared NAT, proxy, scanner, or management address. +- Confirm that the correlated source alert is a meaningful behavioral detection rather than an expected administrative + or discovery event. + + +*Response and remediation* + + +- If the exporter is unauthorized or compromised, restrict it at the collector boundary and isolate its management + plane as appropriate. +- Preserve flow records, source alerts, configuration history, authentication events, and network evidence. +- Remove unauthorized export configuration, restore trusted device configuration, rotate affected credentials, and + review collector ACLs and authentication. + + +==== Setup + + + +*Setup* + + +Enable the building-block rule "First Seen Network Flow Exporter" and detection rules that can identify suspicious +activity with `source.ip` populated. The building-block rule requires decoded NetFlow, IPFIX, or sFlow records from the +Elastic NetFlow (`netflow.log`) or GoFlow2 (`goflow2.sflow`) integration. + +The higher-order rule searches Elastic Security alert indices. The correlated source alert must preserve the exporter +address in `source.ip` and preserve `data_stream.namespace`; alerts without either field cannot contribute to this +correlation. Building-block, higher-order, machine-learning, new-terms, threat-match, and deprecated-rule alerts are +excluded as the second event. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM .alerts-security.* +| WHERE event.kind == "signal" + AND data_stream.namespace IS NOT NULL + AND ( + (kibana.alert.rule.rule_id == "dfe3f626-4224-417e-aff1-8ef9a72c3191" AND observer.ip IS NOT NULL) + OR + (source.ip IS NOT NULL + AND kibana.alert.rule.name IS NOT NULL + AND kibana.alert.rule.rule_id IS NOT NULL + AND kibana.alert.rule.rule_id != "dfe3f626-4224-417e-aff1-8ef9a72c3191" + AND (kibana.alert.risk_score >= 47 OR kibana.alert.severity IN ("medium", "high", "critical")) + AND KQL("""NOT kibana.alert.building_block_type : *""") + AND NOT kibana.alert.rule.type IN ("machine_learning", "new_terms", "threat_match") + AND NOT kibana.alert.rule.name LIKE "Deprecated - *" + AND NOT KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)) + ) +| EVAL + Esql.is_exporter_alert = kibana.alert.rule.rule_id == "dfe3f626-4224-417e-aff1-8ef9a72c3191", + Esql.is_suspicious_source_alert = kibana.alert.rule.rule_id != "dfe3f626-4224-417e-aff1-8ef9a72c3191", + Esql.correlation_ip = CASE(Esql.is_exporter_alert, observer.ip, source.ip), + Esql.exporter_alert_timestamp = CASE(Esql.is_exporter_alert, @timestamp, null), + Esql.suspicious_source_alert_timestamp = CASE(Esql.is_suspicious_source_alert, @timestamp, null), + Esql.suspicious_rule_name = CASE(Esql.is_suspicious_source_alert, kibana.alert.rule.name, null), + Esql.suspicious_rule_id = CASE(Esql.is_suspicious_source_alert, kibana.alert.rule.rule_id, null) +| WHERE Esql.correlation_ip IS NOT NULL +| STATS + Esql.exporter_alert_count = SUM(CASE(Esql.is_exporter_alert, 1, 0)), + Esql.suspicious_source_alert_count = SUM(CASE(Esql.is_suspicious_source_alert, 1, 0)), + observer.ip = MAX(CASE(Esql.is_exporter_alert, Esql.correlation_ip, null)), + source.ip = MAX(CASE(Esql.is_suspicious_source_alert, Esql.correlation_ip, null)), + Esql.exporter_alert_timestamp = MIN(Esql.exporter_alert_timestamp), + Esql.suspicious_source_alert_timestamp = MAX(Esql.suspicious_source_alert_timestamp), + Esql.suspicious_rule_name_values = VALUES(Esql.suspicious_rule_name), + Esql.suspicious_rule_id_values = VALUES(Esql.suspicious_rule_id) + BY data_stream.namespace, Esql.correlation_ip +| EVAL Esql.time_diff_seconds = DATE_DIFF( + "second", Esql.exporter_alert_timestamp, Esql.suspicious_source_alert_timestamp + ) +| WHERE Esql.exporter_alert_count > 0 + AND Esql.suspicious_source_alert_count > 0 + AND Esql.time_diff_seconds >= 0 + AND Esql.time_diff_seconds <= 1800 +| KEEP + data_stream.namespace, + observer.ip, + source.ip, + Esql.correlation_ip, + Esql.exporter_alert_count, + Esql.suspicious_source_alert_count, + Esql.exporter_alert_timestamp, + Esql.suspicious_source_alert_timestamp, + Esql.suspicious_rule_name_values, + Esql.suspicious_rule_id_values, + Esql.time_diff_seconds + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc new file mode 100644 index 0000000000..46c67ff3fc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc @@ -0,0 +1,210 @@ +[[prebuilt-rule-8-19-33-gke-sensitive-rbac-change-followed-by-workload-modification]] +=== GKE Sensitive RBAC Change Followed by Workload Modification + +Detects when the same GKE identity creates or modifies a Role or ClusterRole with high-risk permissions (wildcard access, RBAC escalation verbs, or access to secrets / privileged APIs) and also creates or patches a DaemonSet, Deployment, or CronJob within five minutes. This correlation is consistent with RBAC-based privilege escalation followed by payload deployment. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-11m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control +* https://kubernetes.io/docs/reference/access-authn-authz/rbac/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Domain: Containers +* Data Source: GCP +* Data Source: Google Cloud Platform +* Data Source: GCP Audit Logs +* Platform: GCP +* Platform: Kubernetes +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Rule Type: ESQL + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Sensitive RBAC Change Followed by Workload Modification* + + +This ES|QL rule correlates two successful GKE audit behaviors from the same `client.user.email` within five +minutes: + +1. Role or ClusterRole create/update/patch that grants high-risk permissions (wildcards, `escalate` / + `bind` / `impersonate`, secret read, or privileged API resources such as `pods/exec` and + `serviceaccounts/token`) +2. DaemonSet, Deployment, or CronJob create or patch after the sensitive RBAC change + +`Esql.rbac_to_workload_minutes` is the gap from the latest sensitive RBAC event to the earliest workload +modification in the lookback window. + + +*Possible investigation steps* + + +- Review `Esql.event_action_values` and `Esql.gcp_audit_resource_name_values` for the Role/ClusterRole and + workload objects touched. +- Inspect `Esql.user_agent_original_values` and `Esql.source_ip_values` for unexpected clients or networks. +- Check for RoleBinding or ClusterRoleBinding activity around the same identity and time window. +- Correlate with secret access, pod exec, or token creation from the same actor. + + +*False positive analysis* + + +- GitOps pipelines that manage both RBAC manifests and workloads in one sync cycle. +- Platform bootstrap that patches built-in roles and reconciles addon workloads. + + +*Response and remediation* + + +- Roll back unauthorized Role/ClusterRole and workload changes, revoke the actor's credentials, and + tighten who can mutate RBAC and sensitive workloads. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required. Request body capture on RBAC +resources is required so Role and ClusterRole rule verbs and resources are present in +`gcp.audit.request`. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-gcp.audit-* metadata _id, _index, _version +| where data_stream.dataset == "gcp.audit" + and service.name == "k8s.io" + and event.outcome == "success" + and client.user.email is not null + and source.ip is not null + and not to_string(source.ip) in ("127.0.0.1", "::1") + and not client.user.email in ( + "system:addon-manager", + "system:apiserver", + "system:kube-controller-manager", + "system:serviceaccount:flux-system:kustomize-controller", + "system:serviceaccount:flux-system:helm-controller", + "system:serviceaccount:flux-system:source-controller", + "system:serviceaccount:flux-system:flux-operator", + "system:serviceaccount:flux-operator:flux-operator" + ) + and ( + ( + event.action in ( + "io.k8s.authorization.rbac.v1.roles.create", + "io.k8s.authorization.rbac.v1.roles.update", + "io.k8s.authorization.rbac.v1.roles.patch", + "io.k8s.authorization.rbac.v1.clusterroles.create", + "io.k8s.authorization.rbac.v1.clusterroles.update", + "io.k8s.authorization.rbac.v1.clusterroles.patch" + ) + and not ( + client.user.email == "system:serviceaccount:kube-system:clusterrole-aggregation-controller" + and event.action == "io.k8s.authorization.rbac.v1.clusterroles.patch" + ) + and ( + KQL("""gcp.audit.request.rules.verbs:("*" or "escalate" or "bind" or "impersonate")""") + or KQL("""gcp.audit.request.rules.verbs:("*" or "create" or "patch" or "update") and gcp.audit.request.rules.resources:("*" or "clusterroles" or "clusterrolebindings" or "roles" or "rolebindings" or "pods/exec" or "serviceaccounts/token" or "nodes/proxy" or "daemonsets")""") + or KQL("""gcp.audit.request.rules.verbs:("*" or "get" or "list") and gcp.audit.request.rules.resources:("*" or "secrets")""") + ) + ) + or event.action in ( + "io.k8s.apps.v1.daemonsets.create", + "io.k8s.apps.v1.daemonsets.patch", + "io.k8s.apps.v1.deployments.create", + "io.k8s.apps.v1.deployments.patch", + "io.k8s.batch.v1.cronjobs.create", + "io.k8s.batch.v1.cronjobs.patch" + ) + ) +| eval Esql.is_sensitive_rbac = case(event.action like "io.k8s.authorization.rbac.*", 1, 0), + Esql.is_workload_modification = case(event.action like "io.k8s.apps.*" or event.action like "io.k8s.batch.*", 1, 0), + Esql.sensitive_rbac_timestamp = case(event.action like "io.k8s.authorization.rbac.*", @timestamp, null), + Esql.workload_modification_timestamp = case(event.action like "io.k8s.apps.*" or event.action like "io.k8s.batch.*", @timestamp, null) +| stats + Esql.sensitive_rbac_count = sum(Esql.is_sensitive_rbac), + Esql.workload_modification_count = sum(Esql.is_workload_modification), + Esql.latest_sensitive_rbac_timestamp = max(Esql.sensitive_rbac_timestamp), + Esql.earliest_workload_modification_timestamp = min(Esql.workload_modification_timestamp), + Esql.event_action_values = values(event.action), + Esql.gcp_audit_resource_name_values = values(gcp.audit.resource_name), + Esql.user_agent_original_values = values(user_agent.original), + Esql.source_ip_values = values(source.ip) + by client.user.email +| where Esql.sensitive_rbac_count > 0 + and Esql.workload_modification_count > 0 + and Esql.latest_sensitive_rbac_timestamp <= Esql.earliest_workload_modification_timestamp +| eval Esql.rbac_to_workload_minutes = date_diff( + "minute", + Esql.latest_sensitive_rbac_timestamp, + Esql.earliest_workload_modification_timestamp + ) +| where Esql.rbac_to_workload_minutes <= 5 +| keep + client.user.email, + Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* 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 Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* 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 Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc new file mode 100644 index 0000000000..130e85f107 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-33-kubernetes-sensitive-rbac-change-followed-by-workload-modification]] +=== Kubernetes Sensitive RBAC Change Followed by Workload Modification + +Detects a sequence where a principal creates or modifies a Role/ClusterRole to include high-risk permissions (e.g., wildcard access or escalation verbs) and then creates or patches a workload resource (DaemonSet, Deployment, or CronJob) shortly after, which may indicate RBAC-based privilege escalation followed by payload deployment. This pattern is often used by adversaries to gain unauthorized access to sensitive resources and deploy malicious payloads. + +*Rule type*: eql + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*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://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control + +*Tags*: + +* Data Source: Kubernetes +* Data Source: Kubernetes API Server Audit Logs +* Domain: Containers +* Domain: Kubernetes +* Platform: Kubernetes +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) + +*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 Kubernetes Sensitive RBAC Change Followed by Workload Modification* + + +This rule detects when a user grants or broadens high-risk permissions in a Role/ClusterRole and then quickly creates or patches a DaemonSet, Deployment, or CronJob, a strong signal of RBAC-driven privilege escalation followed by payload deployment. Attackers often add wildcard access or escalation verbs to a new role, bind it to their identity, then patch a workload to run a malicious container across nodes or on a schedule to establish persistence. + + +*Possible investigation steps* + + +- Review the Role/ClusterRole change diff to identify newly granted wildcard resources/verbs or escalation permissions (e.g., bind, impersonate, escalate) and determine the effective access increase for the actor. +- Identify any RoleBinding/ClusterRoleBinding creations or updates around the same time to see whether the modified role was bound to the same principal or a newly created service account. +- Inspect the subsequent DaemonSet/Deployment/CronJob spec changes for malicious indicators such as new images, added initContainers, elevated securityContext (privileged/hostPID/hostNetwork), hostPath mounts, or suspicious command/args. +- Correlate pod runtime activity from the modified workload (image pulls, container starts, outbound connections, and access to secrets/configmaps) to confirm execution and scope of impact. +- Validate the actor’s legitimacy by checking whether the request originated from expected IP/user-agent and whether the identity is associated with approved CI/CD automation or an unusual interactive session. + + +*False positive analysis* + + +- A platform engineer performing an urgent, legitimate RBAC adjustment (e.g., expanding a Role/ClusterRole for a new feature rollout) and then immediately patching or deploying a DaemonSet/Deployment/CronJob as part of the same change window can match this sequence. +- A CI/CD pipeline or GitOps-style workflow using a non-system:masters identity may update RBAC manifests and then apply workload updates within minutes during routine releases, producing this pattern without malicious intent. + + +*Response and remediation* + + +- Immediately revoke or roll back the risky Role/ClusterRole changes and remove any new/updated RoleBinding/ClusterRoleBinding that ties the elevated permissions to the triggering user or service account. +- Quarantine the modified Deployment/DaemonSet/CronJob by scaling it to zero or deleting it and cordon/drain affected nodes if pods ran privileged, used hostPath mounts, or executed on many nodes. +- Rotate credentials and access paths exposed through the workload (service account tokens, kubeconfig files, mounted secrets, cloud keys) and invalidate any newly issued tokens tied to the actor. +- For eradication and recovery, redeploy workloads from trusted Git/registry sources, block the suspicious images/digests in admission controls, and verify no persistence remains via CronJobs, DaemonSets, webhook configurations, or additional RBAC bindings. +- Escalate to incident response and platform leadership if the RBAC change included wildcard permissions or escalation verbs, if the workload ran privileged/hostNetwork/hostPID, or if sensitive secrets were accessed or exfiltration is suspected. +- Harden by enforcing least-privilege RBAC, requiring peer approval for RBAC changes, restricting workload mutations via GitOps-only service accounts, and using admission policies to deny privileged pods, hostPath mounts, and unapproved registries. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by user.name with maxspan=5m + [any where data_stream.dataset == "kubernetes.audit_logs" and + `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and + kubernetes.audit.objectRef.resource in ("roles", "clusterroles") and + kubernetes.audit.verb in ("create", "update", "patch") and + /* GitOps controllers reconcile RBAC then workloads in the same window */ + not user.name in ( + "system:serviceaccount:flux-system:kustomize-controller", + "system:serviceaccount:flux-system:helm-controller", + "system:serviceaccount:flux-system:source-controller" + )] + [any where data_stream.dataset == "kubernetes.audit_logs" and + `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and + kubernetes.audit.objectRef.resource in ("daemonsets", "deployments", "cronjobs") and + kubernetes.audit.verb in ("create", "patch") and + /* reduce control-plane / bootstrap noise */ + not kubernetes.audit.user.groups == "system:masters" + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* 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 Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* 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 Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-launch-service-creation-and-immediate-loading.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-launch-service-creation-and-immediate-loading.asciidoc new file mode 100644 index 0000000000..c8024df309 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-launch-service-creation-and-immediate-loading.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-33-launch-service-creation-and-immediate-loading]] +=== Launch Service Creation and Immediate Loading + +An adversary can establish persistence by installing a new launch agent that executes at login by using launchd or launchctl to load a plist into the appropriate directories. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-endpoint.events.process* + +*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://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 113 + +*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 Launch Service Creation and Immediate Loading* + + +Launch Agents in macOS are used to execute scripts or applications automatically at user login, providing a mechanism for persistence. Adversaries exploit this by creating or modifying Launch Agents to execute malicious payloads. The detection rule identifies such activities by monitoring file changes in Launch Agent directories and subsequent immediate loading via `launchctl`, indicating potential unauthorized persistence attempts. + + +*Possible investigation steps* + + +- Review the file path where the modification or creation of the Launch Agent occurred to determine if it is in a system directory (e.g., /System/Library/LaunchAgents/) or a user directory (e.g., /Users/*/Library/LaunchAgents/). This can help assess the potential impact and scope of the change. +- Examine the contents of the newly created or modified plist file to identify the script or application it is configured to execute. Look for any suspicious or unexpected entries that could indicate malicious activity. +- Check the timestamp of the file modification event to correlate it with any known user activities or other system events that might explain the change. +- Investigate the process execution details of the launchctl command, including the user account under which it was executed and any associated parent processes, to determine if it aligns with legitimate administrative actions or if it appears suspicious. +- Search for any additional related alerts or logs around the same timeframe that might indicate further malicious behavior or corroborate the persistence attempt, such as other process executions or network connections initiated by the suspicious process. + + +*False positive analysis* + + +- System or application updates may create or modify Launch Agents as part of their installation or update process. Users can create exceptions for known and trusted applications by whitelisting their specific file paths or process names. +- User-installed applications that require background processes might use Launch Agents for legitimate purposes. Identify these applications and exclude their associated Launch Agent paths from monitoring. +- Administrative scripts or tools used by IT departments for system management might trigger this rule. Coordinate with IT to document these scripts and exclude their activities from detection. +- Development tools or environments that automatically configure Launch Agents for testing purposes can cause false positives. Developers should be aware of these activities and can exclude their specific development directories. +- Backup or synchronization software that uses Launch Agents to schedule tasks may be flagged. Verify these applications and exclude their Launch Agent paths if they are deemed safe. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes associated with the unauthorized Launch Agent using Activity Monitor or the `kill` command in Terminal. +- Remove the malicious Launch Agent plist file from the affected directories: `/System/Library/LaunchAgents/`, `/Library/LaunchAgents/`, or `/Users/*/Library/LaunchAgents/`. +- Review and restore any system or application settings that may have been altered by the malicious Launch Agent. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Monitor the system for any signs of re-infection or further unauthorized changes to Launch Agents, ensuring that logging and alerting are configured to detect similar activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule 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] +---------------------------------- +sequence by host.id with maxspan=30s + [file where host.os.type == "macos" and event.action == "launch_daemon"] by process.entity_id + [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "launchctl" and process.args in ("load", "bootstrap")] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Launch Agent +** ID: T1543.001 +** Reference URL: https://attack.mitre.org/techniques/T1543/001/ +* Sub-technique: +** Name: Launch Daemon +** ID: T1543.004 +** Reference URL: https://attack.mitre.org/techniques/T1543/004/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Launchctl +** ID: T1569.001 +** Reference URL: https://attack.mitre.org/techniques/T1569/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-linux-firewall-rule-creation-or-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-linux-firewall-rule-creation-or-modification.asciidoc new file mode 100644 index 0000000000..77030e528f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-linux-firewall-rule-creation-or-modification.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-33-linux-firewall-rule-creation-or-modification]] +=== Linux Firewall Rule Creation or Modification + +Adversaries may create or modify Linux firewall rules with DROP, ACCEPT, or REJECT actions to affect how a host receives or sends network traffic. This activity may be used to bypass security controls, block defensive tooling, or gain unauthorized access to the network. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* +* auditbeat-* + +*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 +* Platform: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) + +*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 Linux Firewall Rule Creation or Modification* + + +This rule detects Linux firewall commands that create or modify DROP, ACCEPT, REJECT, deny, allow, or reject rules, which can weaken network controls, conceal malicious traffic, or open unauthorized access paths. An attacker with elevated privileges may add an ACCEPT rule permitting inbound SSH from a controlled address, then add DROP or REJECT rules that block connections to monitoring or management systems. + + +*Possible investigation steps* + + +- Review the full command line, execution user, privilege level, parent process, working directory, and related shell history to determine who initiated the change and whether it followed an approved administrative workflow. +- Reconstruct the resulting firewall policy and identify affected interfaces, protocols, ports, addresses, directions, and rule ordering to assess whether access was opened or security and management traffic was blocked. +- Compare the change with configuration-management activity, maintenance windows, change tickets, administrator baselines, and similar commands on peer hosts to distinguish expected operations from anomalous behavior. +- Correlate nearby authentication, process, file, and network events for suspicious logins, privilege escalation, remote-access tooling, firewall persistence changes, or connections newly enabled by the rule. +- If unauthorized, preserve the active ruleset and relevant telemetry, restore the approved policy through controlled procedures, isolate the host when necessary, and investigate the initiating account and adjacent systems for compromise. + + +*False positive analysis* + + +- An administrator may add or modify DROP, ACCEPT, REJECT, deny, allow, or reject rules during approved firewall maintenance; verify the command scope, initiating user, execution time, and corresponding change record. +- A startup script or configuration-management process may restore the approved firewall baseline after boot or deployment; confirm the parent process, command recurrence, and resulting ruleset match established host and peer baselines. + + +*Response and remediation* + + +- Isolate affected hosts from untrusted networks while preserving approved incident-response access, and block attacker-controlled addresses and newly exposed services at upstream firewalls. +- Preserve the active ruleset and relevant logs, then remove unauthorized DROP, ACCEPT, REJECT, deny, allow, or reject rules and restore the approved policy through configuration management. +- Remove firewall persistence from systemd units, cron jobs, startup scripts, network hooks, nftables configuration, iptables-persistent files, and UFW configuration. +- Revoke compromised credentials and active sessions, inspect for additional malware or privilege escalation, and reimage from a known-good source if root-level integrity cannot be established. +- Escalate immediately to incident response if the rules were created with root privileges, enabled unauthorized remote access, impaired monitoring, or appear on multiple systems. +- Harden the environment by restricting firewall administration through least privilege, enforcing reviewed ruleset baselines, securing configuration files, and alerting on future policy changes. + + +==== 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]. + + +*Additional data sources* + + +This rule also supports ECS-compatible process events from Elastic Endgame and the following integrations: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://www.elastic.co/docs/reference/integrations/auditd_manager[Auditd Manager] +- https://www.elastic.co/guide/en/beats/auditbeat/current/auditbeat-installation-configuration.html[Auditbeat] + + +==== 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 in ( + "iptables", "ip6tables", "iptables-nft", "ip6tables-nft", "iptables-legacy", + "ip6tables-legacy", "xtables-nft-multi", "xtables-legacy-multi" + ) and + process.args in ("-A", "--append", "-I", "--insert", "-R", "--replace", "-P", "--policy") and + process.args like~ ("DROP", "ACCEPT", "REJECT") + ) or + ( + process.name == "nft" and + process.args in ("add", "insert", "replace") and + process.args == "rule" and + process.args like~ ("DROP", "ACCEPT", "REJECT") and + not process.args in ("-c", "--check") + ) or + ( + process.name == "ufw" and + process.args like~ ("deny", "allow", "reject") and + not process.args in ("delete", "--dry-run") + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify System Firewall +** ID: T1562.004 +** Reference URL: https://attack.mitre.org/techniques/T1562/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-m365-identity-user-account-lockouts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-m365-identity-user-account-lockouts.asciidoc new file mode 100644 index 0000000000..fc0cafb494 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-m365-identity-user-account-lockouts.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-33-m365-identity-user-account-lockouts]] +=== M365 Identity User Account Lockouts + +Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*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/security/operations/incident-response-playbook-password-spray +* https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties +* https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/ +* https://github.com/0xZDH/Omnispray +* https://github.com/0xZDH/o365spray + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 Identity User Account Lockouts* + + +Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. + +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. + + +*Investigation Steps* + + +- Review the `user_id_list`: Are specific naming patterns targeted (e.g., admin, helpdesk)? +- Examine `ip_list` and `source_orgs`: Look for suspicious ISPs or hosting providers. +- Check `duration_seconds`: A very short window with a high lockout rate often indicates automation. +- Confirm lockout policy thresholds with IAM or Entra ID admins. Did the policy trigger correctly? +- Use the `first_seen` and `last_seen` values to pivot into related authentication or audit logs. +- Correlate with any recent detection of password spraying or credential stuffing activity. +- Review the `request_type` field to identify which authentication methods were used (e.g., OAuth, SAML, etc.). +- Check for any successful logins from the same IP or ASN after the lockouts. + + +*False Positive Analysis* + + +- Automated systems with stale credentials may cause repeated failed logins. +- Legitimate bulk provisioning or scripted tests could unintentionally cause account lockouts. +- Red team exercises or penetration tests may resemble the same lockout pattern. +- Some organizations may have a high volume of lockouts due to user behavior or legacy systems. + + +*Response Recommendations* + + +- Notify affected users and confirm whether activity was expected or suspicious. +- Lock or reset credentials for impacted accounts. +- Block the source IP(s) or ASN temporarily using conditional access or firewall rules. +- Strengthen lockout and retry delay policies if necessary. +- Review the originating application(s) involved via `request_types`. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-* +| mv_expand event.category +| eval + Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp) +| where + data_stream.dataset == "o365.audit" and + event.category == "authentication" and + event.provider in ("AzureActiveDirectory", "Exchange") and + event.action in ("UserLoginFailed", "PasswordLogonInitialAuthUsingPassword") and + to_lower(o365.audit.ExtendedProperties.RequestType) rlike "(oauth.*|.*login.*)" and + o365.audit.LogonError == "IdsLocked" and + to_lower(o365.audit.UserId) != "not available" and + o365.audit.Target.Type in ("0", "2", "6", "10") and + source.`as`.organization.name != "MICROSOFT-CORP-MSN-as-BLOCK" +| stats + Esql_priv.o365_audit_UserId_count_distinct = count_distinct(to_lower(o365.audit.UserId)), + Esql_priv.o365_audit_UserId_values = values(to_lower(o365.audit.UserId)), + Esql.source_ip_values = values(source.ip), + Esql.source_ip_count_distinct = count_distinct(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.source_geo_country_name_values = values(source.geo.country_name), + Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name), + Esql.o365_audit_ExtendedProperties_RequestType_values = values(to_lower(o365.audit.ExtendedProperties.RequestType)), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp), + Esql.event_count = count(*) + by Esql.time_window_date_trunc +| eval + Esql.event_duration_seconds = date_diff("seconds", Esql.timestamp_first_seen, Esql.timestamp_last_seen) +| keep + Esql.time_window_date_trunc, + Esql_priv.o365_audit_UserId_count_distinct, + Esql_priv.o365_audit_UserId_values, + Esql.source_ip_values, + Esql.source_ip_count_distinct, + Esql.source_as_organization_name_values, + Esql.source_as_organization_name_count_distinct, + Esql.source_geo_country_name_values, + Esql.source_geo_country_name_count_distinct, + Esql.o365_audit_ExtendedProperties_RequestType_values, + Esql.timestamp_first_seen, + Esql.timestamp_last_seen, + Esql.event_count, + Esql.event_duration_seconds +| where + Esql_priv.o365_audit_UserId_count_distinct >= 10 and + Esql.event_count >= 10 and + Esql.event_duration_seconds <= 300 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ +* 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-33/prebuilt-rule-8-19-33-m365-identity-user-brute-force-attempted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-m365-identity-user-brute-force-attempted.asciidoc new file mode 100644 index 0000000000..c3fc8dc464 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-m365-identity-user-brute-force-attempted.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-33-m365-identity-user-brute-force-attempted]] +=== M365 Identity User Brute Force Attempted + +Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray +* https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties +* https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/ +* https://github.com/0xZDH/Omnispray +* https://github.com/0xZDH/o365spray + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 419 + +*Rule authors*: + +* Elastic +* Willem D'Haese +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 Identity User Brute Force Attempted* + + +Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords. + + +*Possible investigation steps* + + +- Review `user_id_list`: Enumerates the user accounts targeted. Look for naming patterns or privilege levels (e.g., admins). +- Check `login_errors`: A consistent error such as `"InvalidUserNameOrPassword"` confirms a spray-style attack using one or a few passwords. +- Examine `ip_list` and `source_orgs`: Determine if the traffic originates from a known corporate VPN, datacenter, or suspicious ASN like hosting providers or anonymizers. +- Review `countries` and `unique_country_count`: Geographic anomalies (e.g., login attempts from unexpected regions) may indicate malicious automation. +- Validate `total_attempts` vs `duration_seconds`: A high frequency of login attempts over a short period may suggest automation rather than manual logins. +- Cross-reference with successful logins: Pivot to surrounding sign-in logs (`azure.signinlogs`) or risk detections (`identityprotection`) for any account that eventually succeeded. +- Check for multi-factor challenges or bypasses: Determine if any of the accounts were protected or if the attack bypassed MFA. + + +*False positive analysis* + + +- IT administrators using automation tools (e.g., PowerShell) during account provisioning may trigger false positives if login attempts cluster. +- Penetration testing or red team simulations may resemble spray activity. +- Infrequent, low-volume login testing tools like ADFS testing scripts can exhibit similar patterns. + + +*Response and remediation* + + +- Initiate an internal incident ticket and inform the affected identity/IT team. +- Temporarily disable impacted user accounts if compromise is suspected. +- Investigate whether any login attempts succeeded after the spray window. +- Block the offending IPs or ASN temporarily via firewall or conditional access policies. +- Rotate passwords for all targeted accounts and audit for password reuse. +- Enforce or verify MFA is enabled for all user accounts. +- Consider deploying account lockout or progressive delay mechanisms if not already enabled. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-* +| mv_expand event.category +| eval + Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp), + Esql_priv.o365_audit_UserId_lower = to_lower(o365.audit.UserId), + Esql.o365_audit_LogonError = o365.audit.LogonError, + Esql.o365_audit_ExtendedProperties_RequestType_lower = to_lower(o365.audit.ExtendedProperties.RequestType) +| where + data_stream.dataset == "o365.audit" and + event.category == "authentication" and + event.provider in ("AzureActiveDirectory", "Exchange") and + event.action in ("UserLoginFailed", "PasswordLogonInitialAuthUsingPassword") and + Esql.o365_audit_ExtendedProperties_RequestType_lower rlike "(oauth.*|.*login.*)" and + Esql.o365_audit_LogonError != "IdsLocked" and + Esql.o365_audit_LogonError not in ( + "EntitlementGrantsNotFound", + "UserStrongAuthEnrollmentRequired", + "UserStrongAuthClientAuthNRequired", + "InvalidReplyTo", + "SsoArtifactExpiredDueToConditionalAccess", + "PasswordResetRegistrationRequiredInterrupt", + "SsoUserAccountNotFoundInResourceTenant", + "UserStrongAuthExpired", + "CmsiInterrupt" + ) and + Esql_priv.o365_audit_UserId_lower != "not available" and + o365.audit.Target.Type in ("0", "2", "6", "10") +| stats + Esql.o365_audit_UserId_lower_count_distinct = count_distinct(Esql_priv.o365_audit_UserId_lower), + Esql_priv.o365_audit_UserId_lower_values = values(Esql_priv.o365_audit_UserId_lower), + Esql.o365_audit_LogonError_values = values(Esql.o365_audit_LogonError), + Esql.o365_audit_LogonError_count_distinct = count_distinct(Esql.o365_audit_LogonError), + Esql.o365_audit_ExtendedProperties_RequestType_values = values(Esql.o365_audit_ExtendedProperties_RequestType_lower), + Esql.source_ip_values = values(source.ip), + Esql.source_ip_count_distinct = count_distinct(source.ip), + Esql.source_as_organization_name_values = values(source.`as`.organization.name), + Esql.source_geo_country_name_values = values(source.geo.country_name), + Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name), + Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp), + Esql.event_count = count(*) + by Esql.time_window_date_trunc +| eval + Esql.event_duration_seconds = date_diff("seconds", Esql.timestamp_first_seen, Esql.timestamp_last_seen), + Esql.brute_force_type = case( + Esql.o365_audit_UserId_lower_count_distinct >= 15 and Esql.o365_audit_LogonError_count_distinct == 1 and Esql.event_count >= 10 and Esql.event_duration_seconds <= 1800, "password_spraying", + Esql.o365_audit_UserId_lower_count_distinct >= 8 and Esql.event_count >= 15 and Esql.o365_audit_LogonError_count_distinct <= 3 and Esql.source_ip_count_distinct <= 5 and Esql.event_duration_seconds <= 600, "credential_stuffing", + Esql.o365_audit_UserId_lower_count_distinct == 1 and Esql.o365_audit_LogonError_count_distinct == 1 and Esql.event_count >= 20 and Esql.event_duration_seconds <= 300, "password_guessing", + "other" + ) +| keep + Esql.time_window_date_trunc, + Esql.o365_audit_UserId_lower_count_distinct, + Esql_priv.o365_audit_UserId_lower_values, + Esql.o365_audit_LogonError_values, + Esql.o365_audit_LogonError_count_distinct, + Esql.o365_audit_ExtendedProperties_RequestType_values, + Esql.source_ip_values, + Esql.source_ip_count_distinct, + Esql.source_as_organization_name_values, + Esql.source_geo_country_name_values, + Esql.source_geo_country_name_count_distinct, + Esql.source_as_organization_name_count_distinct, + Esql.timestamp_first_seen, + Esql.timestamp_last_seen, + Esql.event_duration_seconds, + Esql.event_count, + Esql.brute_force_type +| where Esql.brute_force_type != "other" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-m365-onedrive-sharepoint-excessive-file-downloads.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-m365-onedrive-sharepoint-excessive-file-downloads.asciidoc new file mode 100644 index 0000000000..0bb8e5bc86 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-m365-onedrive-sharepoint-excessive-file-downloads.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-33-m365-onedrive-sharepoint-excessive-file-downloads]] +=== M365 OneDrive/SharePoint Excessive File Downloads + +Identifies when an excessive number of files are downloaded from OneDrive or SharePoint by an authorized user or application in a short period of time. This may indicate a potential data exfiltration event, especially if the downloads are performed using OAuth authentication which could suggest an OAuth phishing attack such as Device Code Authentication phishing. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*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/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/ +* https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Storage +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Data Source: SharePoint +* Data Source: OneDrive +* Use Case: Threat Detection +* Tactic: Collection +* Tactic: Exfiltration +* Resources: Investigation Guide + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 OneDrive/SharePoint Excessive File Downloads* + + +This rule detects an excessive number of files downloaded from OneDrive using OAuth authentication. Threat actors may use OAuth phishing attacks, such as **Device Code Authentication phishing**, to obtain valid access tokens and perform unauthorized data exfiltration. This method allows adversaries to bypass traditional authentication mechanisms, making it a stealthy and effective technique. + +This rule leverages ESQL aggregations which limit the field values available in the alert document. To investigate further, it is recommended to identify the original documents ingested. + + +*Possible Investigation Steps* + + +- Review the user ID field to identify the user who performed the downloads. Check if this user typically downloads large amounts of data from OneDrive. +- Correlate user ID with Entra Sign-In logs to verify the authentication method used and determine if it was expected for this user. +- Review the authentication method used. If OAuth authentication was used, investigate whether it was expected for this user. +- Identify the client application used for authentication. Determine if it is a legitimate enterprise-approved app or an unauthorized third-party application. +- Check the number of unique files downloaded. If a user downloads a high volume of unique files in a short period, it may indicate data exfiltration. +- Analyze the file types and directories accessed to determine if sensitive or confidential data was involved. +- Investigate the source IP address and geolocation of the download activity. If it originates from an unusual or anonymized location, further scrutiny is needed. +- Review other recent activities from the same user, such as file access, sharing, or permission changes, that may indicate further compromise. +- Check for signs of session persistence using OAuth. If Azure sign-in logs are correlated where `authentication_protocol` or `originalTransferMethod` field shows `deviceCode`, the session was established through device code authentication. +- Look for multiple authentication attempts from different devices or locations within a short timeframe, which could indicate unauthorized access. +- Investigate if other OAuth-related anomalies exist, such as consent grants for unfamiliar applications or unexpected refresh token activity. +- Review the `file.directory` value from the original documents to identify the specific folders or paths where the files were downloaded. +- Examine if the downloaded files are from Sharepoint or OneDrive by checking the `event.code` field. +- Review the incoming token type to determine how authentication occurred. If the `token.id` field is populated, it indicates that OAuth authentication was used, which may suggest an OAuth phishing attack. + + +*False Positive Analysis* + + +- Verify if the user regularly downloads large batches of files as part of their job function. +- Determine if the downloads were triggered by an authorized automated process, such as a data backup or synchronization tool. +- Confirm if the detected OAuth application is approved for enterprise use and aligns with expected usage patterns. + + +*Response and Remediation* + + +- If unauthorized activity is confirmed, revoke the OAuth token used and terminate active OneDrive sessions. +- Reset the affected user's password and require reauthentication to prevent continued unauthorized access. +- Restrict OAuth app permissions and enforce conditional access policies to limit authentication to trusted devices and applications. +- Monitor for additional signs of compromise, such as unusual email forwarding rules, external sharing of OneDrive files, or privilege escalation attempts. +- Educate users on OAuth phishing risks and encourage the use of **Microsoft Defender for Office 365 Safe Links** to mitigate credential-based attacks. +- Enable continuous monitoring for OAuth authentication anomalies using **Microsoft Entra ID sign-in logs** and security tools. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-* metadata _id, _version, _index +| where + data_stream.dataset == "o365.audit" and + event.provider == "OneDrive" and + event.action == "FileDownloaded" and + event.outcome == "success" + and (user.id is not null and o365.audit.ApplicationId is not null) + and o365.audit.ApplicationId not in ( + "08e18876-6177-487e-b8b5-cf950c1e598c", // SharePoint Online Web Client Extensibility + "fb8d773d-7ef8-4ec0-a117-179f88add510", // Enterprise Copilot Platform + "d3590ed6-52b3-4102-aeff-aad2292ab01c", // Microsoft Office + "7ab7862c-4c57-491e-8a45-d52a7e023983" // App Service + ) +| eval session.id = coalesce(o365.audit.AppAccessContext.AADSessionId, session.id, null) +| where session.id is not null +| eval Esql.time_window_date_trunc = date_trunc(3 minutes, @timestamp) +// file.size is dynamically mapped in o365.audit and can be keyword or long across backing indices +| eval Esql.file_size_bytes = to_long(file.size) +| stats + Esql.file_directory_values = values(file.directory), + Esql.file_extension_values = values(file.extension), + Esql.application_name_values = values(application.name), + Esql.file_name_count_distinct = count_distinct(file.name), + Esql.total_file_size_mb = round((mv_sum(values(Esql.file_size_bytes))) / 1048576.0, 2), + Esql.o365_audit_Site_values = values(o365.audit.Site), + Esql.o365_audit_SiteUrl_values = values(o365.audit.SiteUrl), + Esql.user_domain_values = values(user.domain), + Esql.token_id_values = values(token.id), + Esql.event_code_values = values(event.code), + Esql.event_provider_values = values(event.provider), + Esql.auth_type_values = values(o365.audit.AuthenticationType), + Esql.is_managed_device_values = values(o365.audit.IsManagedDevice), + Esql.platform_values = values(o365.audit.Platform), + Esql.user_agent_values = values(user_agent.name), + Esql.source_asn_org_values = values(source.as.organization.name), + Esql.geo_country_values = values(source.geo.country_name), + Esql.event_count = count(*) + by + Esql.time_window_date_trunc, + user.id, + session.id, + source.ip, + o365.audit.ApplicationId +| where Esql.file_name_count_distinct >= 25 +| keep + Esql.*, + user.id, + source.ip, + o365.audit.ApplicationId, + session.id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* 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/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Automated Exfiltration +** ID: T1020 +** Reference URL: https://attack.mitre.org/techniques/T1020/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-m365-teams-rogue-help-desk-chat-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-m365-teams-rogue-help-desk-chat-created.asciidoc new file mode 100644 index 0000000000..8af820c1e9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-m365-teams-rogue-help-desk-chat-created.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-33-m365-teams-rogue-help-desk-chat-created]] +=== M365 Teams Rogue Help Desk Chat Created + +Identifies a one-on-one Microsoft Teams chat created by a user from a foreign tenant whose display name, member profile, or email local-part resembles IT help desk or Microsoft security staff. Adversaries abuse cross-tenant Teams external access to impersonate support personnel and socially engineer victims into granting remote access or disclosing credentials. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2026/04/18/crosstenant-helpdesk-impersonation-data-exfiltration-human-operated-intrusion-playbook/ +* https://www.microsoft.com/en-us/security/blog/2024/05/15/threat-actors-misusing-quick-assist-in-social-engineering-attacks-leading-to-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Teams Rogue Help Desk Chat Created* + + +Threat actors create external Microsoft 365 tenants and initiate unsolicited one-on-one Teams chats while impersonating +IT help desk or Microsoft security personnel. These chats often precede vishing, Quick Assist abuse, or malicious link +delivery. + +Review `user.email`, `user.domain`, `o365.audit.Members.DisplayName`, `o365.audit.ChatThreadId`, and +`o365.audit.ParticipantInfo`. Correlate follow-on `MessageSent` events for `source.ip` and `source.geo`, and +`CallParticipantDetail` events sharing the same `o365.audit.CallId` or chat thread for vishing activity. + + +*Possible investigation steps* + + +- Identify the external sender from `user.email`, `user.domain`, and `o365.audit.Members` and determine whether the + tenant or domain is known and trusted. +- Compare `user.name` to `o365.audit.Members.DisplayName` — actors often use a lowercase mailbox alias such as + `helpdesk` while presenting as `Help Desk` in Teams. +- Confirm `o365.audit.ParticipantInfo.HasForeignTenantUsers` is true and that no guest users are involved. +- Pivot on `o365.audit.ChatThreadId` for `MessageSent` and `CallParticipantDetail` events in the same session. +- Review `MessageSent` `source.ip` and `source.geo` for unexpected origin countries relative to the sender profile. +- Correlate with mail-flood, MFA fatigue, or URL click alerts for the targeted user in the same time window. +- Review whether the victim accepted the chat or responded, and hunt for follow-on remote support tool execution on + their endpoint. +- Check whether the sender tenant appears newly created, trial-based, or otherwise anomalous for your environment. + + +*False positive analysis* + + +- Approved external support vendors may use help desk-style display names. Maintain an allowlist of trusted external + tenants or sender domains when recurring benign matches occur. +- The `user.email` and `user.name` impersonation clauses target external mailbox aliases such as `helpdesk@`. Prefer + exceptions anchored on verified tenant IDs or sender domains rather than broad name-based exclusions. + + +*Response and remediation* + + +- Warn the targeted user not to engage and confirm whether they accepted the chat or shared credentials. +- Block or restrict the external tenant via Teams federation policy if malicious. +- Hunt for additional `ChatCreated` events from the same external tenant across the organization. +- Review Teams external access settings and consider blocking trial tenants or restricting federation to an allowlist. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.action:"ChatCreated" and event.provider:"MicrosoftTeams" and event.outcome:"success" and + o365.audit.ParticipantInfo.HasOtherGuestUsers:false and o365.audit.ParticipantInfo.HasGuestUsers:false and + o365.audit.ParticipantInfo.HasForeignTenantUsers:true and o365.audit.CommunicationType:"OneOnOne" and + ( + o365.audit.Members:( + "Help Desk" or "Help Desk Team" or "Help Desk IT" or "IT Help Desk" or + "Microsoft Security" or "Microsoft Security" or "Microsoft Support" + ) or + user.email:( + *helpdesk* or *help.desk* or *help-desk* or *help_desk* or + *ithelp* or *it.help* or *itsupport* or *it.support* or *it-support* + ) or + user.name:(*helpdesk* or *help-desk* or *ithelp* or *itsupport* or support or itassistant or ithelp or it or it_* or itadmin or it-*) or + + (o365.audit.Members: *.onmicrosoft.com and + o365.audit.Members: (*helpdesk* or *help* or *support* or *protection* or *monitoring* or *security* or *department* or *mandatory* or *network* or *systems*)) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing via Service +** ID: T1566.003 +** Reference URL: https://attack.mitre.org/techniques/T1566/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-multiple-alerts-involving-a-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-multiple-alerts-involving-a-user.asciidoc new file mode 100644 index 0000000000..a2d043bc80 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-multiple-alerts-involving-a-user.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-33-multiple-alerts-involving-a-user]] +=== Multiple Alerts Involving a User + +This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-4h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Multiple Alerts Involving a User* + + +In security environments, monitoring user activity is crucial as adversaries often exploit user accounts to gain unauthorized access. Attackers may trigger multiple alerts by performing suspicious actions under a compromised user account. The detection rule identifies such patterns by correlating diverse alerts linked to the same user, excluding known system accounts, thus prioritizing potential threats for analysts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific user account involved, focusing on the user.name field to gather initial context about the user. +- Examine the timeline and sequence of the triggered alerts to understand the pattern of activity associated with the user, noting any unusual or unexpected actions. +- Cross-reference the user activity with known legitimate activities or scheduled tasks to rule out false positives, ensuring that the actions are not part of normal operations. +- Investigate the source and destination IP addresses associated with the alerts to identify any suspicious or unauthorized access points. +- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts. +- Look into any recent login attempts or authentication failures for the user account to detect potential brute force or credential stuffing attacks. +- Collaborate with the user or their manager to verify if the activities were authorized or if the account might be compromised. + + +*False positive analysis* + + +- Alerts triggered by automated system processes or scripts that mimic user behavior can be false positives. To manage these, identify and exclude known benign scripts or processes from the rule. +- Frequent alerts from users in roles that inherently require access to multiple systems or sensitive data, such as IT administrators, may not indicate compromise. Implement role-based exceptions to reduce noise. +- Alerts generated by legitimate software updates or maintenance activities can be mistaken for suspicious behavior. Schedule these activities during known maintenance windows and exclude them from the rule during these times. +- Users involved in testing or development environments may trigger multiple alerts due to their work nature. Create exceptions for these environments to prevent unnecessary alerts. +- High-volume users, such as those in customer support or sales, may naturally generate more alerts. Monitor these users separately and adjust the rule to focus on unusual patterns rather than volume alone. + + +*Response and remediation* + + +- Isolate the affected user account immediately to prevent further unauthorized access. Disable the account or change the password to stop any ongoing malicious activity. +- Conduct a thorough review of the affected user's recent activities and access logs to identify any unauthorized actions or data access. This will help in understanding the scope of the compromise. +- Remove any malicious software or unauthorized tools that may have been installed on the user's system. Use endpoint detection and response (EDR) tools to scan and clean the system. +- Restore any altered or deleted data from backups, ensuring that the restored data is free from any malicious modifications. +- Notify relevant stakeholders, including IT security teams and management, about the incident and the steps being taken to address it. This ensures that everyone is aware and can provide support if needed. +- Implement additional monitoring on the affected user account and related systems to detect any further suspicious activities. This includes setting up alerts for unusual login attempts or data access patterns. +- Review and update access controls and permissions for the affected user and similar accounts to prevent future incidents. Ensure that least privilege principles are applied. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* +| where kibana.alert.rule.name is not null and user.id is not null and + // Exclude low severity alerts + kibana.alert.risk_score > 21 and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) +| stats + Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.kibana_alert_rule_rule_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.rule_id), + Esql.host_id_distinct_count = COUNT_DISTINCT(host.id), + Esql.kibana_alert_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score), + Esql.event_dataset_distinct_count = COUNT_DISTINCT(event.dataset), + Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name), + Esql.kibana_alert_risk_score_values = VALUES(kibana.alert.risk_score), + Esql.event_dataset_values = VALUES(event.dataset), + Esql.event_module_values = VALUES(event.module), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.host_id_values = VALUES(host.id), + Esql.source_ip_values = VALUES(source.ip), + Esql.destination_ip_values = VALUES(destination.ip) by user.id, user.name + +| where Esql.kibana_alert_rule_name_distinct_count >= 4 AND Esql.kibana_alert_rule_rule_id_distinct_count >= 2 and + // Exclude known system accounts with matches in more than one host + not ( + (length(TO_STRING(user.id)) <= 4 or user.id IN ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0")) and + (Esql.host_id_distinct_count >= 2 or Esql.host_id_distinct_count == 0) + ) + +| keep user.id, user.name, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-network-activity-to-a-suspicious-top-level-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-network-activity-to-a-suspicious-top-level-domain.asciidoc new file mode 100644 index 0000000000..32751fedc5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-network-activity-to-a-suspicious-top-level-domain.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-33-network-activity-to-a-suspicious-top-level-domain]] +=== Network Activity to a Suspicious Top Level Domain + +Identifies DNS queries to commonly abused Top Level Domains by common LOLBINs or executables running from world writable directories or unsigned binaries. This behavior matches on common malware C2 abusing less formal domain names. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.network-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*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.cybercrimeinfocenter.org/top-20-tlds-by-malicious-phishing-domains + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Sysmon + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Network Activity to a Suspicious Top Level Domain* + + + +*Possible investigation steps* + + +- Does the alert-local DNS result and domain shape fit the process role? + - Focus: the alert's `event.action`, `dns.question.name`, `dns.Ext.status`, and `dns.resolved_ip`; use "lookup_result" for resolved IPs and "lookup_requested" for failed or request-only lookups. + - Implication: concern rises when the name is algorithmic, newly introduced for that tool, or resolves to unrelated external infrastructure; weaker when the lookup fails immediately or the domain matches a known vendor pattern for that process, but a failed lookup alone does not clear the process. `.onion` lookups signal Tor hidden-service resolution -- treat these as elevated concern and look for Tor binaries or proxy configuration. + +- Is the alerting binary the expected tool in the expected install context? + - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.pe.original_file_name`. + - Implication: more concerning when the binary is unsigned, renamed, user-writable, or inconsistent with its usual signer. Identity alone does not clear the DNS behavior. + +- Does the command line and launch chain fit a legitimate workflow? + - Focus: `process.command_line`, `process.parent.executable`, and `process.parent.command_line`. + - Implication: more concerning if a document, script, or unexpected launcher started the process, or if the arguments look staged or evasive. + +- Does the same process resolve the domain and then communicate with the returned infrastructure? + - Why: a suspicious DNS lookup carries more weight when the same process reuses the returned IPs for follow-on connections or transfer behavior in the same window. + - Focus: process-scoped "lookup_result" and connection events on the same `host.id`, using `dns.resolved_ip` to bridge `dns.question.name` to `destination.ip`; treat `destination.as.organization.name` as ownership context rather than a verdict. !{investigate{"description":"","label":"Network activity for the alerting process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if the transform returns no results, broaden to host-scoped network events around the alert time. + - Implication: escalate when the same process repeatedly resolves the domain, connects to the returned IPs, or shows suspicious transfer patterns; lower suspicion when activity is limited to a one-off lookup with no matching connection behavior. Missing follow-on network telemetry is unresolved, not benign. + +- Do file events or child processes from the same process chain show download-and-execute or artifact staging? + - Focus: same-host file and process activity around the alert time, scoped to the alert's `process.entity_id`, with attention to `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and later `process.executable` reuse of a written path. + - Hint: if file coverage is missing, keep the artifact review bounded to the same host, lineage, and alert window rather than treating the lookup as harmless. + - Implication: staging risk rises when the chain writes scripts, archives, or executables to user-writable paths and later runs them. + +- Does the same process chain pivot to direct-IP traffic, lookalike domains, or TLD rotation that this rule would miss? + - Why: attackers often keep the same process chain but swap to a nearby domain, a different abusive TLD, or direct-IP egress after the first lookup. + - Focus: reuse the process-scoped network results from the prior step to look for direct `destination.ip` connections with no preceding DNS, sibling `dns.question.name` values under different TLDs, or repeated reuse of the same `dns.resolved_ip` across multiple domains. !{investigate{"description":"","label":"Network activity for the alerting process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the process shifts from the flagged lookup to direct-IP traffic, nearby domain variants, or fast domain and TLD rotation on the same infrastructure; lower suspicion when surrounding DNS stays limited to one recognized vendor domain family with no adjacent variant traffic. + +- If the local DNS, process, or artifact evidence stays suspicious or unresolved, does related alert history show this DNS pattern is isolated or part of broader compromise? + - Focus: related alerts for the same `host.id` and `user.id` in the last 48 hours to test whether the same lineage, domain family, or follow-on activity recurs on the asset or follows the user across hosts. + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the host or user view shows repeated suspicious lineage, related delivery or persistence alerts, or reuse of the same infrastructure on other assets; keep scope narrow when the pattern stays confined to one recognized workflow with no contradictory evidence. + +- Escalate when DNS fit, process context, follow-on communication, artifacts, or variant traffic point to unauthorized C2 or delivery; close only when all evidence aligns with a recognized benign workflow; if mixed or incomplete, preserve and escalate. + + +*False positive analysis* + + +- Software distribution, developer tooling, or security-testing workflows can legitimately query less common TLDs. Confirm by matching the same `process.executable`, `process.code_signature.subject_name`, `dns.question.name` family, and `host.id` across prior alerts or against workflow records. +- Before creating an exception, build on `process.executable`, `process.code_signature.subject_name`, the `dns.question.name` family, and `host.id` or `user.id`. Avoid exceptions on the TLD alone, `process.name` alone, or `host.id` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the `process.executable`, `process.code_signature.subject_name`, `process.parent.command_line`, `dns.question.name` family, and bounded `host.id` or `user.id` scope that proved the workflow. Create an exception only if that same pattern recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, first preserve `dns.question.name`, `dns.resolved_ip`, connected `destination.ip` values, the alert's `process.entity_id`, `process.command_line`, `process.parent.command_line`, and any staged `file.path` values. Then apply reversible containment such as temporary DNS or egress blocks for the observed infrastructure or heightened monitoring on `host.id`. Escalate to host isolation only if the preserved evidence shows likely follow-on communication or staging and the asset role can tolerate stronger containment. +- If confirmed malicious, document the alert's `process.entity_id`, `process.command_line`, `process.parent.command_line`, written `file.path` artifacts, and connected `dns.question.name` or `destination.ip` infrastructure before initiating response actions. Prefer endpoint isolation as the first containment step; if direct endpoint response is unavailable, escalate with the preserved artifact set to the team that can isolate the host. Block the confirmed malicious domains and direct-IP destinations before terminating processes or deleting files. +- After containment, review other `host.id` and `user.id` alerts for the same `dns.question.name`, `destination.ip`, or `process.executable` pattern before deleting artifacts or restoring access. Then eradicate staged binaries, scripts, and any persistence or proxy changes identified during the file or variant review, and remediate the entry path that allowed the suspicious process to run. If the same suspicious window includes credential, admin-tool, or remote-session alerts, review those sessions for follow-on misuse and reset exposed credentials when the evidence supports compromise. + + +==== 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/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type == "windows" and dns.question.name != null and + ( + process.name : ("MSBuild.exe", "mshta.exe", "wscript.exe", "powershell.exe", "pwsh.exe", "msiexec.exe", "rundll32.exe", + "bitsadmin.exe", "InstallUtil.exe", "python.exe", "regsvr32.exe", "dllhost.exe", "node.exe", "curl.exe", + "java.exe", "javaw.exe", "*.pif", "*.com", "*.scr") or + (?process.code_signature.trusted == false or ?process.code_signature.exists == false) or + ?process.code_signature.subject_name : ("AutoIt Consulting Ltd", "OpenJS Foundation", "Python Software Foundation") or + ?process.executable : ( + "?:\\Users\\Public\\*.exe", "?:\\ProgramData\\*.exe", "?:\\Users\\*\\Downloads\\*.exe", + "\\Device\\HarddiskVolume*\\Users\\Public\\*.exe", "\\Device\\HarddiskVolume*\\ProgramData\\*.exe", "\\Device\\HarddiskVolume*\\Users\\*\\Downloads\\*.exe" + ) + ) and +dns.question.name regex """.*\.(top|buzz|xyz|rest|ml|cf|gq|ga|onion|monster|cyou|quest|cc|bar|cfd|click|cam|surf|tk|shop|club|icu|pw|ws|online|fun|life|boats|store|hair|skin|motorcycles|christmas|lol|makeup|mom|bond|beauty|biz|live|work|zip|country|accountant|date|party|science|loan|win|men|faith|review|racing|download|host|zone)""" and + +not process.executable : ( + "?:\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\*.exe", + "\\Device\\HarddiskVolume*\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\*.exe", + "?:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Platform\\Versions\\*\\*.exe", + "\\Device\\HarddiskVolume*\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Platform\\Versions\\*\\*.exe" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: DNS +** ID: T1071.004 +** Reference URL: https://attack.mitre.org/techniques/T1071/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Sub-technique: +** Name: MSBuild +** ID: T1127.001 +** Reference URL: https://attack.mitre.org/techniques/T1127/001/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-newly-observed-ipsec-nat-traversal-peer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-newly-observed-ipsec-nat-traversal-peer.asciidoc new file mode 100644 index 0000000000..5b16c71ca8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-newly-observed-ipsec-nat-traversal-peer.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-33-newly-observed-ipsec-nat-traversal-peer]] +=== Newly Observed IPSEC NAT Traversal Peer + +This rule identifies outbound IPSEC NAT Traversal (NAT-T) traffic to an external destination IP that was not observed during the previous 5 days. IPSEC is a VPN technology that allows one system to talk to another using encrypted tunnels. NAT Traversal encapsulates IPSEC ESP traffic in UDP and, once a NAT device is detected, both peers float to UDP port 4500 for the tunnel data channel. Newly observed external NAT-T peers may indicate unauthorized VPN use or an adversary tunneling command and control or exfiltration traffic over the Internet. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Tactic: Command and Control +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek +* 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 Newly Observed IPSEC NAT Traversal Peer* + + +IPSEC NAT Traversal facilitates secure VPN communication across NAT devices by encapsulating IPSEC packets in UDP, typically using port 4500. While essential for legitimate encrypted traffic, adversaries exploit this to mask malicious activities and bypass network defenses. This rule surfaces an external destination the first time NAT-T traffic to it is observed within a 5-day history window. + + +*Possible investigation steps* + + +- Review the source and destination IP addresses associated with the UDP traffic on port 4500 to determine if they are known or expected within your network environment. +- Analyze the volume and frequency of the detected traffic to assess whether it aligns with typical IPSEC NAT Traversal usage or if it appears anomalous. +- Check for any associated network traffic events in the same timeframe that might indicate a pattern of suspicious activity, such as unusual data transfer volumes or connections to known malicious IP addresses. +- Investigate the endpoint or device generating the traffic to verify if it is authorized to use IPSEC NAT Traversal and if it has any history of security incidents or vulnerabilities. +- Correlate the detected activity with any recent changes in network configurations or security policies that might explain the traffic pattern. +- Consult threat intelligence sources to determine if the destination IP address or domain has been associated with known threat actors or command and control infrastructure. + + +*False positive analysis* + + +- A legitimate VPN gateway will alert when it is first deployed or first observed after more than 5 days of inactivity. +- Legitimate VPN traffic using IPSEC NAT Traversal can trigger alerts. Regularly review and whitelist known IP addresses or subnets associated with authorized VPN connections to reduce false positives. +- Network devices or services that rely on IPSEC for secure communication may generate expected traffic on port 4500. Identify and document these devices, then create exceptions in the detection rule to prevent unnecessary alerts. +- Automated backup or synchronization services that use IPSEC for secure data transfer might be flagged. Monitor these services and exclude their traffic patterns if they are verified as non-threatening. +- Some enterprise applications may use IPSEC NAT Traversal for secure communication. Conduct an inventory of such applications and adjust the rule to exclude their traffic after confirming their legitimacy. +- Regularly update the list of known safe IP addresses and services to ensure that new legitimate sources of IPSEC NAT Traversal traffic are promptly excluded from triggering alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further potential malicious activity and lateral movement. +- Conduct a thorough analysis of the isolated system to identify any signs of compromise, such as unauthorized access or data exfiltration, focusing on logs and network traffic related to UDP port 4500. +- Block all suspicious IP addresses associated with the detected traffic on port 4500 at the network perimeter to prevent further communication with potential threat actors. +- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to ensure they effectively block unauthorized IPSEC NAT Traversal traffic, particularly on UDP port 4500. +- Restore the affected system from a known good backup if any signs of compromise are confirmed, ensuring that all security patches and updates are applied before reconnecting to the network. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for UDP traffic on port 4500 to detect and respond to any future suspicious activity promptly. + +==== Rule query + + +[source, js] +---------------------------------- +FROM packetbeat-*, auditbeat-*, filebeat-*, logs-network_traffic.flow-*, logs-panw.panos*, logs-pfsense.log-*, logs-zeek.connection-* METADATA _id +| WHERE ( + data_stream.dataset IN ("network_traffic.flow", "zeek.connection") + OR MV_CONTAINS(event.category, "network") + OR MV_CONTAINS(event.category, "network_traffic") + ) + AND network.transport == "udp" + AND source.port == 4500 + AND destination.port == 4500 + AND CIDR_MATCH(source.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16") + AND NOT CIDR_MATCH( + destination.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" + ) + AND ( + data_stream.dataset IS NULL + OR data_stream.dataset != "panw.panos" + OR event.action IS NULL + OR event.action NOT IN ("flow_dropped", "flow_denied") + ) +| EVAL Esql.dataset = COALESCE(data_stream.dataset, event.dataset) +| STATS + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp), + Esql.event_count = COUNT(*), + Esql.source_ip_count = COUNT_DISTINCT(source.ip), + Esql.source_ip_values = MV_SLICE(VALUES(source.ip), 0, 100), + Esql.event_action_values = VALUES(event.action), + Esql.dataset_values = VALUES(Esql.dataset), + Esql.observer_name_values = MV_SLICE(VALUES(observer.name), 0, 20) + BY destination.ip +| EVAL Esql.recent = DATE_DIFF("minute", Esql.first_seen, NOW()) +| WHERE Esql.recent >= 0 AND Esql.recent <= 10 +| KEEP destination.ip, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ +* Technique: +** Name: Encrypted Channel +** ID: T1573 +** Reference URL: https://attack.mitre.org/techniques/T1573/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-newly-seen-commonly-abused-network-scanner.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-newly-seen-commonly-abused-network-scanner.asciidoc new file mode 100644 index 0000000000..2273f4d01e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-newly-seen-commonly-abused-network-scanner.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-33-newly-seen-commonly-abused-network-scanner]] +=== Newly Seen Commonly Abused Network Scanner + +Identifies newly observed execution of SoftPerfect Network Scanner or Advanced IP/Port Scanner on a Windows host. Adversaries commonly use these legitimate scanners during post-compromise discovery to map live hosts, open ports, and reachable systems, then select targets for lateral movement. + +*Rule type*: new_terms + +*Rule indices*: + +* 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-* + +*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.cisa.gov/news-events/cybersecurity-advisories/aa23-319a +* https://thedfirreport.com/2025/06/30/hide-your-rdp-password-spray-leads-to-ransomhub-deployment/ +* https://thedfirreport.com/2020/11/23/pysa-mespinoza-ransomware/ +* https://www.microsoft.com/en-us/security/blog/2023/07/06/the-five-day-job-a-blackbyte-ransomware-intrusion-case-study/ +* https://www.cyfirma.com/news/weekly-intelligence-report-26-jan-2024/ +* https://github.com/Securityinbits/defender-hunt-queries/blob/main/discovery-tools.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Platform: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Rule Type: New Terms +* 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 + +*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 Newly Seen Commonly Abused Network Scanner* + + +This rule detects the first observed execution of commonly abused network-scanning tools on a Windows host, which can signal post-compromise discovery activity. After gaining a foothold, an attacker may run a portable scanner across the local subnet to identify live systems and exposed SMB or RDP services, then prioritize targets for lateral movement. + + +*Possible investigation steps* + + +- Validate the executable’s path, digital signature, hash reputation, download origin, command line, parent process, user account, and prevalence across the environment to distinguish authorized software from a renamed or portable copy. +- Correlate the execution with network telemetry to identify scanned address ranges, destination ports, connection volume, and whether sensitive systems or lateral-movement services such as SMB, RDP, WinRM, or SSH were targeted. +- Review nearby endpoint and identity activity for initial-access or post-compromise indicators, including suspicious downloads, archive extraction, PowerShell execution, credential access, remote logons, service creation, and scheduled tasks. +- Confirm with the host owner and IT teams whether the scanner and scope were approved, considering the user’s role, device purpose, execution time, and any related change or vulnerability-management activity. +- If unauthorized, isolate the host, preserve the binary and relevant telemetry, block confirmed malicious indicators, reset potentially exposed credentials, and investigate contacted systems for follow-on access. + + +*False positive analysis* + + +- An authorized administrator may run the scanner for network inventory or connectivity troubleshooting; verify the user’s role, executable path and signature, scanned range, and any associated change record. +- An approved security assessment or vulnerability-management activity may execute the scanner on a newly provisioned or infrequently used Windows host; confirm the timing, source host, target scope, and authorization with the responsible team. + + +*Response and remediation* + + +- Isolate the affected Windows host and restrict its access to scanned subnets and services such as SMB, RDP, WinRM, and SSH while preserving the scanner executable, command history, and relevant forensic evidence. +- Remove unauthorized scanner binaries and attacker persistence, including suspicious scheduled tasks, services, startup entries, PowerShell scripts, remote-management tools, and newly created accounts. +- Reset credentials used on the compromised host, revoke active sessions and tokens, and investigate contacted systems for remote logons, service creation, administrative shares, or other lateral-movement activity. +- Escalate immediately to incident response if scanning reached sensitive systems, privileged credentials may be exposed, or follow-on access appears on another host, and expand containment to all affected accounts and endpoints. +- Reimage or restore compromised systems from a verified known-good baseline, patch exploited weaknesses, and validate endpoint protection, logging, and business functionality before reconnecting them. +- Block malicious file hashes and download sources, apply application control to unapproved portable scanners, restrict unnecessary east-west connectivity, and alert on future scanner execution or high-volume port probing. + + + +==== 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/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- 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] +---------------------------------- +event.category:process and host.os.type:windows and event.type:start and +( + process.name.caseless:( + netscan*.exe or advanced_ip_scanner*.exe or + advanced_ip_scanner_console.exe or advanced_port_scanner.exe + ) or + process.pe.original_file_name : ( + "advanced_ip_scanner.exe" or + "advanced_port_scanner.exe" or + "advanced_ip_scanner_console.exe" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-persistence-via-update-orchestrator-service-hijack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-persistence-via-update-orchestrator-service-hijack.asciidoc new file mode 100644 index 0000000000..6fa4fddd82 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-persistence-via-update-orchestrator-service-hijack.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-33-persistence-via-update-orchestrator-service-hijack]] +=== Persistence via Update Orchestrator Service Hijack + +Identifies potential hijacking of the Microsoft Update Orchestrator Service to establish persistence with an integrity level of SYSTEM. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/irsl/CVE-2020-1313 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Use Case: Vulnerability +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Persistence via Update Orchestrator Service Hijack* + + + +*Possible investigation steps* + + +- What did UsoSvc actually launch, and does the child identity fit Windows or Office servicing? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Hint: use `process.parent.command_line` to confirm svchost is hosting UsoSvc, not just sharing the name. + - Implication: escalate when UsoSvc launches a renamed, user-writable, unsigned, rare, or non-servicing child; lower concern only when path, signer, and parent service context match a recognized Windows Update or Click-to-Run component. Identity alone does not clear it. + +- Does the command line show attacker-controlled work running with service-level privilege? + - Why: on unpatched hosts, CVE-2020-1313 ScheduleWork can queue signed System32 or Common Files binaries with attacker-controlled arguments. + - Focus: `process.command_line`, `process.Ext.token.integrity_level_name`, and `user.id`. + - Implication: escalate when "cmd.exe", "rundll32.exe", "regsvr32.exe", a scripting host, or another signed binary runs shell, download, staging, redirection, or persistence arguments under SYSTEM or high integrity; lower concern when arguments fit the exact servicing binary workflow. + +- If registry telemetry is available, was matching work queued under the Update Orchestrator UScheduler path? + - Focus: same `host.id` registry events for `registry.path` under "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Orchestrator\UScheduler", with `registry.value`, `registry.data.strings`, and writer `process.executable`. + - Range: search several days before the alert; queued work can run overnight or after a multi-day service window. + - Hint: interpret queued strings with `registry.data.type`, then compare them to `process.command_line` and `process.executable`; missing registry telemetry is unresolved, not benign. + - Implication: escalate when the queue names the same unusual child or arguments, especially from a non-servicing writer; absent queue history only limits this corroborator. + +- Did the child stage artifacts or spawn follow-on processes that extend the abuse? + - Focus: child starts from `process.entity_id`; if file telemetry exists, same-process `file.path`, `file.Ext.original.path`, and `file.origin_url`. + - !{investigate{"description":"","label":"Child process starts from the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"File events for the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: scope file pivots with `host.id` plus `process.entity_id`; use `host.id` plus `process.pid` and a tight alert window only when entity ID is absent. Missing file telemetry limits artifact review, but child-process and command evidence can justify escalation. + - Implication: escalate when the child writes executable or scriptable content to user-writable or deceptive paths, renames staged content, or launches written artifacts; lower concern when activity stays inside the recognized servicing path with no follow-on execution. + +- If network telemetry is available, does the child contact destinations consistent with servicing? + - Focus: process-scoped DNS `dns.question.name` and `dns.resolved_ip`, then connections by `destination.ip`, `destination.port`, and `destination.as.organization.name`. !{investigate{"description":"","label":"Network events for the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: use "lookup_result" DNS events for populated `dns.resolved_ip`; scope with `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` and a tight alert window. Infrastructure ownership is context, not a verdict; missing network telemetry is unresolved, not benign. + - Implication: escalate when the child reaches rare or public infrastructure unrelated to Microsoft servicing, the signer, or recovered queue; lower concern when destinations fit the signed binary's normal update or repair endpoints. + +- If local evidence remains suspicious or unresolved, do related alerts change scope? + - Focus: compare recent alerts for the same `process.executable`. !{investigate{"description":"","label":"Alerts involving the same child executable","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: review same `host.id` alerts only when child identity, command, queue, artifact, or destination evidence needs scope. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same child path or host shows repeated privilege-escalation, persistence, staging, or follow-on alerts; keep urgency local when isolated and no corroborating alert history appears. + +- Escalate on attacker-controlled UsoSvc child identity or command intent, using queue, artifact, destination, or related-alert evidence as corroboration; close only when alert-local and recovered evidence tie to one exact servicing or authorized validation workflow without contradictions; preserve artifacts and escalate when evidence is mixed, incomplete, or unavailable. + + +*False positive analysis* + + +- Windows Update, repair, or Office Click-to-Run servicing can trigger this rule when UsoSvc queues a servicing component outside the exclusions. Close from telemetry first: child path, signer, command line, parent service context, UScheduler queue content when available, artifacts, destinations, and `host.id` cohort must align with one recognized servicing workflow. Patch-window or change records may corroborate; prior alerts only prove exception stability after current evidence fits. +- Authorized exploit-validation or adversary-emulation tests can exercise Update Orchestrator abuse. Confirm stable payload identity such as `process.hash.sha256`, `process.command_line`, expected `host.id` or `user.id` test scope, matching queue content when available, and no spread to unrelated production hosts. Use engagement records or prior test alerts only as corroboration, and do not exception on `process.parent.executable`, "UsoSvc", or `process.name` alone. + + +*Response and remediation* + + +- If confirmed benign: + - Record the exact evidence that proved the servicing or test workflow: child identity, command line, parent service context, queue content when available, same-process artifacts or destinations, and recurrence or records. Then reverse temporary containment and build any exception from that minimum pattern plus `host.id`, not from UsoSvc or a generic signed-binary condition. +- If suspicious but unconfirmed: + - Preserve a case export with the alert process instance, process tree, command line, UScheduler queue values when available, writer-process details, written artifacts, destination indicators, and related-alert context before cleanup. + - Apply reversible containment tied to the finding, such as blocking the child hash or destination, temporarily disabling the queued work after preservation, or increasing host monitoring. Escalate to host isolation only when host criticality allows it and artifacts, destinations, or related alerts show active follow-on behavior. +- If confirmed malicious: + - Preserve the case export first: child `process.entity_id` or `process.pid`, command line, queue values, writer lineage, payload hashes, artifact paths, and destination indicators. Then isolate the host when the identity, command, queue, artifact, or destination evidence confirms unauthorized UsoSvc execution. + - Remove the malicious queued work or restore the Update Orchestrator registry state to known-good, eradicate only payloads and persistence artifacts identified during triage, validate that UsoSvc returns to recognized servicing children, and review other hosts for the same child path or queue pattern before deleting preserved evidence. +- Post-incident hardening: + - Apply the June 2020 or later Windows security updates where still applicable because the fix blocks untrusted caller queuing, retire unsupported builds, restrict write paths that can feed Update Orchestrator abuse, and retain registry/process telemetry for UScheduler queue changes. + + +==== 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/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.executable : "C:\\Windows\\System32\\svchost.exe" and + process.parent.args : "UsoSvc" and + not process.executable : ( + "?:\\Windows\\System32\\UsoClient.exe", + "?:\\Windows\\System32\\MusNotification.exe", + "?:\\Windows\\System32\\MusNotificationUx.exe", + "?:\\Windows\\System32\\MusNotifyIcon.exe", + "?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\System32\\WerMgr.exe", + "?:\\Windows\\UUS\\amd64\\UsoCoreWorker.exe", + "?:\\Windows\\System32\\UsoCoreWorker.exe" + ) and + not process.name : ("MoUsoCoreWorker.exe", "OfficeC2RClient.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Services Registry Permissions Weakness +** ID: T1574.011 +** Reference URL: https://attack.mitre.org/techniques/T1574/011/ +* 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: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-data-exfiltration-through-curl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-data-exfiltration-through-curl.asciidoc new file mode 100644 index 0000000000..430953a9fc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-data-exfiltration-through-curl.asciidoc @@ -0,0 +1,219 @@ +[[prebuilt-rule-8-19-33-potential-data-exfiltration-through-curl]] +=== Potential Data Exfiltration Through Curl + +Detects the use of curl to upload files to an internet server. Threat actors often will collect and exfiltrate data on a system to their C2 server for review. Many threat actors have been observed using curl to upload the collected data. Use of curl in this way, while not inherently malicious, should be considered highly abnormal and suspicious activity. + +*Rule type*: eql + +*Rule indices*: + +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://everything.curl.dev/usingcurl/uploads +* https://cloud.google.com/blog/topics/threat-intelligence/disrupting-gridtide-global-espionage-campaign?hl=en + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Auditd Manager +* Data Source: Windows Security Event Logs + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Data Exfiltration Through Curl* + + +Curl is a command-line tool used for transferring data with URLs, commonly employed for legitimate data exchange tasks. However, adversaries can exploit curl to exfiltrate sensitive data by uploading compressed files to remote servers. The detection rule identifies suspicious curl usage by monitoring for specific command patterns and arguments indicative of data uploads, flagging abnormal activities for further investigation. + + +*Possible investigation steps* + + +- Review the process command line to confirm the presence of suspicious arguments such as "-F", "-T", "-d", or "--data*" and check for any compressed file extensions like .zip, .gz, or .tgz being uploaded to an external server. +- Investigate the parent process of the curl command to understand the context in which curl was executed, including the parent executable and its purpose. +- Examine network logs to identify the destination IP address or domain to which the data was being uploaded, and assess whether it is a known or suspicious entity. +- Check for any recent file creation or modification events on the host that match the compressed file types mentioned in the query, which could indicate data collection prior to exfiltration. +- Correlate this event with other security alerts or logs from the same host to identify any patterns of behavior that might suggest a broader compromise or data exfiltration attempt. + + +*False positive analysis* + + +- Legitimate data transfers using curl for system backups or data synchronization can trigger the rule. To manage this, identify and whitelist specific processes or scripts that are known to perform these tasks regularly. +- Automated system updates or software installations that use curl to download and upload data might be flagged. Exclude these processes by verifying their source and adding them to an exception list if they are from trusted vendors. +- Internal data transfers within a secure network that use curl for efficiency can be mistaken for exfiltration. Monitor the destination IP addresses and exclude those that are internal or known safe endpoints. +- Developers or system administrators using curl for testing or development purposes may inadvertently trigger the rule. Educate these users on the potential alerts and establish a process for them to notify security teams of their activities to prevent unnecessary investigations. +- Scheduled tasks or cron jobs that use curl for routine data uploads should be reviewed and, if deemed safe, added to an exception list to avoid repeated false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further data exfiltration and contain the threat. +- Terminate any suspicious curl processes identified by the detection rule to stop ongoing data transfers. +- Conduct a forensic analysis of the affected system to identify any additional malicious activities or compromised data. +- Change credentials and access keys that may have been exposed or used during the incident to prevent unauthorized access. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further action. +- Review and update firewall and network security rules to block unauthorized outbound traffic, especially to suspicious or unknown external servers. +- Implement enhanced monitoring and logging for curl usage and similar data transfer tools to detect and respond to future exfiltration attempts promptly. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name : ("curl", "curl.exe") and +( + process.args in ("-T", "--upload-file") or + ( + (process.args in ("-F", "-d", "--form") or process.args like "--data*") and process.command_line like "*@*" + ) +) and +( + process.command_line like ("*http:*", "*https:*", "*ftp:*", "*ftps:*") or + process.command_line regex ".*[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}.*" +) and +not ( + process.args : ( + "https://*/ap/fleet/*", "https://*/api/saved_objects/*", "http*localhost:*", "http*127.0.0.*", "*ApiKey*", "http*.us-central1.run.app/*", + "*Authorization*", "*session.id*", "http*.elastic-cloud.com*", "http*.elastic.dev*", "http*.elastic.cloud*", "http*.aws.found.io*", + "http*.gcp.cloud.es.io*", "http*.cisco.com/api/*", "-u", "http://192.168*", + "*incoming.telemetry.mozilla.org*", "*cloudamize.com*" + ) or + process.args == "--unix-socket" or + process.parent.name like "clevis*" or + ?process.parent.executable in ("/usr/bin/clevis-decrypt-tang", "/bin/clevis-decrypt-tang") or + ( + ?process.parent.command_line like "*oracle/retina/vvaa-*" and + process.working_directory == "/home/oracle" + ) or + ( + process.working_directory == "/home/oracle" and + process.args == "--trace" and + ?process.parent.executable like "/home/oracle/retina/vvaa-*-oracle/app/*.sh" + ) or + ( + process.working_directory == "/home/service/common/system.check" and + ?process.parent.command_line == "/bin/bash ./check.sh" + ) or + ( + ?process.parent.executable == "C:\\Windows\\SysWOW64\\cmd.exe" and + ?process.parent.args like "?:\\*\\temp-app\\caller_batch_*.bat" + ) or + ( + ?process.parent.executable == "/opt/rudder/share/commands/agent-run" and + ?process.parent.command_line == "/bin/sh /opt/rudder/share/commands/agent-run -uRN" and + process.args like "/var/rudder/reports/ready/*" + ) or + ( + ?process.parent.executable like "/var/lib/docker/overlay2/*/merged/usr/bin/bash" and + ?process.parent.command_line like "bash /home/*/old/scripts/crawler.sh start" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Sub-technique: +** Name: Exfiltration Over Symmetric Encrypted Non-C2 Protocol +** ID: T1048.001 +** Reference URL: https://attack.mitre.org/techniques/T1048/001/ +* Sub-technique: +** Name: Exfiltration Over Unencrypted Non-C2 Protocol +** ID: T1048.003 +** Reference URL: https://attack.mitre.org/techniques/T1048/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-entra-id-prt-extraction-via-browsercore.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-entra-id-prt-extraction-via-browsercore.asciidoc new file mode 100644 index 0000000000..01b8d37fdd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-entra-id-prt-extraction-via-browsercore.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-33-potential-entra-id-prt-extraction-via-browsercore]] +=== Potential Entra ID PRT Extraction via BrowserCore + +Identifies anomalous execution of BrowserCore.exe, the Windows component used by Chromium-based browsers for native messaging with the Web Account Manager (WAM). Adversaries abuse BrowserCore to extract Entra ID Primary Refresh Tokens (PRTs) without interactive browser context, enabling session hijacking. Legitimate BrowserCore launches carry a chrome-extension:// argument from the browser native-messaging host. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.armadin.com/blog-posts/prtremote-extract-prt-cookies-remotely-with-interactivetoken-scheduled-task +* https://github.com/dmcxblue/ANIMO/blob/master/helpers/scripts/GrabTokenAzureAD/PrtExtractor.cs +* https://attack.mitre.org/techniques/T1528/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Platform: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Rule Type: ESQL +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Entra ID PRT Extraction via BrowserCore* + + +BrowserCore.exe is the Chromium native-messaging helper that brokers Web Account Manager (WAM) / Entra ID token +operations for Edge and Chrome. Tools such as PRTRemote and PrtExtractor invoke it outside the browser's +native-messaging context to obtain Primary Refresh Tokens (PRTs). + + +*Possible investigation steps* + + +- Is BrowserCore running from a non-canonical path or with a mismatched original filename? + - Focus: `process.executable`, `process.name`, `process.pe.original_file_name`, `process.hash.sha256`, and signer fields. + - Implication: escalate when the PE original name is BrowserCore.exe but the path is outside + `C:\Windows\BrowserCore\`, or when the binary is recently dropped/renamed. + +- Does the command line lack the browser native-messaging extension URI? + - Focus: `process.command_line`, `process.parent.name`, `process.parent.executable`, `process.parent.command_line`. + - Hint: legitimate launches include `chrome-extension://`. Abuse often omits that URI and may be launched by Task + Scheduler, scripts, or remote tools. + - Implication: escalate when `chrome-extension://` is absent and the parent is `svchost.exe` (task), `powershell.exe`, + `wscript.exe`, or another unexpected launcher. + +- Was there related token theft or Entra ID activity around the same time? + - Focus: related alerts for `user.id` / `host.id` covering credential access, unusual logons, or cloud session abuse. + - Implication: broaden scope when PRT extraction coincides with suspicious Azure/Entra sign-ins or cookie theft. + + +*False positive analysis* + + +- Legitimate browser SSO and account linking launch BrowserCore with a `chrome-extension://` argument and should not + match pivot 2. Rare custom helpers that invoke BrowserCore without that URI may need exceptions scoped to + `process.executable`, `process.parent.executable`, `user.id`, and `host.id`. + + +*Response and remediation* + + +- If confirmed malicious, isolate the host, terminate the anomalous BrowserCore tree, and assume the user's Entra ID + PRT/session may be compromised: revoke refresh tokens / sign the user out of all sessions and rotate credentials. +- Hunt for the same `process.command_line` pattern, scheduled tasks, or scripts that invoke BrowserCore across the estate. +- Remove persistence (scheduled tasks, scripts) that launched BrowserCore outside the browser native-messaging flow. + + +==== 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/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- 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-sentinel_one_cloud_funnel.*, logs-m365_defender.event-* metadata _id, _version, _index +| where KQL(""" event.category : "process" and event.type : "start" and host.os.type : "windows" """) and + to_lower(process.name) == "browsercore.exe" and process.parent.name is not null and process.command_line is not null and + not to_lower(process.command_line) like "*chrome-extension://*" +| keep + @timestamp, + _id, + _version, + _index, + data_stream.namespace, + host.id, + host.name, + user.name, + user.id, + process.entity_id, + process.name, + process.executable, + process.command_line, + process.pe.original_file_name, + process.parent.name, + process.parent.executable, + process.parent.command_line + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* 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-33/prebuilt-rule-8-19-33-potential-etherhiding-c2-via-blockchain-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-etherhiding-c2-via-blockchain-connection.asciidoc new file mode 100644 index 0000000000..41bbfe5249 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-etherhiding-c2-via-blockchain-connection.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-33-potential-etherhiding-c2-via-blockchain-connection]] +=== Potential Etherhiding C2 via Blockchain Connection + +Detects when a scripting interpreter makes an outbound network connection to an Ethereum blockchain endpoint for command and control purposes. Adversaries may leverage Ethereum blockchain infrastructure as a covert C2 channel to receive commands and exfiltrate data, as observed in campaigns like SleepyDuck malware. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* 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://secureannex.com/blog/sleepyduck-malware/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Etherhiding C2 via Blockchain Connection* + + +Etherhiding is an advanced command and control technique where threat actors store malicious configurations, commands, or payload URLs within blockchain transactions on platforms like Ethereum or Binance Smart Chain. This approach provides a highly resilient and censorship-resistant C2 infrastructure since blockchain data cannot be taken down or modified. This detection rule identifies script interpreters or suspicious processes connecting to blockchain API endpoints that may be retrieving attacker-controlled data from the blockchain. + + +*Possible investigation steps* + + +- Review the process.name and process.executable fields to identify which application is making blockchain API requests and assess whether cryptocurrency or Web3 functionality is expected on this system. +- Examine the destination.domain and dns.question.name fields to identify the specific blockchain API endpoint being queried, such as Infura, Alchemy, or public RPC endpoints. +- Analyze the process.command_line and process.args to understand what code or script is executing and look for hardcoded contract addresses or wallet addresses that may be querying blockchain data. +- Investigate the process.parent.executable and parent process chain to determine how the blockchain-querying process was launched and identify the initial execution vector. +- Review network connection payloads if available to identify the specific blockchain queries being made and extract any contract addresses or transaction hashes being queried. +- Search threat intelligence sources for the identified contract addresses or wallet addresses to determine if they are associated with known malicious campaigns. +- Correlate with file modification events on the same host to identify if the blockchain data is being written to disk or used to configure malware. + + +*False positive analysis* + + +- Cryptocurrency wallet applications and browser extensions legitimately access blockchain APIs to display balances and transaction history. Verify if the user has approved cryptocurrency applications. +- Web3 developers and blockchain application developers may use blockchain APIs during development and testing. Confirm with development teams if such activities are expected. +- Decentralized application (dApp) browsers and related tools access blockchain data as part of normal operations. Verify if these tools are sanctioned for business use. +- NFT marketplaces and related applications may query blockchain data for asset verification. Confirm if such applications are approved. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further C2 communication or payload retrieval. +- Terminate the suspicious process making blockchain API connections and prevent it from restarting. +- Extract and analyze the blockchain contract addresses or transaction data being queried to understand the malicious payload or configuration. +- Conduct a thorough malware analysis of the responsible application to identify its full capabilities and persistence mechanisms. +- Block the identified blockchain API endpoints at the network perimeter if they are not required for legitimate business purposes. +- Search for similar blockchain API connections across other endpoints to identify potential lateral movement or additional compromised systems. +- Escalate to the security operations team for comprehensive incident response if the activity confirms an active Etherhiding-based attack. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=15s + [network where host.os.type == "macos" and event.type == "start" and + (process.name in ("bash", "sh", "zsh", "osascript", "node", "Cursor", "Cursor Helper (Plugin)", "Windsurf", "Windsurf Helper (Plugin)") or + process.name like ("python*", "ruby*", "perl*", "tclsh*")) and + destination.domain like ("eth-mainnet*", "ethereum*", "eth.*.com", + "*.drpc.org", "polygon-rpc.com", "polygon-mainnet*", "*.polygon.technology", + "bsc-dataseed*", "*.bnbchain.org", "arb1.arbitrum.io", "mainnet.base.org", + "rpc.ankr.com", "*.infura.io", "*.alchemy.com", "*.quiknode.pro", + "*.publicnode.com", "*.chainstack.com")] + [file where host.os.type == "macos" and event.action == "modification" and file.extension in ("js", "py", "sh")] + +---------------------------------- + +*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/ +* Sub-technique: +** Name: Dead Drop Resolver +** ID: T1102.001 +** Reference URL: https://attack.mitre.org/techniques/T1102/001/ +* Sub-technique: +** Name: Bidirectional Communication +** ID: T1102.002 +** Reference URL: https://attack.mitre.org/techniques/T1102/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: 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-etherhiding-c2-via-curl-json-rpc-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-etherhiding-c2-via-curl-json-rpc-request.asciidoc new file mode 100644 index 0000000000..ae20850d1f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-etherhiding-c2-via-curl-json-rpc-request.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-33-potential-etherhiding-c2-via-curl-json-rpc-request]] +=== Potential EtherHiding C2 via Curl JSON-RPC Request + +Detects when curl or nscurl is spawned by a shell or osascript to make a JSON-RPC request to a blockchain endpoint for command and control purposes. Adversaries may leverage blockchain smart contracts as a covert C2 channel to retrieve commands or payload staging information, as observed in ClickFix campaigns. + +*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://notes.netbytesec.com/2026/08/anatomy-of-macos-clickfix-crimekit-that.html +* https://cloud.google.com/blog/topics/threat-intelligence/dprk-adopts-etherhiding +* https://cloud.google.com/blog/topics/threat-intelligence/unc5142-etherhiding-distribute-malware + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential EtherHiding C2 via Curl JSON-RPC Request* + + +EtherHiding is a command and control technique in which threat actors store malicious configuration, commands, +or payload URLs inside smart contract data on public blockchains. Because the blockchain is immutable and the +RPC endpoints are legitimate public infrastructure, this provides a takedown-resistant C2 channel. On macOS, +ClickFix-delivered loaders have been observed reading contract data by spawning curl from a shell or osascript +with a raw JSON-RPC eth_call request body. + + +*Possible investigation steps* + + +- Review process.command_line to identify the destination RPC endpoint, the contract address in the eth_call + parameters, and the method selector. +- Examine the parent process chain (process.parent.command_line, effective parent) to determine how the shell + or osascript was launched — interactive terminal, LaunchAgent, or another persistence mechanism. +- Search the same host for follow-on network connections shortly after this event; EtherHiding reads are + typically followed by a connection to the decoded C2 host. +- Check for recent LaunchAgent or LaunchDaemon plist creation on the host, which commonly accompanies this + activity as persistence. +- Search the contract address against threat intelligence sources to identify the associated campaign. +- Pivot fleet-wide on the destination RPC domain and any decoded C2 domains to identify additional hosts. + + +*False positive analysis* + + +- Web3 developers may test contract calls with curl against RPC endpoints. Verify whether the user has a + legitimate blockchain development role and whether the parent context (terminal session vs. persistence + item) matches interactive development work. +- CI or build scripts that query chain state via curl could match. Confirm with the owning team and consider + excluding specific parent scripts or hosts. + + +*Response and remediation* + + +- Isolate the affected host to interrupt the C2 channel. +- Terminate the parent shell or osascript process tree. +- Identify and remove any associated persistence (LaunchAgents/LaunchDaemons) and decoded payloads. +- Block decoded C2 domains identified from the contract data; note that blocking public RPC aggregators may + impact legitimate use and should be a risk-based decision. +- Rotate credentials accessible from the host and review for evidence of data theft. +- Escalate for full incident response if the activity chains from a ClickFix or social engineering delivery. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + process.name in ("curl", "nscurl") and + process.parent.name in ("osascript", "bash", "sh", "zsh") and + process.command_line like~ ("*eth_call*", "*\"jsonrpc\"*") + +---------------------------------- + +*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/ +* Sub-technique: +** Name: Dead Drop Resolver +** ID: T1102.001 +** Reference URL: https://attack.mitre.org/techniques/T1102/001/ +* Sub-technique: +** Name: Bidirectional Communication +** ID: T1102.002 +** Reference URL: https://attack.mitre.org/techniques/T1102/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: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-fileless-execution-via-o-tmpfile.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-fileless-execution-via-o-tmpfile.asciidoc new file mode 100644 index 0000000000..dd9d564967 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-fileless-execution-via-o-tmpfile.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-33-potential-fileless-execution-via-o-tmpfile]] +=== Potential Fileless Execution via O_TMPFILE + +This rule identifies potential fileless ELF execution where a process is launched from an anonymous temporary executable path that appears as "/#" in "process.executable". This pattern may be associated with "O_TMPFILE" and "execveat" with "AT_EMPTY_PATH", which can allow execution without a normal filesystem pathname. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/MatheuZSecurity/Dntry +* https://matheuzsecurity.github.io/hacking/fileless-loader-bypassing-elastic-memfd/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Platform: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Rule Type: Event Correlation (EQL) +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* 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 Potential Fileless Execution via O_TMPFILE* + + +This rule detects Linux processes launched from anonymous temporary files created with O_TMPFILE, a pattern associated with execveat and AT_EMPTY_PATH execution that leaves no normal filesystem pathname. An attacker can write a malicious ELF payload into an unnamed file descriptor and execute it directly, reducing disk artifacts and making the payload harder to discover through routine file inspection. + + +*Possible investigation steps* + + +- Preserve volatile evidence from the live process by collecting its `/proc//exe`, file descriptors, memory maps, command line, environment, namespaces, and a hash or copy of the anonymous executable where policy permits. +- Reconstruct the full process ancestry and execution context, focusing on the initiating user, parent binary, container or service identity, privilege changes, and whether the chain originated from a shell, web service, or remote session. +- Correlate audit telemetry for the preceding `openat` or `openat2` call using `O_TMPFILE`, subsequent writes and permission changes, and the final `execveat` call using `AT_EMPTY_PATH`. +- Review nearby network, authentication, and endpoint activity for payload delivery, command-and-control connections, credential access, persistence creation, lateral movement, or additional spawned processes. +- Determine prevalence across hosts and compare hashes, ancestry, and execution context with approved software, escalating isolated or unsigned occurrences and containing affected systems when malicious behavior is confirmed. + + +*False positive analysis* + + +- Legitimate system or application software may use O_TMPFILE for secure temporary execution, so verify the process ancestry, executable hash, package ownership, and consistency with approved activity. +- Authorized software installation, update, or testing workflows may execute an anonymous ELF binary, so confirm the timing against approved changes and validate the initiating user, service, and expected recurrence across comparable hosts. + + +*Response and remediation* + + +- Isolate the affected Linux host or container from the network while preserving `/proc//exe`, open file descriptors, memory, and relevant audit logs for forensic analysis. +- Terminate the malicious process tree, revoke exposed credentials and active sessions, and block identified executable hashes, command-and-control destinations, and payload sources across the environment. +- Remove attacker persistence from systemd units, cron jobs, shell profiles, SSH `authorized_keys`, startup scripts, modified containers, and unauthorized accounts or packages. +- Escalate immediately to incident response if privileged execution, credential theft, command-and-control traffic, persistence, or activity on additional hosts is identified. +- Reimage compromised systems from known-good media, restore validated data, rotate affected secrets, patch the initial access vector, and verify that no anonymous executable or related attacker activity remains. +- Harden Linux endpoints by restricting unnecessary O_TMPFILE and `execveat` behavior through application allowlisting, SELinux or AppArmor policies, container controls, and enhanced auditing of anonymous-file execution. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.executable regex """.*/\#[0-9]+.*""" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-linux-hack-tool-launched.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-linux-hack-tool-launched.asciidoc new file mode 100644 index 0000000000..cd46a7cc24 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-linux-hack-tool-launched.asciidoc @@ -0,0 +1,242 @@ +[[prebuilt-rule-8-19-33-potential-linux-hack-tool-launched]] +=== Potential Linux Hack Tool Launched + +Monitors for the execution of different processes that might be used by attackers for malicious intent. An alert from this rule should be investigated further, as hack tools are commonly used by blue teamers and system administrators as well. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* 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*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 110 + +*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 Linux Hack Tool Launched* + + +Linux environments often utilize various tools for system administration and security testing. While these tools serve legitimate purposes, adversaries can exploit them for malicious activities, such as unauthorized access or data exfiltration. The detection rule identifies suspicious process executions linked to known hacking tools, flagging potential misuse by monitoring specific process names and actions indicative of exploitation attempts. + + +*Possible investigation steps* + + +- Review the process name and command-line arguments that triggered the alert to determine if they identify any known hacking tools listed in the query, such as "crackmapexec" or "sqlmap". +- Check the user account associated with the process execution to assess if it is a legitimate user or potentially compromised. +- Investigate the source and destination IP addresses involved in the process execution to identify any unusual or unauthorized network activity. +- Examine the command line arguments used during the process execution to understand the intent and scope of the activity. +- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities. +- Verify if the process execution aligns with any scheduled tasks or known administrative activities to rule out false positives. + + +*False positive analysis* + + +- System administrators and security teams often use tools like "john", "hashcat", and "hydra" for legitimate security testing and password recovery. To reduce false positives, create exceptions for these tools when used by authorized personnel or during scheduled security assessments. +- Blue team exercises may involve the use of exploitation frameworks such as "msfconsole" and "msfvenom". Implement a process to whitelist these activities when they are part of a sanctioned security drill. +- Network scanning tools like "zenmap" and "nuclei" are frequently used for network mapping and vulnerability assessments. Establish a baseline of normal usage patterns and exclude these from alerts when they match expected behavior. +- Web enumeration tools such as "gobuster" and "dirbuster" might be used by web developers for testing purposes. Coordinate with development teams to identify legitimate use cases and exclude these from triggering alerts. +- Regularly review and update the list of excluded processes to ensure that only non-threatening activities are exempted, maintaining a balance between security and operational efficiency. + + +*Response and remediation* + + +- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the alert, such as those listed in the detection query, to halt potential malicious activities. +- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or lateral movement attempts. +- Restore the affected system from a known good backup if any unauthorized changes or data exfiltration are confirmed. +- Update and patch all software and applications on the affected host to mitigate vulnerabilities that could be exploited by the identified tools. +- Implement stricter access controls and monitoring on the affected host to prevent unauthorized execution of potentially malicious tools in the future. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. + +==== 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 to select "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 in~ ( + // exploitation frameworks + "crackmapexec", "msfconsole", "msfvenom", "sliver-client", "sliver-server", "havoc", + // network scanners (nmap left out to reduce noise) + "zenmap", "nuclei", "netdiscover", "legion", + // web enumeration + "gobuster", "dirbuster", "dirb", "wfuzz", "ffuf", "whatweb", "eyewitness", + // web vulnerability scanning + "wpscan", "joomscan", "droopescan", "nikto", + // exploitation tools + "sqlmap", "commix", "yersinia", + // cracking and brute forcing + "john", "hashcat", "hydra", "ncrack", "cewl", "fcrackzip", "rainbowcrack", + // host and network + "linenum.sh", "linpeas.sh", "pspy32", "pspy32s", "pspy64", "pspy64s", "binwalk", "evil-winrm", + "linux-exploit-suggester-2.pl", "linux-exploit-suggester.sh", "panix.sh" + ) or + ( + process.name : "python*" and + process.args : ("*sqlmap.py", "*crackmapexec", "*commix.py") + ) or + ( + process.name : "ruby*" and process.args : "*wpscan" + ) or + ( + process.name in~ ("bash", "dash", "sh", "zsh", "ksh", "fish", "busybox") and + process.args : ("*linenum.sh*", "*linpeas.sh*", "*linux-exploit-suggester.sh*", "*panix.sh*") + ) or + ( + process.name : "perl*" and process.args : "*linux-exploit-suggester-2.pl" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Cracking +** ID: T1110.002 +** Reference URL: https://attack.mitre.org/techniques/T1110/002/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ +* Technique: +** Name: Process Discovery +** ID: T1057 +** Reference URL: https://attack.mitre.org/techniques/T1057/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* 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: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Vulnerability Scanning +** ID: T1595.002 +** Reference URL: https://attack.mitre.org/techniques/T1595/002/ +* Sub-technique: +** Name: Wordlist Scanning +** ID: T1595.003 +** Reference URL: https://attack.mitre.org/techniques/T1595/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-network-scan-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-network-scan-detected.asciidoc new file mode 100644 index 0000000000..0bcdf0b71d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-network-scan-detected.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-33-potential-network-scan-detected]] +=== Potential Network Scan Detected + +This rule identifies a potential port scan from an internal IP address. A port scan is a method utilized by attackers to systematically scan a target system for open ports, allowing them to identify available services and potential vulnerabilities. By mapping out the open ports, attackers can gather critical information to plan and execute targeted attacks, gaining unauthorized access, compromising security, and potentially leading to data breaches, unauthorized control, or further exploitation of the targeted system. This rule defines a threshold-based approach to detect connection attempts from a single internal source to a wide range of destination ports on a single destination. + +*Rule type*: esql + +*Rule indices*: None + +*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*: 5 + +*References*: None + +*Tags*: + +* Domain: Network +* Tactic: Discovery +* Tactic: Reconnaissance +* Use Case: Network Security Monitoring +* Data Source: PAN-OS +* Resources: Investigation Guide + +*Version*: 16 + +*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 Network Scan Detected* + + +Network scanning is a technique used to identify open ports and services on a network, often exploited by attackers to find vulnerabilities. Adversaries may use this method to map out a network's structure and identify weak points for further exploitation. The detection rule identifies suspicious activity by monitoring for multiple connection attempts from a single source to numerous destination ports, indicating a potential scan. This helps in early detection and mitigation of reconnaissance activities. + + +*Possible investigation steps* + + +- Review the source IP address involved in the alert to determine if it belongs to a known or trusted entity within the organization. Check if the IP falls within the specified ranges: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. +- Analyze the network flow logs to identify the specific destination ports that were targeted by the source IP. Determine if these ports are associated with critical services or known vulnerabilities. +- Correlate the detected activity with any recent changes or updates in the network infrastructure that might explain the scanning behavior, such as new devices or services being deployed. +- Investigate if there are any other alerts or logs indicating similar scanning activities from the same source IP or other IPs within the same subnet, which might suggest a coordinated scanning effort. +- Check for any historical data or past incidents involving the source IP to assess if this behavior is part of a recurring pattern or a new anomaly. +- Consult with network administrators to verify if the detected activity aligns with any scheduled network assessments or security tests that might have been conducted without prior notification. + + +*False positive analysis* + + +- Internal network scanning tools used for legitimate security assessments can trigger this rule. To manage this, create exceptions for known IP addresses of authorized scanning tools. +- Automated network monitoring systems that check service availability across multiple ports may be flagged. Exclude these systems by identifying their IP addresses and adding them to an exception list. +- Load balancers and network devices that perform health checks on various services might cause false positives. Identify these devices and configure the rule to ignore their IP addresses. +- Development and testing environments where frequent port scanning is part of routine operations can be mistakenly flagged. Implement exceptions for these environments by specifying their IP ranges. +- Regularly scheduled vulnerability assessments conducted by internal security teams can appear as network scans. Document these activities and exclude the associated IPs from triggering the rule. + + +*Response and remediation* + + +- Isolate the affected host: Immediately disconnect the source IP from the network to prevent further scanning or potential exploitation of identified vulnerabilities. +- Conduct a thorough investigation: Analyze the source IP's activity logs to determine if any unauthorized access or data exfiltration has occurred. This will help assess the extent of the threat. +- Update firewall rules: Implement stricter access controls to limit the number of open ports and restrict unnecessary inbound and outbound traffic from the affected IP range. +- Patch and update systems: Ensure all systems and services identified during the scan are up-to-date with the latest security patches to mitigate known vulnerabilities. +- Monitor for recurrence: Set up enhanced monitoring for the source IP and similar scanning patterns to quickly detect and respond to any future scanning attempts. +- Escalate to security operations: If the scan is part of a larger attack or if sensitive data is at risk, escalate the incident to the security operations team for further analysis and response. +- Review and enhance detection capabilities: Evaluate the effectiveness of current detection mechanisms and consider integrating additional threat intelligence sources to improve early detection of similar threats. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-network_traffic.*, packetbeat-*, logs-panw.panos* +| mv_expand event.action +| where event.action in ("network_flow", "flow_started") and destination.port is not null and source.ip is not null and destination.ip is not null +| eval Esql.time_window = DATE_TRUNC(1min, @timestamp) +| where CIDR_MATCH(source.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16") +| eval sensitive_port = case(destination.port IN (21, 22, 23, 53, 88, 139, 389, 445, 3389, 5900, 5985, 5986, 9389), true, false) +| stats + Esql.count_distinct_destination_ports = COUNT_DISTINCT(destination.port), + Esql.count_distinct_sensitive_ports = COUNT_DISTINCT(destination.port) where sensitive_port == true, + Esql.values_destination_ports = VALUES(destination.port), + Esql.values_sensitive_ports = VALUES(destination.port) where sensitive_port == true + by Esql.time_window, destination.ip, source.ip +| where (Esql.count_distinct_destination_ports >= 50 or Esql.count_distinct_sensitive_ports >= 5) +| keep source.ip, destination.ip, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Scanning IP Blocks +** ID: T1595.001 +** Reference URL: https://attack.mitre.org/techniques/T1595/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-ssh-brute-force-detected-via-macos-security-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-ssh-brute-force-detected-via-macos-security-events.asciidoc new file mode 100644 index 0000000000..02dc3e103d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-ssh-brute-force-detected-via-macos-security-events.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-33-potential-ssh-brute-force-detected-via-macos-security-events]] +=== Potential SSH Brute Force Detected via macOS Security Events + +Identifies a high number of failed inbound SSH authentication attempts on a macOS host within a short time window, using sshd authentication messages collected by the macOS Security Events integration. Adversaries may perform password brute force or password spraying against exposed SSH services to obtain unauthorized access. + +*Rule type*: esql + +*Rule indices*: None + +*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://themittenmac.com/detecting-ssh-activity-via-process-monitoring/ + +*Tags*: + +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: macOS Security Events +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential SSH Brute Force Detected via macOS Security Events* + + +On macOS, the `sshd-session` process logs every failed authentication attempt to the unified log (`Failed password for`, `Failed keyboard-interactive/pam for`, +`PAM: authentication error for`), and connections that probe a non-existent username end with `Connection closed by invalid user`. +This rule counts these failure messages per host and alerts when the number reaches the threshold within the rule window. +Successful authentications are not counted. The rule extracts the targeted usernames and source IP addresses from the message text and reports them in the alert as `Esql.user_name_values` +and `Esql.source_ip_values`, with distinct counts in `Esql.user_name_count` and `Esql.source_ip_count`. + + +*Possible investigation steps* + + +- Review `Esql.event_count`, `Esql.user_name_values`, and `Esql.source_ip_values` in the alert to identify how many +attempts occurred and which accounts and sources were involved. +- Use `Esql.user_name_count` and `Esql.source_ip_count` to characterize the activity: many usernames from one source +indicates password spraying, one username from one source indicates password guessing, and one username from many +sources indicates a distributed attack. Check whether the targeted usernames exist on the host. +- Check whether any `Accepted` message from `sshd-session` follows the failures in `logs-macos.authentication-*`, which +would indicate the attack succeeded. +- Determine whether the source IP addresses are internal or external and whether they are associated with known +infrastructure, scanners, or previous alerts. +- Determine whether Remote Login is expected to be enabled on this host (for example, build servers or developer +workstations). +- Correlate with other alerts or events from the same host during the same period. + + +*Related rules* + + +- Potential Successful SSH Brute Force Attack via macOS Security Events - f5898b1e-3071-4597-b066-43d298c7b415 + + +*False positive analysis* + + +- Automation or configuration management tooling with stale or rotated credentials can generate bursts of failures, +typically from a single known source IP address against a single service account. +- Security scanners or credential-validation health checks that test SSH authentication against known hosts. +- Internet-facing SSH services may receive high volumes of scanning or credential-stuffing traffic from unrelated +sources; consider network-level rate limiting or exclusions for known source addresses. +- Users repeatedly mistyping a password rarely reach the threshold within the window due to PAM's per-attempt delay, +but multiple parallel sessions from the same user can approach it. + + +*Response and remediation* + + +- Block or rate-limit the source IP addresses reported in `Esql.source_ip_values` at the network perimeter or on the +host. +- Verify no successful authentication followed the failures; if one did, treat the host as potentially compromised and +follow the response steps of the successful brute force rule. +- Reset credentials for the accounts reported in `Esql.user_name_values` if there is any indication they may be weak or +exposed. +- Review the host's SSH configuration: prefer key-based authentication, restrict access with `AllowUsers`/`AllowGroups`, +and disable Remote Login where it is not required. +- Escalate to the security operations team if additional hosts show similar patterns. + + +==== Setup + + + +*Setup* + + +This rule requires data from the macOS Security Events integration. +Integration setup instructions: https://www.elastic.co/docs/reference/security/prebuilt-rules/integration/macos/macos_security_events[macOS Security Events] +SSH authentication logging setup instructions: https://www.elastic.co/docs/reference/security/prebuilt-rules/integration/macos/macos_security_events_ssh_authentication[macOS Security Events: SSH Authentication] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-macos.authentication-* +| WHERE data_stream.dataset == "macos.authentication" and ( + macos.event.message.description LIKE "Failed password for*" or + macos.event.message.description LIKE "Failed keyboard-interactive/pam for*" or + macos.event.message.description LIKE "error: PAM: authentication error for*" or + macos.event.message.description LIKE "Connection closed by invalid user*" + ) +| GROK macos.event.message.description "for (invalid user )?%{NOTSPACE:Esql.user_name_attempt} from %{IP:Esql.source_ip_attempt}" +| GROK macos.event.message.description "closed by invalid user %{NOTSPACE:Esql.user_name_probe} %{IP:Esql.source_ip_probe}" +| EVAL Esql.user_name = COALESCE(Esql.user_name_attempt, Esql.user_name_probe), + Esql.source_ip = COALESCE(Esql.source_ip_attempt, Esql.source_ip_probe) +| STATS + Esql.event_count = COUNT(*), + Esql.user_name_values = VALUES(Esql.user_name), + Esql.user_name_count = COUNT_DISTINCT(Esql.user_name), + Esql.source_ip_values = VALUES(Esql.source_ip), + Esql.source_ip_count = COUNT_DISTINCT(Esql.source_ip) + BY host.id, host.name +| WHERE Esql.event_count >= 20 +| KEEP host.id, host.name, Esql.event_count, Esql.user_name_values, Esql.user_name_count, Esql.source_ip_values, Esql.source_ip_count + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-successful-ssh-brute-force-attack-via-macos-security-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-successful-ssh-brute-force-attack-via-macos-security-events.asciidoc new file mode 100644 index 0000000000..e4d4a31bd4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-successful-ssh-brute-force-attack-via-macos-security-events.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-33-potential-successful-ssh-brute-force-attack-via-macos-security-events]] +=== Potential Successful SSH Brute Force Attack via macOS Security Events + +Identifies a burst of failed inbound SSH authentication attempts on a macOS host followed shortly by a successful SSH authentication on the same host, using sshd authentication messages collected by the macOS Security Events integration. A successful login immediately after repeated failures indicates that a password brute force or password spraying attack against an exposed SSH service has likely succeeded. + +*Rule type*: eql + +*Rule indices*: + +* logs-macos.authentication-* + +*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://themittenmac.com/detecting-ssh-activity-via-process-monitoring/ + +*Tags*: + +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Initial Access +* Data Source: macOS Security Events +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Successful SSH Brute Force Attack via macOS Security Events* + + +SSH (Secure Shell) is a protocol used to securely access remote systems. On macOS, the `sshd-session` process logs each +failed authentication attempt (`Failed password for`, `Failed keyboard-interactive/pam for`, +`PAM: authentication error for`) and each successful one (`Accepted for from port `) to the +unified log. This rule alerts when ten or more failure messages on a host are followed within 15 seconds by an +`Accepted` message on the same host, indicating that a brute force or password spraying attack has likely succeeded. +The sequence is correlated per host; the source IP address and username are present in the message text and must be +read from the sequence events. + + +*Possible investigation steps* + + +- Review the `Accepted` event in the sequence and read its `macos.event.message.description.` field to identify the compromised username, the +source IP address and port, and the authentication method used. +- Compare the source IP address and usernames in the failure messages with the `Accepted` message to confirm the +success came from the same source and to determine whether one account or many were targeted. +- Determine whether the source IP address is internal or external and whether it is associated with known +infrastructure, scanners, or previous alerts. +- Verify whether the compromised account has administrative privileges or is a member of the `admin` group. +- Review process activity on the host after the successful login for discovery, persistence, or credential access +behavior, using Elastic Defend data if available. +- Review other alerts and events associated with the affected host and account during the past 48 hours. +- Determine whether Remote Login is expected to be enabled on this host and whether the account is expected to log in +over SSH. + + +*Related rules* + + +- Potential SSH Brute Force Detected via macOS Security Events - 3751cc17-6e7e-4356-86d5-c8f44aab9a28 + + +*False positive analysis* + + +- Automation or configuration management tooling that retries with stale credentials before succeeding with a valid one +can produce a burst of failures followed by a success. Verify the source and exclude known automation if expected. +- Because correlation is per host, an unrelated successful login within 15 seconds of a failure burst from another source +will match. Compare source IP addresses in the failure and `Accepted` messages to rule this out. +- A user with an expired or recently rotated password who retries repeatedly before succeeding. The 15-second window and +PAM's per-attempt delay make this unlikely from a single interactive session. +- Security scanners or credential-validation health checks that test SSH authentication against known hosts. + + +*Response and remediation* + + +- Treat the alert as a potential compromise: a successful login after repeated failures means the attacker likely holds +valid credentials for the host. +- Terminate active SSH sessions for the compromised account and isolate the host from the network if unauthorized +access is confirmed. +- Reset the password of the compromised account and any other accounts sharing the same credential; review the account +for unexpected privilege changes, SSH authorized keys, or persistence mechanisms such as launch agents or login items. +- Review commands executed in the session and on the host for follow-on activity, including data access, lateral +movement, or additional accounts created. +- Block or rate-limit the source IP address at the network perimeter or on the host, and review why the SSH service was +reachable from that source. +- Review and harden the host's SSH configuration: prefer key-based authentication, restrict access with +`AllowUsers`/`AllowGroups`, and disable Remote Login where it is not required. +- Search for similar sequences across other macOS hosts to determine whether the activity is part of a broader campaign. +- Escalate to the incident response team and update logging and detection coverage based on the findings. + + +==== Setup + + + +*Setup* + + +This rule requires data from the macOS Security Events integration. +Integration setup instructions: https://www.elastic.co/docs/reference/security/prebuilt-rules/integration/macos/macos_security_events[macOS Security Events] +SSH authentication logging setup instructions: https://www.elastic.co/docs/reference/security/prebuilt-rules/integration/macos/macos_security_events_ssh_authentication[macOS Security Events: SSH Authentication] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=15s + [authentication where event.dataset == "macos.authentication" and host.os.type == "macos" and + macos.event.message.description : ("Failed password for*", + "Failed keyboard-interactive/pam for*", + "error: PAM: authentication error for*")] with runs=10 + [authentication where event.dataset == "macos.authentication" and host.os.type == "macos" and + macos.event.message.description : "Accepted *"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* 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: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-syn-based-port-scan-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-syn-based-port-scan-detected.asciidoc new file mode 100644 index 0000000000..7153ee5ecf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-potential-syn-based-port-scan-detected.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-33-potential-syn-based-port-scan-detected]] +=== Potential SYN-Based Port Scan Detected + +This rule identifies a potential SYN-Based port scan. A SYN port scan is a technique employed by attackers to scan a target network for open ports by sending SYN packets to multiple ports and observing the response. Attackers use this method to identify potential entry points or services that may be vulnerable to exploitation, allowing them to launch targeted attacks or gain unauthorized access to the system or network, compromising its security and potentially leading to data breaches or further malicious activities. This rule defines a threshold-based approach to detect connection attempts from a single source to a large number of unique destination ports, while limiting the number of packets per port. + +*Rule type*: threshold + +*Rule indices*: + +* logs-network_traffic.* +* packetbeat-* +* filebeat-* +* logs-panw.panos* + +*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*: 5 + +*References*: None + +*Tags*: + +* Domain: Network +* Tactic: Discovery +* Tactic: Reconnaissance +* Use Case: Network Security Monitoring +* Data Source: PAN-OS +* Resources: Investigation Guide + +*Version*: 15 + +*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 SYN-Based Port Scan Detected* + + +SYN-based port scanning is a reconnaissance technique where attackers send SYN packets to multiple ports to identify open services. This method helps adversaries map network vulnerabilities for potential exploitation. The detection rule identifies such scans by flagging connection attempts from internal IPs to multiple ports with minimal packet exchange, indicating a low-risk reconnaissance activity. + + +*Possible investigation steps* + + +- Review the source IP address involved in the alert to determine if it belongs to a known or authorized device within the network. Check for any recent changes or unusual activity associated with this IP. +- Analyze the destination ports targeted by the scan to identify any patterns or specific services that may be of interest to the attacker. Determine if these ports are associated with critical or vulnerable services. +- Examine historical logs to identify any previous scanning activity from the same source IP or similar patterns of behavior. This can help establish whether the activity is part of a larger reconnaissance effort. +- Correlate the alert with other security events or alerts to assess if there is a broader attack campaign underway. Look for related alerts that might indicate subsequent exploitation attempts. +- Investigate the timing and frequency of the scan attempts to understand if they coincide with other suspicious activities or known attack windows. This can provide context on the attacker's intent and urgency. +- Assess the network's current security posture and ensure that appropriate defenses, such as firewalls and intrusion detection systems, are configured to mitigate potential exploitation of identified open ports. + + +*False positive analysis* + + +- Internal network scanning tools or scripts used by IT teams for legitimate network mapping can trigger this rule. To manage this, create exceptions for known internal IP addresses or subnets used by IT for network discovery. +- Automated monitoring systems or security appliances that perform regular port checks might be flagged. Identify these systems and exclude their IP addresses from the rule to prevent false positives. +- Software updates or patch management systems that check multiple ports for service availability can be mistaken for a SYN-based port scan. Whitelist these systems to avoid unnecessary alerts. +- Load balancers or network devices that perform health checks across multiple ports may trigger the rule. Exclude these devices from the rule to ensure accurate detection. +- Development or testing environments where multiple port scans are part of routine operations can cause false positives. Implement exceptions for these environments to maintain focus on genuine threats. + + +*Response and remediation* + + +- Isolate the affected internal IP address to prevent further reconnaissance or potential exploitation of identified open ports. +- Conduct a thorough review of firewall and network access control lists to ensure that only necessary ports are open and accessible from internal networks. +- Implement rate limiting on SYN packets to reduce the risk of successful port scanning and reconnaissance activities. +- Monitor the network for any unusual outbound traffic from the affected IP address, which may indicate further malicious activity or data exfiltration attempts. +- Escalate the incident to the security operations team for further analysis and to determine if additional network segments or systems are affected. +- Update intrusion detection and prevention systems to enhance detection capabilities for similar SYN-based port scanning activities. +- Review and update network segmentation policies to limit the exposure of critical services and systems to internal reconnaissance activities. + +==== Rule query + + +[source, js] +---------------------------------- +event.action:(network_flow or flow_started) and destination.port:* and network.packets <= 2 and source.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Scanning IP Blocks +** ID: T1595.001 +** Reference URL: https://attack.mitre.org/techniques/T1595/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-protected-storage-service-access-via-smb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-protected-storage-service-access-via-smb.asciidoc new file mode 100644 index 0000000000..bbd36ef761 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-protected-storage-service-access-via-smb.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-33-protected-storage-service-access-via-smb]] +=== Protected Storage Service Access via SMB + +Identifies remote access to the Windows Protected Storage Service through the IPC$ share. Attackers may abuse this named pipe to interact with the Protected Storage Service and extract sensitive credentials, certificates, or DPAPI backup keys. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*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://threathunterplaybook.com/hunts/windows/190620-DomainDPAPIBackupKeyExtraction/notebook.html +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Protected Storage Service Access via SMB* + + +The Protected Storage Service manages sensitive user data such as passwords, certificates, and private keys. Remote +access to the `protected_storage` named pipe over the IPC$ share is unusual and may indicate an attempt to extract +credentials or abuse DPAPI to retrieve domain backup keys from domain controllers. + + +*Possible investigation steps* + + +- Identify the source system and user account that initiated the access by reviewing `source.ip`, `user.name`, and + `winlog.event_data.SubjectUserName`. +- Determine whether the target host is a domain controller or other high-value system that stores DPAPI backup keys. +- Review authentication events (4624, 4625) around the alert time to identify how the source authenticated to the + target. +- Investigate other alerts associated with the source host or user during the past 48 hours. +- Check for follow-on credential access activity such as registry hive access, LSASS access, or lateral movement. + + +*False positive analysis* + + +- This activity is rarely expected in most environments. If legitimate administrative tooling accesses this pipe, + confirm the source, account, and target system before adding an exception. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the source host if unauthorized access is confirmed. +- Investigate credential exposure and reset passwords for potentially compromised accounts. +- Review domain controller DPAPI backup key exposure if the target is a domain controller. + + +==== Setup + + + +*Setup* + + +Audit Detailed File Share must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-detailed-file-share + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:file and event.code:5145 and + winlog.event_data.ShareName:"\\\\*\\IPC$" and + winlog.event_data.RelativeTargetName:"protected_storage" and + not source.ip:("::" or "::1" or "0.0.0.0" or "127.0.0.1") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Private Keys +** ID: T1552.004 +** Reference URL: https://attack.mitre.org/techniques/T1552/004/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-proxy-execution-via-console-window-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-proxy-execution-via-console-window-host.asciidoc new file mode 100644 index 0000000000..b08ca7c874 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-proxy-execution-via-console-window-host.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-33-proxy-execution-via-console-window-host]] +=== Proxy Execution via Console Window Host + +Identifies abuse of the Console Window Host (conhost.exe) to execute commands via proxy. This behavior is used as a defense evasion technique to blend-in malicious activity with legitimate Windows software. + +*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-* + +*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://lolbas-project.github.io/lolbas/Binaries/Conhost/ + +*Tags*: + +* 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 +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Proxy Execution via Console Window Host* + + + +*Possible investigation steps* + + +- What command did the headless conhost instance proxy? + - Why: `--headless` can hide the child window behind conhost, so command intent and child-process evidence outweigh conhost identity alone. + - Focus: `process.command_line` for `--headless` and the proxied family: shell, script host, retrieval, UNC, caret-escaped, batch, or scheduled-task action. + - Implication: escalate when headless conhost proxies script execution, remote retrieval, scheduled-task changes, or lateral-path commands; lower suspicion only when command, launcher, user, and host match remote-admin console management, deployment automation, or installer/update helper use and later process evidence does not contradict it. +- Is this the native conhost binary or a masqueraded copy? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`; compare the path with `C:\Windows\System32\conhost.exe`. + - Implication: escalate when conhost is renamed, unsigned, user-writable, host-new by hash, or signed by an unexpected publisher; native signed identity lowers masquerade concern but not suspicious `--headless` proxy execution. +- Which launcher produced headless conhost? + - Focus: `process.parent.executable`, `process.parent.command_line`, and `process.parent.entity_id`. + - Implication: escalate when the launcher is Office, a browser, a script host, a temp or user-writable binary, another LOLBin, or a remote-management tool outside its console-management pattern; lower suspicion when the same parent is a stable console, deployment, or update path for the same `user.id` and `host.id`. +- Do the user and session context fit the same admin or deployment use? + - Focus: `user.id`, `host.id`, `process.Ext.session_info.logon_type`, and `process.Ext.authentication_id`. + - Implication: escalate when session type, account, or authentication ID is unusual for that `host.id` and user cohort or ties to unrelated suspicious processes; lower suspicion when user, host cohort, session type, command, and lineage match the same remote-admin, deployment, or update use. +- Did headless conhost spawn the command family named in the alert? + - Focus: child process starts on `host.id` where `process.parent.entity_id` matches alert `process.entity_id`; read `process.name`, `process.executable`, and `process.command_line`. !{investigate{"description":"","label":"Child process starts from the same conhost instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.entity_id` is absent, query the same `host.id` with alert `process.pid` in a tight alert-time window; treat matches as weaker because PID reuse is possible. + - Implication: escalate when conhost spawns shell, script-host, downloader, scheduled-task, or payload-like children; keep scope local only when no child execution appears and earlier evidence fits the same named admin, deployment, or update use. +- If local evidence is suspicious or unresolved, is this isolated or broader proxy execution? + - Focus: process-start history for the same `host.id` and, if needed, `user.id`; compare `process.command_line`, `process.parent.executable`, and child-process patterns. + - !{investigate{"description":"","label":"Process history on the same host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Process history for the same user","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: review related alerts for the same `host.id` and `user.id`, especially script execution, downloader, scheduled-task, credential-tool, or other proxy-execution activity. + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when the same host or user shows repeated headless conhost proxy execution, suspicious launchers, or related script, downloader, scheduled-task, or credential-tool processes; lack of history does not clear suspicious command, lineage, session, or child-process evidence. + +- Escalate on unauthorized headless proxy execution plus suspicious identity, launcher, session, child-process, or repeat-alert corroboration; close only when command, identity, lineage, session, and child-process evidence bind to one named benign use case below; preserve evidence and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Remote-administration, console-management, deployment automation, installer, or update agents can launch headless conhost when a named tool uses console helpers. Confirm that native `process.executable`, stable `process.parent.executable`, `process.parent.code_signature.subject_name`, `process.parent.code_signature.trusted`, parent and child `process.command_line`, `user.id`, `host.id`, `process.Ext.session_info.logon_type`, and child-process pattern all align with that tool or product path. Tool inventories, change records, or owner confirmation can corroborate telemetry-backed use, but should not replace missing or contradictory process evidence. If command, parent, session, or child evidence diverges, or the first cohort event includes retrieval, UNC, script-host, or scheduled-task behavior outside that path, treat it as unresolved or suspicious. +- Before creating an exception, verify that native `process.executable`, parent identity, exact `process.command_line`, `user.id`, `host.id`, and session type recur across prior alerts from this rule. Build the exception from that confirmed workflow pattern; avoid exceptions on `process.name`, the conhost filename, or `--headless` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the command intent, native conhost identity, parent lineage, `user.id`, `host.id`, session type, and child-process evidence that justified closure. Create an exception only when that same admin, deployment, or update pattern recurs consistently across prior alerts. +- If suspicious but unconfirmed, preserve the alert, process tree export, command lines, hash and signer details, `process.entity_id`, `process.parent.entity_id`, `process.Ext.authentication_id`, child-process events, and any scripts or task definitions named in the command line before containment. Apply reversible containment first, such as heightened monitoring or temporary restrictions on the affected `user.id`, `host.id`, or parent tool, and avoid process termination until scope is clearer. +- If confirmed malicious, contain the host or affected account when command intent, launcher lineage, session context, or child-process evidence establishes unauthorized proxy execution. Record the process identifiers, command lines, signer and hash evidence, user and host anchors, and child-process chain before terminating processes, deleting scripts, disabling scheduled tasks, or isolating accounts. +- Eradicate only the scripts, task definitions, copied tools, or persistence mechanisms identified during the investigation, then remediate the launcher, automation path, or access path that allowed headless conhost to proxy the command. +- Rotate credentials only when the user and session evidence or adjacent case evidence confirms account misuse, remote abuse, or privileged account compromise; otherwise keep identity action proportional to the confirmed process evidence. +- After containment, scope other hosts and users for the same `process.command_line`, `process.parent.executable`, `process.hash.sha256`, parent signer, or child-process pattern. Retain the process telemetry and response notes needed to distinguish repeat benign console automation from repeat proxy execution. + + +==== 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/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- 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] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "conhost.exe" and process.args : "--headless" and + process.command_line : ( + "*powershell*", "*cmd *", "*cmd.exe *", "*script*", "*mshta*", "*curl *", "*curl.exe *", "*^*^*^*", + "*.bat*", "*.cmd*", "*schtasks*", "*@SSL*", "*http*", "* \\\\*", "*.vbs*", "*.js*", "*mhsta*" + ) and + not ( + /* Winget-AutoUpdate via ServiceUI */ + ?process.parent.executable : "?:\\Program Files\\winget-autoupdate*\\serviceui.exe" or + /* Winget-AutoUpdate notification via Task Scheduler */ + ( + ?process.parent.executable : "?:\\Windows\\System32\\svchost.exe" and ?process.parent.args : "-s" and + ?process.parent.args : "Schedule" and process.command_line : "*WAU-Notify.ps1*" + ) or + /* Windows OpenSSH console host — SSH-specific detection handled by 8cd49fbc-a35a-4418-8688-133cc3a1e548 */ + ?process.parent.executable : ( + "?:\\Windows\\System32\\OpenSSH\\sshd.exe", + "?:\\Windows\\System32\\OpenSSH\\sshd-session.exe", + "?:\\Program Files\\OpenSSH*\\sshd.exe", + "?:\\Program Files\\OpenSSH*\\sshd-session.exe" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-remote-file-download-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-remote-file-download-via-powershell.asciidoc new file mode 100644 index 0000000000..ca8c2faa22 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-remote-file-download-via-powershell.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-33-remote-file-download-via-powershell]] +=== Remote File Download via PowerShell + +Identifies PowerShell being used to download an executable file from an untrusted remote destination. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 117 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Remote File Download via PowerShell* + + +Attackers commonly transfer tooling or malware from external systems into a compromised environment using the command and control channel. However, they can also abuse signed utilities to drop these files. + +PowerShell is one of system administrators' main tools for automation, report routines, and other tasks. This makes it available for use in various environments and creates an attractive way for attackers to execute code and perform actions. This rule correlates network and file events to detect downloads of executable and script files performed using PowerShell. + +> **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 the https://www.elastic.co/guide/en/security/current/interactive-investigation-guides.html[Investigate Markdown Plugin] introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Evaluate whether the user needs to use PowerShell to complete tasks. +- Investigate other alerts associated with the user/host during the past 48 hours. + - !{investigate{"label":"Alerts associated with the user in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"label":"Alerts associated with the host in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.name","queryType":"phrase","value":"{{host.name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} +- Check the reputation of the domain or IP address used to host the downloaded file. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - !{investigate{"label":"Investigate the Subject Process Network Events","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]]}} + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- Administrators can use PowerShell legitimately to download executable and script files. Analysts can dismiss the alert if the Administrator is aware of the activity and the triage has not identified suspicious or malicious files. + + +*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. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule 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 + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=30s +[network where host.os.type == "windows" and + process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and + network.protocol == "dns" and + not dns.question.name : ( + "*.microsoft.com", "*.azureedge.net", "*.powershellgallery.com", "*.windowsupdate.com", + "metadata.google.internal", "dist.nuget.org", "artifacts.elastic.co", "*.digicert.com", + "*.chocolatey.org", "outlook.office365.com", "cdn.oneget.org", "ci.dot.net", + "packages.icinga.com", "login.microsoftonline.com", "*.gov", "*.azure.com", "*.python.org", + "dl.google.com", "sensor.cloud.tenable.com", "*.azurefd.net", "*.office.net", "*.anac*", + "aka.ms", "dot.net", "*.visualstudio.com", "*.local") and + not user.id == "S-1-5-18" and + /* Filter out NetBIOS/LLMNR-style names (e.g. host, localhost, etc.) */ + dns.question.name regex """.*\.[a-zA-Z]{2,5}"""] +[file where host.os.type == "windows" and event.type == "creation" and + process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and + (file.extension : ("exe", "dll", "ps1", "bat", "cmd", "vbs", "vbe", "js", "jse", "wsh", "wsf", "sct", "hta", "cpl", "scr", "pif", "com") or file.Ext.header_bytes : "4d5a*") and + not file.name : "__PSScriptPolicy*.ps1" and + not file.path : ( + "?:\\Users\\*\\AppData\\Local\\Temp\\????????.dll", + "?:\\Users\\*\\AppData\\Local\\Temp\\*\\????????.dll", + "?:\\Windows\\TEMP\\ansible-tmp-*\\AnsiballZ*.ps1" + ) and + not user.id == "S-1-5-18"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-remote-management-access-launch-after-msi-install.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-remote-management-access-launch-after-msi-install.asciidoc new file mode 100644 index 0000000000..69f89fbd92 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-remote-management-access-launch-after-msi-install.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-33-remote-management-access-launch-after-msi-install]] +=== Remote Management Access Launch After MSI Install + +Detects an MSI installer execution followed by the execution of commonly abused Remote Management Software like ScreenConnect. This behavior may indicate abuse where an attacker triggers an MSI install then connects via a guest link with a known session key. + +*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.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1219/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Windows Security Event Logs +* Data Source: Elastic Endgame + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Remote Management Access Launch After MSI Install* + + +This rule fires when the same host runs msiexec with an install argument (/i) and within one minute starts a pre-configured RMM software. + + +*Possible investigation steps* + + +- Confirm the sequence on the host: first event should be msiexec.exe with process.args containing "/i"; second should be a remote management software. +- Review the source of the MSI file using file events. +- Check whether use of RMM software is approved for this host. +- Check network events to validate which remote host the RMM software connects to. +- Correlate with other alerts for the same host (initial access, persistence, C2). + + +*False positive analysis* + + +- Legitimate IT/MSP deployment of RMM for support. + + +*Response and remediation* + + +- If unauthorized RMM use or abuse is confirmed: isolate the host, terminate the ScreenConnect client, remove or block the installation, and investigate how the MSI was delivered and who operates the relay. + + +==== 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/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- 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] +---------------------------------- +sequence by host.id with maxspan=1m + [process where host.os.type == "windows" and event.type == "start" and process.name : "msiexec.exe" and + process.args : ("/i*", "-i*") and process.parent.name : ("explorer.exe", "sihost.exe", "powershell.exe", "cmd.exe")] + [process where host.os.type == "windows" and event.type == "start" and + ( + (process.name : "ScreenConnect.ClientService.exe" and process.command_line : "*?e=Access&y=Guest&h*&k=*") or + (process.name : "Syncro.Installer.exe" and process.args : "--config-json" and process.args : "--key") or + process.name : ("tvnserver.exe", "winvnc.exe") + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Sub-technique: +** Name: Remote Desktop Software +** ID: T1219.002 +** Reference URL: https://attack.mitre.org/techniques/T1219/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-rpc-remote-procedure-call-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-rpc-remote-procedure-call-to-the-internet.asciidoc new file mode 100644 index 0000000000..f9629cf83a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-rpc-remote-procedure-call-to-the-internet.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-33-rpc-remote-procedure-call-to-the-internet]] +=== RPC (Remote Procedure Call) to the Internet + +This rule detects network events that may indicate the use of RPC traffic to the Internet. RPC is commonly used by system administrators to remotely control a system for maintenance or to use shared resources. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.* +* logs-panw.panos* +* logs-fortinet_fortigate.log-* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Tactic: Initial Access +* Tactic: Lateral Movement +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: Corelight +* Data Source: Fortinet +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek +* Resources: Investigation Guide + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating RPC (Remote Procedure Call) to the Internet* + + +RPC enables remote management and resource sharing across networks, crucial for system administration. However, when exposed to the Internet, it becomes a target for attackers seeking initial access or backdoor entry. The detection rule identifies suspicious RPC traffic from internal IPs to external networks, flagging potential exploitation attempts by monitoring specific ports and IP ranges. + + +*Possible investigation steps* + + +- Review the source IP address from the alert to identify the internal system initiating the RPC traffic. Check if this IP belongs to a known or authorized device within the network. +- Examine the destination IP address to determine if it is a known or suspicious external entity. Use threat intelligence sources to assess if the IP has been associated with malicious activity. +- Analyze the network traffic logs for the specific event.dataset values (network_traffic.flow or zeek.dce_rpc) to gather more context about the nature and volume of the RPC traffic. +- Investigate the destination port, specifically port 135, to confirm if the traffic is indeed RPC-related and assess if there are any legitimate reasons for this communication. +- Check for any recent changes or anomalies in the network configuration or system settings of the source IP that might explain the unexpected RPC traffic. +- Correlate this alert with other security events or logs to identify any patterns or additional indicators of compromise that might suggest a broader attack campaign. + + +*False positive analysis* + + +- Internal testing environments may generate RPC traffic to external IPs for legitimate purposes. Identify and document these environments, then create exceptions in the detection rule to prevent unnecessary alerts. +- Cloud-based services or applications that require RPC communication for integration or management might trigger false positives. Review these services and whitelist their IP addresses if they are verified as non-threatening. +- VPN or remote access solutions that use RPC for secure connections can be mistaken for suspicious activity. Ensure that the IP ranges of these solutions are excluded from the rule to avoid false alerts. +- Automated backup or synchronization tools that use RPC to communicate with external servers could be flagged. Verify these tools and add their destination IPs to an exception list if they are part of routine operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough analysis of the affected system to identify any unauthorized changes or installed backdoors, focusing on processes and services related to RPC. +- Revoke any compromised credentials and enforce a password reset for all accounts that may have been accessed or used during the incident. +- Apply necessary patches and updates to the affected system and any other systems with similar vulnerabilities to mitigate the risk of exploitation. +- Monitor network traffic for any signs of lateral movement or additional suspicious activity, particularly focusing on RPC-related traffic. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced logging and monitoring for RPC traffic to detect and respond to similar threats more effectively in the future. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset:(fortinet_fortigate.log or network_traffic.flow) or event.category:(network or network_traffic)) and + network.transport:tcp and (destination.port:135 or data_stream.dataset:zeek.dce_rpc) and + source.ip:( + 10.0.0.0/8 or + 172.16.0.0/12 or + 192.168.0.0/16 + ) and + not destination.ip:( + 10.0.0.0/8 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.2.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.168.0.0/16 or + 192.88.99.0/24 or + 224.0.0.0/4 or + 100.64.0.0/10 or + 192.175.48.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Distributed Component Object Model +** ID: T1021.003 +** Reference URL: https://attack.mitre.org/techniques/T1021/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-suricata-and-elastic-defend-network-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-suricata-and-elastic-defend-network-correlation.asciidoc new file mode 100644 index 0000000000..294dca7853 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-suricata-and-elastic-defend-network-correlation.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-33-suricata-and-elastic-defend-network-correlation]] +=== Suricata and Elastic Defend Network Correlation + +This detection correlates Suricata alerts with Elastic Defend network events to identify the source process performing the network activity. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* filebeat-* +* 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*: + +* https://attack.mitre.org/tactics/TA0011/ +* https://www.elastic.co/docs/reference/integrations/suricata +* https://www.elastic.co/docs/reference/integrations/endpoint + +*Tags*: + +* Domain: Endpoint +* Domain: Network +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Suricata +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suricata and Elastic Defend Network Correlation* + + + +*Possible investigation steps* + + +- Investigate in the Timeline feature the two events matching this correlation (Suricata and Elastic Defend). +- Review the process details like command_line, privileges, global relevance and reputation. +- Assess the destination.ip reputation and global relevance. +- Review the parent process execution details like command_line, global relevance and reputation. +- Examine all network connection details performed by the process during last 48h. +- Correlate the alert with other security events or logs to identify any patterns or additional indicators of compromise related to the same process or network activity. + + +*False positive analysis* + + +- Trusted system or third party processes performing network activity that looks like beaconing. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the suspicious processes and all associated children and parents. +- Implement network-level controls to block traffic to the destination.ip. +- Conduct a thorough review of the system's configuration files to identify unauthorized changes. +- Reset credentials for any accounts associated with the source machine. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by source.port, source.ip, destination.ip with maxspan=5s + [network where data_stream.dataset == "suricata.eve" and event.kind == "alert" and + event.severity != 3 and source.ip != null and destination.ip != null and + not rule.name in ("ET INFO SMB2 NT Create AndX Request For a Powershell .ps1 File", "ET SCAN MS Terminal Server Traffic on Non-standard Port")] + [network where event.module == "endpoint" and event.action in ("disconnect_received", "connection_attempted") and + not process.executable in ("System", "C:\\Program Files (x86)\\Admin Arsenal\\PDQ Inventory\\PDQInventoryService.exe") and + not process.executable : "C:\\Windows\\AdminArsenal\\PDQInventory-Scanner\\service-*\\exec\\PDQInventoryScanner.exe"] + +---------------------------------- + +*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/ +* Technique: +** Name: Non-Standard Port +** ID: T1571 +** Reference URL: https://attack.mitre.org/techniques/T1571/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-system-v-init-script-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-system-v-init-script-created.asciidoc new file mode 100644 index 0000000000..24928d6385 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-system-v-init-script-created.asciidoc @@ -0,0 +1,229 @@ +[[prebuilt-rule-8-19-33-system-v-init-script-created]] +=== System V Init Script Created + +Files that are placed in the "/etc/init.d/" directory in Unix can be used to start custom applications, services, scripts or commands during start-up. Init.d has been mostly replaced in favor of Systemd. However, the "systemd-sysv-generator" can convert init.d files to service unit files that run at boot. Adversaries may add or alter files located in the "/etc/init.d/" directory to execute malicious code upon boot in order to gain persistence on the system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.intezer.com/blog/malware-analysis/hiddenwasp-malware-targeting-linux-systems/ +* https://pberba.github.io/security/2022/02/06/linux-threat-hunting-for-persistence-initialization-scripts-and-shell-configuration/#8-boot-or-logon-initialization-scripts-rc-scripts +* https://www.cyberciti.biz/faq/how-to-enable-rc-local-shell-script-on-systemd-while-booting-linux-system/ +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: SentinelOne + +*Version*: 120 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating System V Init Script Created* + + +The `/etc/init.d` directory is used in Linux systems to store the initialization scripts for various services and daemons that are executed during system startup and shutdown. + +Attackers can abuse files within the `/etc/init.d/` directory to run scripts, commands or malicious software every time a system is rebooted by converting an executable file into a service file through the `systemd-sysv-generator`. After conversion, a unit file is created within the `/run/systemd/generator.late/` directory. + +This rule looks for the creation of new files within the `/etc/init.d/` directory. Executable files in these directories will automatically run at boot with root privileges. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + +*Possible Investigation Steps* + + +- Investigate the file that was created or modified. + - !{osquery{"label":"Osquery - Retrieve File Information","query":"SELECT * FROM file WHERE path = {{file.path}}"}} +- Investigate whether any other files in the `/etc/init.d/` or `/run/systemd/generator.late/` directories have been altered. + - !{osquery{"label":"Osquery - Retrieve File Listing Information","query":"SELECT * FROM file WHERE path LIKE '/etc/init.d/%'"}} + - !{osquery{"label":"Osquery - Retrieve Additional File Listing Information","query":"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE path LIKE '/etc/init.d/%' OR path LIKE '/etc/init/%' OR path IN ('/etc/init', '/etc/inittab', '/etc/inittab2')\n\n"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate syslog through the `sudo cat /var/log/syslog | grep 'LSB'` command to find traces of the LSB header of the script (if present). If syslog is being ingested into Elasticsearch, the same can be accomplished through Kibana. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate whether this activity is related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} + + +*False Positive Analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator who uses init.d for administrative purposes, consider adding exceptions for this specific administrator user account. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Related Rules* + + +- Suspicious File Creation in /etc for Persistence - 1c84dd64-7e6c-4bad-ac73-a5014ee37042 + + +*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. +- Delete the maliciously created service/init.d files or restore it to the original configuration. +- 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] +---------------------------------- +file where host.os.type == "linux" and event.action in ("creation", "file_create_event", "rename", "file_rename_event") +and file.path like ("/etc/init.d/*", "/etc/init/*", "/etc/init", "/etc/inittab*") and +not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", "./envbuilder/bin/envbuilder", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", "/opt/puppetlabs/puppet/bin/ruby", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "./usr/bin/podman", "/usr/lib/systemd/systemd", + "/usr/bin/buildah", "/dev/.buildkit_qemu_emulator", "/usr/lib/nvidia/post-install", "/usr/bin/dnf5", "/usr/sbin/yum-cron" + ) or + file.extension in ("swp", "swpx", "swx", "dpkg-remove", "dpkg-new") or + ?file.Ext.original.name like "*.dpkg-new" or + file.path like ("/etc/init.d/*beat*", "/etc/init.d/elastic-agent*") or + process.executable like ( + "/nix/store/*", "/var/lib/dpkg/*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*", "/var/lib/docker/overlay2/*/dockerd ", + "/var/lib/containers/storage/overlay/*/dockerd" + ) or + process.name in ("docker-init", "jumpcloud-agent", "crio") or + process.executable == null or + process.name in ("executor", "univention-config-registry", "install", "dockerd-entrypoint.sh", "platform-python*", "ssm-agent-worker") or + (process.name == "ln" and file.path : "/etc/init.d/rc*.d/*") or + (process.name == "sed" and file.name : "sed*") or + (process.name == "perl" and file.name : "e2scrub_all.tmp*") or + (process.name == "cp" and file.path == "/etc/init.d/unified-monitoring-agent") or + (process.name == "./vmware-install.pl" and file.path == "/etc/init.d/vmware-tools") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-unusual-network-connection-to-suspicious-web-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-unusual-network-connection-to-suspicious-web-service.asciidoc new file mode 100644 index 0000000000..22980cf3cc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-unusual-network-connection-to-suspicious-web-service.asciidoc @@ -0,0 +1,243 @@ +[[prebuilt-rule-8-19-33-unusual-network-connection-to-suspicious-web-service]] +=== Unusual Network Connection to Suspicious Web Service + +This rule monitors for the unusual occurrence of outbound network connections to suspicious webservice domains. + +*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://specterops.io/blog/2026/01/30/weaponizing-whitelists-an-azure-blob-storage-mythic-c2-profile/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* 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 Unusual Network Connection to Suspicious Web Service* + + +In macOS environments, network connections to web services are routine for data sharing and collaboration. However, adversaries exploit these services for command and control by disguising malicious traffic as legitimate. The detection rule identifies unusual outbound connections to known suspicious domains, flagging potential misuse by monitoring specific domain patterns and connection events, thus aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the destination domain and process executable from the alert to determine if it matches any expected web service communication. +- Check the event.category and event.type fields to confirm the nature of the network connection and ensure it aligns with the expected behavior of a macOS system. +- Investigate the source host identified by host.os.type to gather information about its recent activities, installed applications, and any potential indicators of compromise. +- Analyze network traffic logs for the source host to identify any other unusual or suspicious outbound connections that may indicate a broader compromise. +- Correlate the alert with other security events or alerts from the same host or network segment to identify patterns or related incidents. +- Consult threat intelligence sources to gather additional context on the flagged domain and assess its reputation and history of malicious activity. + + +*False positive analysis* + + +- Frequent access to legitimate cloud storage services like Google Drive or Dropbox for routine file sharing can trigger false positives. Users can create exceptions for specific domains or IP addresses known to be safe and frequently accessed by their organization. +- Automated backup services that use domains such as OneDrive or SharePoint may be flagged. To mitigate this, identify and whitelist the specific services or applications that are part of regular backup operations. +- Collaboration tools like Slack or Discord, used for legitimate communication, might be mistakenly flagged. Users should review and whitelist these domains if they are part of standard business operations. +- URL shorteners like bit.ly or tinyurl.com used in marketing or communication campaigns can cause false alerts. Establish a list of trusted shortener services and exclude them from monitoring if they are regularly used by the organization. +- Development and testing environments using services like ngrok or localtunnel for temporary public URLs can be misidentified. Ensure these environments are documented and excluded from the rule if they are part of normal development workflows. + + +*Response and remediation* + + +- Immediately isolate the affected macOS device from the network to prevent further communication with the suspicious domains. +- Conduct a thorough review of the network logs to identify any data exfiltration attempts or additional suspicious connections originating from the isolated device. +- Remove any unauthorized or suspicious applications or scripts found on the device that may be facilitating the outbound connections. +- Update the device's security software and perform a full system scan to detect and remove any malware or unauthorized software. +- Reset credentials and review access permissions for the affected user accounts to prevent unauthorized access. +- Monitor the network for any further attempts to connect to the flagged domains and ensure that alerts are configured to notify security teams of any recurrence. +- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to determine if the threat is part of a larger attack campaign. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category : "network" and host.os.type : "macos" and event.type : "start" and +destination.domain : ( + pastebin.* or + paste.ee or + ghostbin.com or + drive.google.com or + ?.docs.live.net or + api.dropboxapi.* or + content.dropboxapi.* or + *dl.dropboxusercontent.* or + api.onedrive.com or + *.onedrive.org or + onedrive.live.com or + filebin.net or + *.ngrok.io or + ngrok.com or + *.portmap.* or + *serveo.net or + *localtunnel.me or + *pagekite.me or + *localxpose.io or + *notabug.org or + rawcdn.githack.* or + paste.nrecom.net or + zerobin.net or + controlc.com or + requestbin.net or + api.slack.com or + slack-redir.net or + slack-files.com or + cdn.discordapp.com or + discordapp.com or + discord.com or + apis.azureedge.net or + cdn.sql.gg or + ?.top4top.io or + top4top.io or + uplooder.net or + *.cdnmegafiles.com or + transfer.sh or + updates.peer2profit.com or + api.telegram.org or + t.me or + meacz.gq or + rwrd.org or + *.publicvm.com or + *.blogspot.com or + api.mylnikov.org or + script.google.com or + script.googleusercontent.com or + paste4btc.com or + workupload.com or + temp.sh or + filetransfer.io or + gofile.io or + store?.gofile.io or + tiny.one or + api.notion.com or + *.sharepoint.com or + *upload.ee or + bit.ly or + t.ly or + cutt.ly or + mbasic.facebook.com or + api.gofile.io or + file.io or + api.anonfiles.com or + api.trello.com or + gist.githubusercontent.com or + dpaste.com or + *azurewebsites.net or + *.zulipchat.com or + *.4shared.com or + filecloud.me or + i.ibb.co or + files.catbox.moe or + *.getmyip.com or + mockbin.org or + webhook.site or + run.mocky.io or + *infinityfreeapp.com or + free.keep.sh or + tinyurl.com or + ftpupload.net or + lobfile.com or + *.ngrok-free.app or + myexternalip.com or + yandex.ru or + *.yandex.ru or + *.aternos.me or + cdn??.space or + *.pcloud.com or + mediafire.zip or + urlz.fr or + rentry.co or + *.b-cdn.net or + pastecode.dev or + i.imgur.com or + the.earth.li or + *.trycloudflare.com or + *.blob.core.windows.net or + *.blob.storage.azure.net +) and +not (destination.domain : (*.sharepoint.com or *.azurewebsites.net or "onedrive.live.com" or *.b-cdn.net or api.onedrive.com or "drive.google.com" or *.blogspot.com or *.blob.core.windows.net or *.blob.storage.azure.net) and process.code_signature.subject_name:(*Microsoft* or "Software Signing" or "Apple Mac OS Application Signing" or *VMware*) and process.code_signature.trusted:true) and +not (process.code_signature.subject_name:(*Mozilla* or *Google* or *Brave* or *Opera* or "Software Signing" or "macOS Software Signing" or *Zscaler* or *Browser*) and process.code_signature.trusted:true) and +not (destination.domain :("discord.com" or cdn.discordapp.com or "content.dropboxapi.com" or "dl.dropboxusercontent.com") and process.code_signature.subject_name :(*Discord* or *Dropbox*) and process.code_signature.trusted:true) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* 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/ +* Sub-technique: +** Name: Exfiltration to Text Storage Sites +** ID: T1567.003 +** Reference URL: https://attack.mitre.org/techniques/T1567/003/ +* Sub-technique: +** Name: Exfiltration Over Webhook +** ID: T1567.004 +** Reference URL: https://attack.mitre.org/techniques/T1567/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-unusual-parent-child-relationship.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-unusual-parent-child-relationship.asciidoc new file mode 100644 index 0000000000..6966350a1e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-unusual-parent-child-relationship.asciidoc @@ -0,0 +1,222 @@ +[[prebuilt-rule-8-19-33-unusual-parent-child-relationship]] +=== Unusual Parent-Child Relationship + +Identifies Windows programs run from unexpected parent processes. This could indicate masquerading or other strange activity on a system. + +*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-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/sbousseaden/Slides/blob/master/Hunting%20MindMaps/PNG/Windows%20Processes%20TH.map.png +* https://www.andreafortuna.org/2017/06/15/standard-windows-processes-a-brief-reference/ +* https://www.elastic.co/security-labs/elastic-security-labs-steps-through-the-r77-rootkit + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* 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 + +*Version*: 324 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Parent-Child Relationship* + + +Windows internal/system processes have some characteristics that can be used to spot suspicious activities. One of these characteristics is parent-child relationships. These relationships can be used to baseline the typical behavior of the system and then alert on occurrences that don't comply with the baseline. + +This rule uses this information to spot suspicious parent and child processes. + +> **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. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*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. +- 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. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule 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/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- 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] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +process.parent.name != null and process.parent.executable like ("?:\\*", "\\Device\\*") and + ( + /* suspicious parent processes */ + (process.name:"autochk.exe" and not process.parent.name:"smss.exe") or + (process.name:("fontdrvhost.exe", "dwm.exe") and not process.parent.name:("wininit.exe", "winlogon.exe", "dwm.exe")) or + (process.name:("consent.exe", "RuntimeBroker.exe", "TiWorker.exe") and not process.parent.name:("svchost.exe", "Workplace Container Helper.exe")) or + (process.name:"SearchIndexer.exe" and not process.parent.name:"services.exe") or + (process.name:"SearchProtocolHost.exe" and not process.parent.name:("SearchIndexer.exe", "dllhost.exe")) or + (process.name:"dllhost.exe" and not process.parent.name:("services.exe", "svchost.exe")) or + (process.name:"smss.exe" and not process.parent.name:"System") or + (process.name:"csrss.exe" and not process.parent.name:("smss.exe", "svchost.exe")) or + (process.name:"wininit.exe" and not process.parent.name:"smss.exe") or + (process.name:"winlogon.exe" and not process.parent.name:"smss.exe") or + (process.name:("lsass.exe", "LsaIso.exe") and not process.parent.name:"wininit.exe") or + (process.name:"LogonUI.exe" and not process.parent.name:("wininit.exe", "winlogon.exe")) or + (process.name:"services.exe" and not process.parent.name:"wininit.exe") or + (process.name:"svchost.exe" and not process.parent.name:("MsMpEng.exe", "services.exe")) or + (process.name:"spoolsv.exe" and not process.parent.name:("services.exe", "Workplace Starter.exe")) or + (process.name:"taskhost.exe" and not process.parent.name:("services.exe", "svchost.exe", "ngentask.exe")) or + (process.name:"taskhostw.exe" and not process.parent.name:("services.exe", "svchost.exe")) or + (process.name:"userinit.exe" and not process.parent.name:("dwm.exe", "winlogon.exe", "KUsrInit.exe")) or + (process.name:("wmiprvse.exe", "wsmprovhost.exe", "winrshost.exe") and not process.parent.name:"svchost.exe") or + /* suspicious child processes */ + (process.parent.name:("SearchProtocolHost.exe", "taskhost.exe", "csrss.exe") and not process.name:("werfault.exe", "wermgr.exe", "WerFaultSecure.exe", "conhost.exe", "ngentask.exe", "SearchProtocolHost.exe")) or + (process.parent.name:"autochk.exe" and not process.name:("chkdsk.exe", "doskey.exe", "WerFault.exe")) or + (process.parent.name:"smss.exe" and not process.name:("autochk.exe", "csrss.exe", "wininit.exe", "winlogon.exe", "setupcl.exe", "WerFault.exe", "wpbbin.exe", "PvsVmBoot.exe", "SophosNA.exe", "omnissa-ic-nga.exe", "vmware-svi-nga.exe", "icarus_rvrt.exe", "poqexec.exe", "QcSkExt*.exe")) or + (process.parent.name:"wermgr.exe" and not process.name:("WerFaultSecure.exe", "WerFault.exe") and + not (process.name:"rundll32.exe" and process.command_line : "*WerConCpl.dll*LaunchErcApp*")) or + (process.parent.name:"conhost.exe" and not process.name:("mscorsvw.exe", "wermgr.exe", "WerFault.exe", "WerFaultSecure.exe")) + ) and + /* exclude self-spawns */ + not startswith~(process.parent.name, process.name) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Process Hollowing +** ID: T1055.012 +** Reference URL: https://attack.mitre.org/techniques/T1055/012/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Break Process Trees +** ID: T1036.009 +** Reference URL: https://attack.mitre.org/techniques/T1036/009/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Parent PID Spoofing +** ID: T1134.004 +** Reference URL: https://attack.mitre.org/techniques/T1134/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-web-server-cloud-metadata-ssrf-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-web-server-cloud-metadata-ssrf-request.asciidoc new file mode 100644 index 0000000000..e86e305f24 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-web-server-cloud-metadata-ssrf-request.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-33-web-server-cloud-metadata-ssrf-request]] +=== Web Server Cloud Metadata SSRF Request + +Detects HTTP requests to web servers whose URL or query string references cloud instance metadata endpoints or equivalent encoded variants. Attackers exploit server-side request forgery (SSRF) vulnerabilities in web applications to reach link-local metadata services on AWS, GCP, Azure, and similar cloud providers and harvest temporary credentials, tokens, or instance details. + +*Rule type*: eql + +*Rule indices*: + +* logs-nginx.access-* +* logs-apache.access-* +* logs-apache_tomcat.access-* +* logs-iis.access-* +* logs-traefik.access-* +* logs-zeek.http-* + +*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://owasp.org/www-community/attacks/Server_Side_Request_Forgery + +*Tags*: + +* Domain: Web +* Domain: Cloud +* Domain: Network +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Initial Access +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Data Source: IIS +* Data Source: Traefik +* Data Source: Zeek +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Web Server Cloud Metadata SSRF Request* + + +This alert flags inbound HTTP requests to a web server whose `url.original` or `url.query` contains cloud instance +metadata addresses, hostnames, or credential paths. A common attacker pattern is exploiting an SSRF vulnerability so +the application fetches `http://169.254.169.254/latest/meta-data/iam/security-credentials/` or equivalent GCP and Azure +metadata routes, then reuses the returned role credentials against cloud APIs. + + +*Possible investigation steps* + + +- Review `url.original`, `url.query`, `http.request.method`, `http.response.status_code`, and `source.ip` to identify + the injected metadata target, affected route, and whether the server returned a successful response. +- URL-decode the request repeatedly and inspect parameters for nested encodings, redirect chains, or wrapper URLs that + hide the metadata destination. +- Map the targeted endpoint to the backend handler and determine whether user-controlled input can influence outbound + HTTP requests from the application. +- Correlate with application, proxy, and outbound network logs around `@timestamp` for connections from the web server + process to `169.254.169.254`, `100.100.100.200`, `metadata.google.internal`, or Azure metadata hosts. +- Check cloud audit, sign-in, or token-issuance telemetry for use of instance role or managed identity credentials + shortly after the request. +- Pivot on `source.ip` and `user_agent.original` for related SSRF, scanning, or exploitation attempts across other web + hosts. + + +*False positive analysis* + + +- Security scanners, authorized penetration tests, or WAF validation may send metadata URLs in test payloads. Confirm the + activity aligns with an approved assessment window and source before closing as benign. +- Internal documentation, error pages, or security training content that echoes metadata URLs in query strings can + trigger the rule without an exploitable SSRF path. Verify the application does not perform outbound fetches based on + the matched input. + + +*Response and remediation* + + +- Block the offending `source.ip` at the WAF or reverse proxy and add virtual patches to reject requests containing + metadata addresses or credential paths. +- If exploitation is confirmed, isolate the affected application host, preserve access logs, and rotate any cloud role + or managed identity credentials that may have been exposed. +- Patch or remediate the SSRF vulnerability by enforcing strict outbound allowlists, blocking link-local and metadata + destinations, and validating user-supplied URLs. +- Enforce IMDSv2, hop limits, and least-privilege instance roles to reduce impact if metadata access succeeds. + + +==== Rule query + + +[source, js] +---------------------------------- +web where ( + url.original : ( + "*169.254.169.254*", "*169%2e254%2e169%2e254*", "*0xa9fea9fe*", "*0xa9.0xfe.0xa9.0xfe*", + "*2852039166*", "*0251.0376.0251.0376*", "*::ffff:169.254.169.254*", "*::ffff:a9fe:a9fe*", "*fd00:ec2::254*", + "*100.100.100.200*", "*169.254.170.2*", "*metadata.google.internal*", "*metadata.goog*", "*computeMetadata/v1*", + "*meta-data/iam/security-credentials*", "*meta-data%2Fiam%2Fsecurity-credentials*", + "*latest/meta-data*", "*latest/api/token*" + ) + or + url.query : ( + "*169.254.169.254*", "*169%2e254%2e169%2e254*", "*0xa9fea9fe*", "*0xa9.0xfe.0xa9.0xfe*", + "*2852039166*", "*0251.0376.0251.0376*", "*::ffff:169.254.169.254*", "*::ffff:a9fe:a9fe*", "*fd00:ec2::254*", + "*100.100.100.200*", "*169.254.170.2*", "*metadata.google.internal*", "*metadata.goog*", "*computeMetadata/v1*", + "*meta-data/iam/security-credentials*", "*meta-data%2Fiam%2Fsecurity-credentials*", + "*latest/meta-data*", "*latest/api/token*" + ) +) and source.as.number != 396982 +and not ( + user_agent.original : ("*ChatGPT-User*", "*GPTBot*", "*ClaudeBot*", "*anthropic-ai*", "*OAI-SearchBot*", "*perplexity.ai*", "*claude-searchbot*", "*anthropic.com*", "*google.com/bot.html*", "*TelegramBot*", "*openai.com/searchbot*", "*LinkedInBot*", "*x.ai/grokbot*", "*Discordbot*", "*Amazonbot*", "*amazonbot*", "*Applebot*", "*Slackbot*", "*Twitterbot*", "*Bytespider*") + and http.response.status_code in (401, 403, 404, 429) +) + +---------------------------------- + +*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: 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-33/prebuilt-rule-8-19-33-whoami-process-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-whoami-process-activity.asciidoc new file mode 100644 index 0000000000..34df98c369 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rule-8-19-33-whoami-process-activity.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-33-whoami-process-activity]] +=== Whoami Process Activity + +Identifies suspicious use of whoami.exe which displays user, group, and privileges information for the user who is currently logged on to the local system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*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: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: Windows Security Event Logs + +*Version*: 220 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Whoami Process Activity* + + +After successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps. This can happen by running commands to enumerate network resources, users, connections, files, and installed security software. + +This rule looks for the execution of the `whoami` utility. Attackers commonly use this utility to measure their current privileges, discover the current user, determine if a privilege escalation was successful, etc. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. + + +*False positive analysis* + + +- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed. + + +*Related rules* + + +- Account Discovery Command via SYSTEM Account - 2856446a-34e6-435b-9fb5-f8f040bfa7ed + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- 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. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule 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/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] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and process.name : "whoami.exe" and +( + ( + /* scoped for whoami execution under system privileges */ + ( + ( + user.domain : ("NT *", "* NT", "IIS APPPOOL") and + user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20", "S-1-5-82-*") and + not ?winlog.event_data.SubjectUserName : "*$" and + + /* Sysmon will always populate user.id as S-1-5-18, leading to FPs */ + not data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon") + ) or + (?process.Ext.token.integrity_level_name : "System" or ?winlog.event_data.IntegrityLevel : "System") + ) and + not ( + process.parent.name : "cmd.exe" and + ?process.parent.args : ( + "chcp 437>nul 2>&1 & C:\\WINDOWS\\System32\\whoami.exe /groups", + "chcp 437>nul 2>&1 & %systemroot%\\system32\\whoami /user", + "C:\\WINDOWS\\System32\\whoami.exe /groups", + "*WINDOWS\\system32\\config\\systemprofile*" + ) + ) and + not (process.parent.executable : "C:\\Windows\\system32\\inetsrv\\appcmd.exe" and ?process.parent.args : "LIST") and + not process.parent.executable : ( + "C:\\Program Files\\Microsoft Monitoring Agent\\Agent\\MonitoringHost.exe", + "C:\\Program Files\\Cohesity\\cohesity_windows_agent_service.exe" + ) + ) or + process.parent.name : ("wsmprovhost.exe", "w3wp.exe", "wmiprvse.exe", "rundll32.exe", "regsvr32.exe") +) + +---------------------------------- + +*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: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rules-8-19-33-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rules-8-19-33-appendix.asciidoc new file mode 100644 index 0000000000..9860f01067 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rules-8-19-33-appendix.asciidoc @@ -0,0 +1,64 @@ +["appendix",role="exclude",id="prebuilt-rule-8-19-33-prebuilt-rules-8-19-33-appendix"] += Downloadable rule update v8.19.33 + +This section lists all updates associated with version 8.19.33 of the Fleet integration *Prebuilt Security Detection Rules*. + + +include::prebuilt-rule-8-19-33-azure-wireserver-unusual-process-connection.asciidoc[] +include::prebuilt-rule-8-19-33-first-seen-network-flow-exporter-followed-by-suspicious-source-activity.asciidoc[] +include::prebuilt-rule-8-19-33-aws-root-console-login-password-spraying.asciidoc[] +include::prebuilt-rule-8-19-33-aws-security-hub-disabled.asciidoc[] +include::prebuilt-rule-8-19-33-aws-backup-resource-enumeration-via-long-term-access-key.asciidoc[] +include::prebuilt-rule-8-19-33-aws-ses-enumeration-via-long-term-access-key.asciidoc[] +include::prebuilt-rule-8-19-33-aws-s3-bucket-mfa-delete-disabled.asciidoc[] +include::prebuilt-rule-8-19-33-aws-organizations-delegated-administrator-registered.asciidoc[] +include::prebuilt-rule-8-19-33-aws-service-quota-increase-requested-by-rare-identity.asciidoc[] +include::prebuilt-rule-8-19-33-aws-ses-account-email-sending-enabled.asciidoc[] +include::prebuilt-rule-8-19-33-entra-id-device-bound-prt-replay-via-first-party-app-from-unusual-ip.asciidoc[] +include::prebuilt-rule-8-19-33-entra-id-device-bound-prt-from-unusual-device-ip.asciidoc[] +include::prebuilt-rule-8-19-33-entra-id-windows-hello-or-passkey-sign-in-from-unregistered-device.asciidoc[] +include::prebuilt-rule-8-19-33-azure-storage-anonymous-blob-access-to-unusual-resource.asciidoc[] +include::prebuilt-rule-8-19-33-entra-id-windows-hello-for-business-credential-registered.asciidoc[] +include::prebuilt-rule-8-19-33-potential-ssh-brute-force-detected-via-macos-security-events.asciidoc[] +include::prebuilt-rule-8-19-33-potential-successful-ssh-brute-force-attack-via-macos-security-events.asciidoc[] +include::prebuilt-rule-8-19-33-azure-wireserver-openssl-certificate-decrypt-or-linuxtransport-generation.asciidoc[] +include::prebuilt-rule-8-19-33-potential-fileless-execution-via-o-tmpfile.asciidoc[] +include::prebuilt-rule-8-19-33-linux-firewall-rule-creation-or-modification.asciidoc[] +include::prebuilt-rule-8-19-33-file-with-suspicious-double-extension-created-by-web-server.asciidoc[] +include::prebuilt-rule-8-19-33-potential-etherhiding-c2-via-curl-json-rpc-request.asciidoc[] +include::prebuilt-rule-8-19-33-azure-wireserver-http-request-from-unexpected-user-agent.asciidoc[] +include::prebuilt-rule-8-19-33-potential-entra-id-prt-extraction-via-browsercore.asciidoc[] +include::prebuilt-rule-8-19-33-newly-seen-commonly-abused-network-scanner.asciidoc[] +include::prebuilt-rule-8-19-33-azcopy-or-azure-storage-explorer-usage-on-unusual-host.asciidoc[] +include::prebuilt-rule-8-19-33-suricata-and-elastic-defend-network-correlation.asciidoc[] +include::prebuilt-rule-8-19-33-web-server-cloud-metadata-ssrf-request.asciidoc[] +include::prebuilt-rule-8-19-33-potential-data-exfiltration-through-curl.asciidoc[] +include::prebuilt-rule-8-19-33-elastic-defend-and-network-security-alerts-correlation.asciidoc[] +include::prebuilt-rule-8-19-33-multiple-alerts-involving-a-user.asciidoc[] +include::prebuilt-rule-8-19-33-aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc[] +include::prebuilt-rule-8-19-33-aws-lateral-movement-from-kubernetes-sa-via-assumerolewithwebidentity.asciidoc[] +include::prebuilt-rule-8-19-33-gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc[] +include::prebuilt-rule-8-19-33-kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc[] +include::prebuilt-rule-8-19-33-m365-onedrive-sharepoint-excessive-file-downloads.asciidoc[] +include::prebuilt-rule-8-19-33-m365-identity-user-brute-force-attempted.asciidoc[] +include::prebuilt-rule-8-19-33-m365-identity-user-account-lockouts.asciidoc[] +include::prebuilt-rule-8-19-33-m365-teams-rogue-help-desk-chat-created.asciidoc[] +include::prebuilt-rule-8-19-33-potential-linux-hack-tool-launched.asciidoc[] +include::prebuilt-rule-8-19-33-system-v-init-script-created.asciidoc[] +include::prebuilt-rule-8-19-33-potential-etherhiding-c2-via-blockchain-connection.asciidoc[] +include::prebuilt-rule-8-19-33-unusual-network-connection-to-suspicious-web-service.asciidoc[] +include::prebuilt-rule-8-19-33-launch-service-creation-and-immediate-loading.asciidoc[] +include::prebuilt-rule-8-19-33-accepted-default-telnet-port-connection.asciidoc[] +include::prebuilt-rule-8-19-33-newly-observed-ipsec-nat-traversal-peer.asciidoc[] +include::prebuilt-rule-8-19-33-potential-network-scan-detected.asciidoc[] +include::prebuilt-rule-8-19-33-potential-syn-based-port-scan-detected.asciidoc[] +include::prebuilt-rule-8-19-33-rpc-remote-procedure-call-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-33-abnormally-large-dns-response.asciidoc[] +include::prebuilt-rule-8-19-33-network-activity-to-a-suspicious-top-level-domain.asciidoc[] +include::prebuilt-rule-8-19-33-remote-file-download-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-33-remote-management-access-launch-after-msi-install.asciidoc[] +include::prebuilt-rule-8-19-33-protected-storage-service-access-via-smb.asciidoc[] +include::prebuilt-rule-8-19-33-proxy-execution-via-console-window-host.asciidoc[] +include::prebuilt-rule-8-19-33-whoami-process-activity.asciidoc[] +include::prebuilt-rule-8-19-33-persistence-via-update-orchestrator-service-hijack.asciidoc[] +include::prebuilt-rule-8-19-33-unusual-parent-child-relationship.asciidoc[] diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rules-8-19-33-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rules-8-19-33-summary.asciidoc new file mode 100644 index 0000000000..03d9dc4ba2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rules-8-19-33-summary.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-33-prebuilt-rules-8-19-33-summary]] +[role="xpack"] +== Update v8.19.33 + +This section lists all updates associated with version 8.19.33 of the Fleet integration *Prebuilt Security Detection Rules*. + + +[width="100%",options="header"] +|============================================== +|Rule |Description |Status |Version + +|<> | Identifies shells, LOLBins, GTFOBins, and scripting runtimes connecting to the Azure WireServer / HostGAPlugin address 168.63.129.16 on ports 80 or 32526. The guest agent uses this fabric endpoint for GoalState, certificates, and vmSettings. Adversaries with code execution on an Azure VM (including via Run Command) use curl, PowerShell, openssl, bun, or similar tools to enumerate versions, pull transport certificates, and read HostGAPlugin /vmSettings. Azure guest-agent binaries and system python used by waagent are excluded. Descendants of the guest agent are not excluded: Run Command payloads execute in that tree. | new | 1 + +|<> | Identifies a newly observed NetFlow, IPFIX, or sFlow exporter IP followed by another detection alert with medium-or-higher severity or an elevated risk score, where that exporter IP is the source of the detected activity in the same data stream namespace. This correlation adds behavioral evidence that can help distinguish routine exporter onboarding from a potentially unauthorized or compromised exporter introduced as part of defense evasion. | new | 2 + +|<> | Identifies failed authentication attempts against the AWS Management Console root user from the same source IP address targeting multiple AWS accounts. Password spraying uses few attempts per target across many accounts to avoid lockout, making per-account volume an unreliable signal. This rule detects the cross-account breadth pattern: a single source IP generating root ConsoleLogin failures across two or more distinct AWS accounts. Requires an AWS Organizations-level CloudTrail trail aggregating events from member accounts. | new | 1 + +|<> | Detects when AWS Security Hub is disabled in a region. Security Hub aggregates security findings from AWS services (GuardDuty, Inspector, Macie, IAM Access Analyzer) and third-party tools into a single pane of glass. Disabling it suppresses centralized finding aggregation and compliance checks, removing visibility into threats across the account. This action is a documented pre-ransomware and pre-exfiltration defense evasion technique. | new | 1 + +|<> | Detects enumeration of AWS Backup resources using long-term IAM access keys (AKIA* prefix). AWS Backup protects EC2 instances, EBS volumes, RDS databases, DynamoDB tables, EFS file systems, and S3 buckets. An adversary who obtains long-term access keys may enumerate backup vaults, backup plans, and protected resources as a precursor to ransomware. Identifying which resources have recent backups (indicating high-value data) and what vault access policies can be modified to delete or corrupt the backups before encrypting the primary data. | new | 1 + +|<> | Detects enumeration of Amazon Simple Email Service (SES) resources using long-term IAM access keys (AKIA* prefix). Long-term access keys are associated with IAM users and are the credential type most commonly exfiltrated from repositories, configuration files, and environment variables. An adversary who obtains a long-term key may enumerate SES to discover verified email identities, sending quotas, and DKIM/MAIL FROM domain configurations as a precursor to phishing or spam campaigns launched from the compromised account's verified domains. | new | 1 + +|<> | Detects when MFA Delete is disabled on an Amazon S3 bucket. MFA Delete is an additional layer of security for versioned S3 buckets that requires multi-factor authentication to permanently delete object versions or disable versioning. When MFA Delete is disabled, an adversary with S3 write access and a compromised long-term access key can permanently delete object versions, a critical step in ransomware attacks that target S3 versioning as a backup mechanism. MFA Delete is configured via PutBucketVersioning with the MfaDelete parameter set to Disabled. | new | 1 + +|<> | Detects when an AWS member account is registered as a delegated administrator for an AWS service via the RegisterDelegatedAdministrator API. Delegated administrators receive service-level administrative access across the entire organization without being the management account. An attacker who compromises a principal with organizations permissions can abuse overly permissive managed policies to register a member account they control as a delegated administrator, then use that privileged access to escalate privileges organization-wide and compromise all member accounts. | new | 1 + +|<> | Detects the first time an AWS identity requests a service quota increase via the AWS Service Quotas API within a 7-day history window. Service quota increases are submitted to AWS Support and, when approved, raise the limits on EC2 instances, Lambda concurrency, VPC resources, and other services. An adversary who obtains AWS credentials may request quota increases as infrastructure preparation for large-scale cryptomining, DDoS amplification, phishing campaigns, or data exfiltration operations that require compute or network resources beyond the account's current limits. | new | 1 + +|<> | Detects when account-level email sending is explicitly enabled in Amazon SES, via the v1 UpdateAccountSendingEnabled API with Enabled: true or the v2 PutAccountSendingAttributes API with SendingEnabled: true. Account-level sending is commonly paused by an administrator, or by automation wired to CloudWatch reputation alarms when bounce or complaint rates rise. An attacker who compromises an AWS account may re-enable sending to restore a paused capability as part of phishing infrastructure setup, allowing bulk email under the victim organization's trusted sending domain. Neither API can resume sending that AWS itself has paused. | new | 1 + +|<> | Detects a first-party FOCI tooling client (Azure CLI, PowerShell, VS Code, Graph CLI, Azure AD PowerShell, or Visual Studio) redeeming a device-bound Primary Refresh Token (PRT) for Microsoft Graph, SharePoint/OneDrive, or Exchange Online from an IP that is not among that user and device's Windows Sign-In or WAM addresses. Replay events are limited to compliant or Intune-managed devices: the stolen cookie keeps the workstation deviceid, so compliant-device Conditional Access can succeed off-box. | new | 1 + +|<> | Detects a first-party FOCI tooling client (Azure CLI, PowerShell, VS Code, Graph CLI, Azure AD PowerShell, or Visual Studio) redeeming a device-bound Primary Refresh Token (PRT) for Microsoft Graph, SharePoint/OneDrive, or Exchange Online from a source IP that has not been seen with that deviceid. Replay events are limited to compliant or Intune-managed devices. Adversaries who steal a WAM PRT SSO cookie replay it off-box; the token keeps the workstation deviceid, so this pair is new even when Windows Sign-In for that device is outside a correlation window. | new | 1 + +|<> | Identifies a Microsoft Entra ID sign-in that is satisfied by a phishing-resistant, device-bound credential (Windows Hello for Business, FIDO2 security key, or passkey) while carrying no device identifier. Windows Hello for Business (WHfB) and passkey credentials are bound to a device's TPM, so a genuine sign-in with one of these methods is normally accompanied by the registered device it lives on. A WHfB or passkey assertion that authenticates with an empty `device_detail.device_id` indicates the underlying key material is being used away from its bound device, for example by an adversary who extracted the key (or signed an assertion with it) and replayed it from attacker infrastructure to mint device-agnostic tokens. This is the core primitive of the "borrowing Windows Hello keys" technique and is a strong precursor to attacker device registration and Primary Refresh Token (PRT) issuance. Cross-tenant (B2B) sign-ins are excluded because they are a common benign source of empty device identifiers. | new | 1 + +|<> | Identifies the first time an Azure Storage resource receives an anonymous data-plane read (GetBlob and related Get or List operations). Anonymous requests are used to probe public containers and to test stolen blob URLs before a SAS is appended. First-seen resource ID keeps volume down while still covering WireServer-related probes of status or extension blobs. | new | 1 + +|<> | Identifies the first-seen registration of a Windows Hello for Business (WHfB) credential for a Microsoft Entra ID user from a given source ASN in a tenant, based on a prefixed historic window. Enrollment is commonly part of legitimate onboarding or passwordless rollout and is not inherently malicious. Adversaries who have obtained a token that satisfies fresh (NGC) multi-factor authentication, for example by borrowing an existing WHfB key or passkey, can also enroll their own WHfB credential to establish durable, phishing-resistant persistence that survives password resets and standard session revocation. Correlate first-seen enrollments with the sign-in and device state that preceded them. | new | 1 + +|<> | Identifies a high number of failed inbound SSH authentication attempts on a macOS host within a short time window, using sshd authentication messages collected by the macOS Security Events integration. Adversaries may perform password brute force or password spraying against exposed SSH services to obtain unauthorized access. | new | 2 + +|<> | Identifies a burst of failed inbound SSH authentication attempts on a macOS host followed shortly by a successful SSH authentication on the same host, using sshd authentication messages collected by the macOS Security Events integration. A successful login immediately after repeated failures indicates that a password brute force or password spraying attack against an exposed SSH service has likely succeeded. | new | 1 + +|<> | Identifies OpenSSL generating a CN=LinuxTransport certificate or decrypting CMS/PKCS7 payloads with a key that is not the Azure Linux Agent certificate under /var/lib/waagent. Adversaries can scrape WireServer certificates, mint a LinuxTransport identity, and decrypt extension protectedSettings with openssl cms -decrypt or smime -decrypt. | new | 1 + +|<> | This rule identifies potential fileless ELF execution where a process is launched from an anonymous temporary executable path that appears as "/#" in "process.executable". This pattern may be associated with "O_TMPFILE" and "execveat" with "AT_EMPTY_PATH", which can allow execution without a normal filesystem pathname. | new | 1 + +|<> | Adversaries may create or modify Linux firewall rules with DROP, ACCEPT, or REJECT actions to affect how a host receives or sends network traffic. This activity may be used to bypass security controls, block defensive tooling, or gain unauthorized access to the network. | new | 1 + +|<> | This rule detects when a web server process creates a file with a double extension, where the real extension is a non-web extension. This is a common technique used by attackers to bypass security measures and to hide the true nature of the file. | new | 1 + +|<> | Detects when curl or nscurl is spawned by a shell or osascript to make a JSON-RPC request to a blockchain endpoint for command and control purposes. Adversaries may leverage blockchain smart contracts as a covert C2 channel to retrieve commands or payload staging information, as observed in ClickFix campaigns. | new | 1 + +|<> | Identifies HTTP requests to Azure WireServer (168.63.129.16) for GoalState, certificates, versions, or HostGAPlugin vmSettings that do not use a known guest-agent user agent. These requests retrieve transport certificates and extension protectedSettings, including embedded SAS URLs. Azure Linux Agent, Windows guest agent, and related platform UAs are excluded. Requests with no user agent are also excluded; that pattern is common for the Windows guest agent. | new | 1 + +|<> | Identifies anomalous execution of BrowserCore.exe, the Windows component used by Chromium-based browsers for native messaging with the Web Account Manager (WAM). Adversaries abuse BrowserCore to extract Entra ID Primary Refresh Tokens (PRTs) without interactive browser context, enabling session hijacking. Legitimate BrowserCore launches carry a chrome-extension:// argument from the browser native-messaging host. | new | 2 + +|<> | Identifies newly observed execution of SoftPerfect Network Scanner or Advanced IP/Port Scanner on a Windows host. Adversaries commonly use these legitimate scanners during post-compromise discovery to map live hosts, open ports, and reachable systems, then select targets for lateral movement. | new | 1 + +|<> | Identifies the first time, in a historical window, a host runs AzCopy copy or sync to Azure Blob, Data Lake, or File storage, or starts Azure Storage Explorer. These Microsoft utilities are legitimate data-transfer tools; ransomware and cloud-ransomware operators drop portable copies and use SAS-authenticated jobs to pull data from victim storage and push it to attacker-controlled accounts. | new | 1 + +|<> | This detection correlates Suricata alerts with Elastic Defend network events to identify the source process performing the network activity. | update | 5 + +|<> | Detects HTTP requests to web servers whose URL or query string references cloud instance metadata endpoints or equivalent encoded variants. Attackers exploit server-side request forgery (SSRF) vulnerabilities in web applications to reach link-local metadata services on AWS, GCP, Azure, and similar cloud providers and harvest temporary credentials, tokens, or instance details. | update | 2 + +|<> | Detects the use of curl to upload files to an internet server. Threat actors often will collect and exfiltrate data on a system to their C2 server for review. Many threat actors have been observed using curl to upload the collected data. Use of curl in this way, while not inherently malicious, should be considered highly abnormal and suspicious activity. | update | 10 + +|<> | This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto Networks (PANW), Fortinet Fortigate and Suricata by host.ip and source.ip. This may indicate that this host is compromised and triggering multi-datasource alerts. | update | 8 + +|<> | This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. | update | 10 + +|<> | 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 | 3 + +|<> | Detects when credentials issued through `AssumeRoleWithWebIdentity` for a Kubernetes service account identity are later used for several distinct AWS control-plane actions on the same session access key. Workloads that use EKS IAM Roles for Service Accounts routinely exchange a projected service-account token for short-lived IAM credentials; this rule highlights sessions where that exchange is followed by a spread of sensitive APIs—reconnaissance, secrets and parameter access, IAM changes, or compute creation—beyond what routine pod traffic usually shows. High-volume S3 object reads and writes are excluded from the correlation set to reduce noise from normal data-plane work. | update | 2 + +|<> | Detects when the same GKE identity creates or modifies a Role or ClusterRole with high-risk permissions (wildcard access, RBAC escalation verbs, or access to secrets / privileged APIs) and also creates or patches a DaemonSet, Deployment, or CronJob within five minutes. This correlation is consistent with RBAC-based privilege escalation followed by payload deployment. | update | 2 + +|<> | Detects a sequence where a principal creates or modifies a Role/ClusterRole to include high-risk permissions (e.g., wildcard access or escalation verbs) and then creates or patches a workload resource (DaemonSet, Deployment, or CronJob) shortly after, which may indicate RBAC-based privilege escalation followed by payload deployment. This pattern is often used by adversaries to gain unauthorized access to sensitive resources and deploy malicious payloads. | update | 4 + +|<> | Identifies when an excessive number of files are downloaded from OneDrive or SharePoint by an authorized user or application in a short period of time. This may indicate a potential data exfiltration event, especially if the downloads are performed using OAuth authentication which could suggest an OAuth phishing attack such as Device Code Authentication phishing. | update | 10 + +|<> | Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords. | update | 419 + +|<> | Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. | update | 10 + +|<> | Identifies a one-on-one Microsoft Teams chat created by a user from a foreign tenant whose display name, member profile, or email local-part resembles IT help desk or Microsoft security staff. Adversaries abuse cross-tenant Teams external access to impersonate support personnel and socially engineer victims into granting remote access or disclosing credentials. | update | 2 + +|<> | Monitors for the execution of different processes that might be used by attackers for malicious intent. An alert from this rule should be investigated further, as hack tools are commonly used by blue teamers and system administrators as well. | update | 110 + +|<> | Files that are placed in the "/etc/init.d/" directory in Unix can be used to start custom applications, services, scripts or commands during start-up. Init.d has been mostly replaced in favor of Systemd. However, the "systemd-sysv-generator" can convert init.d files to service unit files that run at boot. Adversaries may add or alter files located in the "/etc/init.d/" directory to execute malicious code upon boot in order to gain persistence on the system. | update | 120 + +|<> | Detects when a scripting interpreter makes an outbound network connection to an Ethereum blockchain endpoint for command and control purposes. Adversaries may leverage Ethereum blockchain infrastructure as a covert C2 channel to receive commands and exfiltrate data, as observed in campaigns like SleepyDuck malware. | update | 3 + +|<> | This rule monitors for the unusual occurrence of outbound network connections to suspicious webservice domains. | update | 7 + +|<> | An adversary can establish persistence by installing a new launch agent that executes at login by using launchd or launchctl to load a plist into the appropriate directories. | update | 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. | update | 117 + +|<> | This rule identifies outbound IPSEC NAT Traversal (NAT-T) traffic to an external destination IP that was not observed during the previous 5 days. IPSEC is a VPN technology that allows one system to talk to another using encrypted tunnels. NAT Traversal encapsulates IPSEC ESP traffic in UDP and, once a NAT device is detected, both peers float to UDP port 4500 for the tunnel data channel. Newly observed external NAT-T peers may indicate unauthorized VPN use or an adversary tunneling command and control or exfiltration traffic over the Internet. | update | 114 + +|<> | This rule identifies a potential port scan from an internal IP address. A port scan is a method utilized by attackers to systematically scan a target system for open ports, allowing them to identify available services and potential vulnerabilities. By mapping out the open ports, attackers can gather critical information to plan and execute targeted attacks, gaining unauthorized access, compromising security, and potentially leading to data breaches, unauthorized control, or further exploitation of the targeted system. This rule defines a threshold-based approach to detect connection attempts from a single internal source to a wide range of destination ports on a single destination. | update | 16 + +|<> | This rule identifies a potential SYN-Based port scan. A SYN port scan is a technique employed by attackers to scan a target network for open ports by sending SYN packets to multiple ports and observing the response. Attackers use this method to identify potential entry points or services that may be vulnerable to exploitation, allowing them to launch targeted attacks or gain unauthorized access to the system or network, compromising its security and potentially leading to data breaches or further malicious activities. This rule defines a threshold-based approach to detect connection attempts from a single source to a large number of unique destination ports, while limiting the number of packets per port. | update | 15 + +|<> | This rule detects network events that may indicate the use of RPC traffic to the Internet. RPC is commonly used by system administrators to remotely control a system for maintenance or to use shared resources. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. | update | 113 + +|<> | 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 | 113 + +|<> | Identifies DNS queries to commonly abused Top Level Domains by common LOLBINs or executables running from world writable directories or unsigned binaries. This behavior matches on common malware C2 abusing less formal domain names. | update | 5 + +|<> | Identifies PowerShell being used to download an executable file from an untrusted remote destination. | update | 117 + +|<> | Detects an MSI installer execution followed by the execution of commonly abused Remote Management Software like ScreenConnect. This behavior may indicate abuse where an attacker triggers an MSI install then connects via a guest link with a known session key. | update | 5 + +|<> | Identifies remote access to the Windows Protected Storage Service through the IPC$ share. Attackers may abuse this named pipe to interact with the Protected Storage Service and extract sensitive credentials, certificates, or DPAPI backup keys. | update | 2 + +|<> | Identifies abuse of the Console Window Host (conhost.exe) to execute commands via proxy. This behavior is used as a defense evasion technique to blend-in malicious activity with legitimate Windows software. | update | 5 + +|<> | Identifies suspicious use of whoami.exe which displays user, group, and privileges information for the user who is currently logged on to the local system. | update | 220 + +|<> | Identifies potential hijacking of the Microsoft Update Orchestrator Service to establish persistence with an integrity level of SYSTEM. | update | 320 + +|<> | Identifies Windows programs run from unexpected parent processes. This could indicate masquerading or other strange activity on a system. | update | 324 + +|============================================== diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc index 4646827d7c..5fd0b53068 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 +|<> | 16 Sep 2026 | 26 | 32 | +This release includes new rules for Linux, Windows, macOS, AWS, Azure, and Network Traffic. New rules for Linux include detection for credential access, persistence, and defense evasion. New rules for Windows include detection for credential access, discovery, and exfiltration. New rules for macOS include detection for credential access and command and control. New rules for AWS include detection for credential access, resource development, discovery, persistence, impact, and defense evasion. New rules for Azure include detection for credential access, defense evasion, persistence, and discovery. New rules for Network Traffic include detection for credential access and defense evasion. Additionally, significant tuning for Linux, Windows, macOS, AWS, Azure, Microsoft 365, Kubernetes, and GCP rules improves efficacy and performance. + + |<> | 01 Sep 2026 | 24 | 94 | This release includes new rules for Linux, AWS, Windows, macOS, GCP, Network Traffic, and SonicWall. New rules for Linux include detection for execution, discovery, defense evasion, initial access, and persistence. New rules for AWS include detection for credential access, defense evasion, persistence, privilege escalation, and resource development. New rules for Windows include detection for initial access and defense evasion. New rules for macOS include detection for persistence, execution, defense evasion, and initial access. New rules for GCP include detection for discovery. New rules for Network Traffic include detection for command and control and initial access. New rules for SonicWall include detection for initial access. Additionally, significant tuning for Linux, Windows, macOS, AWS, Azure, Kubernetes, and network rules improves efficacy and performance. @@ -173,3 +177,4 @@ include::downloadable-packages/8-19-29/prebuilt-rules-8-19-29-summary.asciidoc[l include::downloadable-packages/8-19-30/prebuilt-rules-8-19-30-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-31/prebuilt-rules-8-19-31-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-32/prebuilt-rules-8-19-32-summary.asciidoc[leveloffset=+1] +include::downloadable-packages/8-19-33/prebuilt-rules-8-19-33-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 f7d66c48f2..5fded56c84 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc @@ -24,12 +24,14 @@ and their rule type is `machine_learning`. |<> |Detects the closure of an AWS account via the CloseAccount API. This can be called either by the account itself (account.amazonaws.com, self-service closure) or by an AWS Organizations management account against one of its member accounts (organizations.amazonaws.com). Account closure triggers a 90-day grace period during which the account is suspended before permanent termination, and is one of the most destructive and disruptive actions available in AWS. It removes access to all resources and data in the account for the duration of the suspension. An adversary with root-level access in a member account, or management-level access to an organization, may close accounts to destroy evidence, disrupt business operations, or eliminate compute and data resources. A malicious insider could use the same action for sabotage. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Impact], [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 +|<> |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 |3 |<> |Detects any attempt, successful or denied, for a member account to leave an AWS Organization via the LeaveOrganization API. Leaving an organization immediately strips the account of every Service Control Policy (SCP) guardrail the organization enforces, removes it from centralized CloudTrail aggregation, and eliminates the management account's ability to audit or control it going forward. An adversary who has gained root or organization-management-capable access in a member account may use this technique to escape organizational security controls and operate unmonitored. Denied attempts are included because a blocked call is just as strong a signal of intent as a successful one, and is often the only trace left when the account's default permissions correctly prevent the action. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS Organizations], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Impact], [Resources: Investigation Guide] |None |1 |<> |Identifies deletion of an AWS Backup recovery point via DeleteRecoveryPoint. A recovery point is a stored backup of a protected resource (EBS, RDS, DynamoDB, EFS, S3, and others). Deleting recovery points removes the ability to restore the associated data and is a core anti-recovery technique used in ransomware and data-destruction attacks to ensure victims cannot recover without paying or rebuilding. Routine lifecycle expirations are performed by the AWS Backup service itself; deletion by a non-service principal is rare and should be reviewed. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Backup], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1 +|<> |Detects enumeration of AWS Backup resources using long-term IAM access keys (AKIA* prefix). AWS Backup protects EC2 instances, EBS volumes, RDS databases, DynamoDB tables, EFS file systems, and S3 buckets. An adversary who obtains long-term access keys may enumerate backup vaults, backup plans, and protected resources as a precursor to ransomware. Identifying which resources have recent backups (indicating high-value data) and what vault access policies can be modified to delete or corrupt the backups before encrypting the primary data. |[Domain: Cloud], [Platform: AWS], [Data Source: AWS CloudTrail], [Service: AWS Backup], [Rule Type: Custom Query (KQL)], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 + |<> |Identifies deletion of an AWS Backup vault or removal of its Vault Lock configuration via DeleteBackupVault or DeleteBackupVaultLockConfiguration. A backup vault stores recovery points, and Vault Lock enforces WORM (write-once, read-many) immutability that prevents recovery points from being deleted before their retention expires. Removing the lock defeats the primary control designed to stop ransomware from destroying backups, and deleting the vault removes the backup container entirely. Both actions are strong anti-recovery signals and are rare in normal operations. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Backup], [Use Case: Threat Detection], [Tactic: Impact], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 |<> |Detects the first time an AWS identity submits an AWS Batch job with a container command override ("containerOverrides.command"), indicating a runtime-modified execution environment. Command overrides allow the submitter to replace the default command of a job definition at submission time. This flexibility is commonly abused by adversaries to inject malicious commands or exfiltration logic into otherwise legitimate Batch compute environments without modifying the underlying job definition — making the malicious activity harder to detect through configuration review alone. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Batch], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |1 @@ -308,12 +310,14 @@ and their rule type is `machine_learning`. |<> |Identifies the modification of an AWS Lambda layer permission policy to grant another AWS account, an AWS Organization, or the public the ability to use a layer version. Lambda layers package code and dependencies that are loaded into the execution environment of any function that references them. Sharing a layer with an external account or with everyone can leak proprietary code or secrets bundled in the layer, and can serve as a supply-chain mechanism whereby downstream functions load attacker-influenced code. Layer sharing should be infrequent and deliberate, so newly granted external or public access warrants review. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 -|<> |Detects when credentials issued through `AssumeRoleWithWebIdentity` for a Kubernetes service account identity are later used for several distinct AWS control-plane actions on the same session access key. Workloads that use EKS IAM Roles for Service Accounts routinely exchange a projected service-account token for short-lived IAM credentials; this rule highlights sessions where that exchange is followed by a spread of sensitive APIs—reconnaissance, secrets and parameter access, IAM changes, or compute creation—beyond what routine pod traffic usually shows. High-volume S3 object reads and writes are excluded from the correlation set to reduce noise from normal data-plane work. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Data Source: AWS STS], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Discovery], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 +|<> |Detects when credentials issued through `AssumeRoleWithWebIdentity` for a Kubernetes service account identity are later used for several distinct AWS control-plane actions on the same session access key. Workloads that use EKS IAM Roles for Service Accounts routinely exchange a projected service-account token for short-lived IAM credentials; this rule highlights sessions where that exchange is followed by a spread of sensitive APIs—reconnaissance, secrets and parameter access, IAM changes, or compute creation—beyond what routine pod traffic usually shows. High-volume S3 object reads and writes are excluded from the correlation set to reduce noise from normal data-plane work. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Data Source: AWS STS], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Discovery], [Tactic: Credential Access], [Resources: Investigation Guide] |None |2 |<> |Identifies a high number of failed authentication attempts to the AWS management console for the Root user identity. An adversary may attempt to brute force the password for the Root user identity, as it has complete access to all services and resources for the AWS account. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Sign-In], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |214 |<> |Identifies a successful login to the AWS Management Console by the Root user. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Sign-In], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access], [Tactic: Privilege Escalation] |None |214 +|<> |Detects when an AWS member account is registered as a delegated administrator for an AWS service via the RegisterDelegatedAdministrator API. Delegated administrators receive service-level administrative access across the entire organization without being the management account. An attacker who compromises a principal with organizations permissions can abuse overly permissive managed policies to register a member account they control as a delegated administrator, then use that privileged access to escalate privileges organization-wide and compromise all member accounts. |[Domain: Cloud], [Platform: AWS], [Data Source: AWS CloudTrail], [Service: AWS Organizations], [Rule Type: Custom Query (KQL)], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 + |<> |Identifies a principal that, within a short window, both registers an Amazon ECS task definition using a public / non-ECR container image at a high CPU allocation (8 or 16 vCPU) AND launches ECS workloads (RunTask, StartTask, or CreateService). Registering a public miner image at maximum compute and then launching it is the ECS/Fargate cryptocurrency-mining deployment pattern seen after credential compromise. Requiring both the mining-signature registration and a launch by the same principal confirms an actual deployment rather than a standalone (possibly benign) task-definition registration, which sharply reduces false positives from high-compute workloads that are merely registered. |[Domain: Cloud], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1 |<> |Identifies the creation or modification of an Amazon RDS DB instance or cluster where the "publiclyAccessible" attribute is set to "true". Publicly accessible RDS instances expose a network endpoint on the public internet, which may allow unauthorized access if combined with overly permissive security groups, weak authentication, or misconfigured IAM policies. Adversaries may enable public access on an existing instance, or create a new publicly accessible instance, to establish persistence, move data outside of controlled network boundaries, or bypass internal access controls. |[Domain: Cloud], [Platform: AWS], [Data Source: AWS CloudTrail], [Service: AWS RDS], [Tactic: Defense Evasion], [Tactic: Persistence], [Rule Type: Event Correlation (EQL)], [Resources: Investigation Guide] |None |10 @@ -336,6 +340,8 @@ and their rule type is `machine_learning`. |<> |Surfaces an AWS identity whose successful API traffic is dominated by a small set of large cloud-provider source AS organization labels, yet also shows a very small share of traffic from other AS organization names—including at least one sensitive control-plane, credential, storage, or model-invocation action on that uncommon network path with recent activity from the uncommon path. The intent is to highlight disproportionate “baseline” cloud egress versus sparse use from rarer networks on the same principal, a shape that can appear when automation or CI credentials are reused or pivoted outside their usual hosted-cloud footprint. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |1 +|<> |Identifies failed authentication attempts against the AWS Management Console root user from the same source IP address targeting multiple AWS accounts. Password spraying uses few attempts per target across many accounts to avoid lockout, making per-account volume an unreliable signal. This rule detects the cross-account breadth pattern: a single source IP generating root ConsoleLogin failures across two or more distinct AWS accounts. Requires an AWS Organizations-level CloudTrail trail aggregating events from member accounts. |[Domain: Cloud], [Domain: Identity], [Platform: AWS], [Data Source: AWS CloudTrail], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Rule Type: Threshold], [Resources: Investigation Guide] |None |1 + |<> |Identifies when the transfer lock on an AWS Route 53 domain is disabled. The transfer lock protects domains from being moved to another registrar or AWS account without authorization. Disabling this lock removes an important safeguard against domain hijacking. Adversaries who gain access to domain-management permissions may disable the lock as a precursor to unauthorized domain transfer, takeover, or service disruption. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Route 53], [Use Case: Asset Visibility], [Tactic: Persistence], [Tactic: Resource Development], [Resources: Investigation Guide] |None |213 |<> |Identifies when an AWS Route 53 domain is transferred to another AWS account. Transferring a domain changes administrative control of the DNS namespace, enabling the receiving account to modify DNS records, route traffic, request certificates, and potentially hijack operational workloads. Adversaries who gain access to privileged IAM users or long-lived credentials may leverage domain transfers to establish persistence, redirect traffic, conduct phishing, or stage infrastructure for broader attacks. This rule detects successful domain transfer requests. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Route 53], [Use Case: Asset Visibility], [Tactic: Persistence], [Tactic: Resource Development], [Resources: Investigation Guide] |None |212 @@ -352,6 +358,8 @@ and their rule type is `machine_learning`. |<> |Identifies the addition of an expiration lifecycle configuration to an Amazon S3 bucket. S3 lifecycle rules can automatically delete or transition objects after a defined period. Adversaries can abuse them by configuring auto-deletion of logs, forensic evidence, or sensitive objects to cover their tracks. This rule detects the use of the PutBucketLifecycle or PutBucketLifecycleConfiguration APIs with Expiration parameters, which may indicate an attempt to automate the removal of data to hinder investigation or maintain operational secrecy after malicious activity. |[Domain: Cloud], [Platform: AWS], [Data Source: AWS CloudTrail], [Service: AWS S3], [Tactic: Defense Evasion], [Rule Type: Event Correlation (EQL)], [Resources: Investigation Guide] |None |9 +|<> |Detects when MFA Delete is disabled on an Amazon S3 bucket. MFA Delete is an additional layer of security for versioned S3 buckets that requires multi-factor authentication to permanently delete object versions or disable versioning. When MFA Delete is disabled, an adversary with S3 write access and a compromised long-term access key can permanently delete object versions, a critical step in ransomware attacks that target S3 versioning as a backup mechanism. MFA Delete is configured via PutBucketVersioning with the MfaDelete parameter set to Disabled. |[Domain: Cloud], [Platform: AWS], [Data Source: AWS CloudTrail], [Service: AWS S3], [Rule Type: Custom Query (KQL)], [Tactic: Impact], [Resources: Investigation Guide] |None |1 + |<> |Detects when an Amazon S3 bucket policy is modified to grant public access using a wildcard (Principal:"*") statement. This rule analyzes PutBucketPolicy events that include both Effect=Allow and Principal:"*" in the request parameters, indicating that permissions were extended to all identities, potentially making the bucket or its contents publicly accessible. Publicly exposing an S3 bucket is one of the most common causes of sensitive data leaks in AWS environments. Adversaries or misconfigurations can leverage this exposure to exfiltrate data, host malicious content, or collect credentials and logs left in open storage. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Threat Detection], [Tactic: Exfiltration], [Tactic: Collection], [Resources: Investigation Guide] |None |3 |<> |Detects when an Amazon S3 bucket policy is modified to share access with an external AWS account. This rule analyzes PutBucketPolicy events and compares the S3 bucket’s account ID to any account IDs referenced in the policy’s Effect=Allow statements. If the policy includes principals from accounts other than the bucket owner’s, the rule triggers an alert. This behavior may indicate an adversary backdooring a bucket for data exfiltration or cross-account persistence. For example, an attacker who compromises credentials could attach a policy allowing access from an external AWS account they control, enabling continued access even after credentials are rotated. Note: This rule will not alert if the account ID is part of the bucket’s name or appears in the resource ARN. Such cases are common in standardized naming conventions (e.g., “mybucket-123456789012”). To ensure full coverage, use complementary rules to monitor for suspicious PutBucketPolicy API requests targeting buckets with account IDs embedded in their names or resources. |[Domain: Cloud], [Platform: AWS], [Data Source: AWS CloudTrail], [Service: AWS S3], [Tactic: Collection], [Tactic: Exfiltration], [Rule Type: Event Correlation (EQL)], [Resources: Investigation Guide] |None |11 @@ -370,8 +378,12 @@ and their rule type is `machine_learning`. |<> |Identifies AWS CloudTrail events where an unauthenticated source is attempting to access an S3 bucket. This activity may indicate a misconfigured S3 bucket policy that allows public access to the bucket, potentially exposing sensitive data to unauthorized users. Adversaries can specify --no-sign-request in the AWS CLI to retrieve objects from an S3 bucket without authentication. This is a New Terms rule, which means it will trigger for each unique combination of the source.address and targeted bucket name that has not been seen making this API request. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon S3], [Use Case: Asset Visibility], [Resources: Investigation Guide], [Tactic: Collection] |None |9 +|<> |Detects when account-level email sending is explicitly enabled in Amazon SES, via the v1 UpdateAccountSendingEnabled API with Enabled: true or the v2 PutAccountSendingAttributes API with SendingEnabled: true. Account-level sending is commonly paused by an administrator, or by automation wired to CloudWatch reputation alarms when bounce or complaint rates rise. An attacker who compromises an AWS account may re-enable sending to restore a paused capability as part of phishing infrastructure setup, allowing bulk email under the victim organization's trusted sending domain. Neither API can resume sending that AWS itself has paused. |[Domain: Cloud], [Platform: AWS], [Data Source: AWS CloudTrail], [Service: AWS SES], [Rule Type: Custom Query (KQL)], [Tactic: Resource Development], [Resources: Investigation Guide] |None |1 + |<> |Detects an SES email identity being verified and subsequently deleted within a 30-minute window, performed by the same AWS identity. Amazon SES requires email addresses and domains to be verified before they can be used as senders. An adversary who obtains SES credentials may verify a domain or address they control, use it to send phishing or spam email, then delete the identity to remove evidence of the sending domain from the account's verified identity list. This verify-use-delete pattern is a recognized attacker technique for SES abuse. |[Domain: Cloud], [Platform: AWS], [Data Source: AWS CloudTrail], [Service: AWS SES], [Rule Type: ESQL], [Tactic: Resource Development], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |2 +|<> |Detects enumeration of Amazon Simple Email Service (SES) resources using long-term IAM access keys (AKIA* prefix). Long-term access keys are associated with IAM users and are the credential type most commonly exfiltrated from repositories, configuration files, and environment variables. An adversary who obtains a long-term key may enumerate SES to discover verified email identities, sending quotas, and DKIM/MAIL FROM domain configurations as a precursor to phishing or spam campaigns launched from the compromised account's verified domains. |[Domain: Cloud], [Platform: AWS], [Data Source: AWS CloudTrail], [Service: AWS SES], [Rule Type: Custom Query (KQL)], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 + |<> |Detects the first occurrence in 7 days of an AWS identity attaching the managed policy AmazonSESFullAccess to an IAM user, role, or group. AmazonSESFullAccess grants unrestricted permission to send email, manage identities and templates, manage suppression lists, and access SES account-level settings. Granting this policy to an unexpected IAM entity, particularly a newly created user or a role not previously associated with email operations, is a documented technique used by threat actors to establish phishing infrastructure on compromised AWS accounts, enabling them to send email on behalf of the victim organization's trusted sending domain. Using new terms on the calling identity suppresses recurring attachments by known email automation while surfacing identities performing this action for the first time. |[Domain: Cloud], [Platform: AWS], [Data Source: AWS], [Data Source: Amazon Web Services], [Service: AWS IAM], [Service: AWS SES], [Rule Type: New Terms], [Tactic: Persistence], [Tactic: Resource Development], [Resources: Investigation Guide] |None |1 |<> |Identifies when a user subscribes to an SNS topic using a new protocol type (ie. email, http, lambda, etc.). SNS allows users to subscribe to recieve topic messages across a broad range of protocols like email, sms, lambda functions, http endpoints, and applications. Adversaries may subscribe to an SNS topic to collect sensitive information or exfiltrate data via an external email address, cross-account AWS service or other means. This rule identifies a new protocol subscription method for a particular user. |[Domain: Cloud], [Platform: AWS], [Data Source: AWS CloudTrail], [Service: AWS SNS], [Tactic: Collection], [Tactic: Exfiltration], [Tactic: Impact], [Rule Type: New Terms], [Resources: Investigation Guide] |None |11 @@ -416,8 +428,12 @@ and their rule type is `machine_learning`. |<> |Identifies rapid secret retrieval activity from AWS Secrets Manager using the GetSecretValue or BatchGetSecretValue API actions. Adversaries who compromise an IAM user, instance role, or temporary credentials may attempt to enumerate or exfiltrate secrets in bulk to escalate privileges, move laterally, or gain persistence. This rule detects 20 or more unique secret retrievals by the same user identity within a short time window, which may indicate credential compromise or automated secret harvesting. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Secrets Manager], [Tactic: Credential Access], [Resources: Investigation Guide] |None |8 +|<> |Detects when AWS Security Hub is disabled in a region. Security Hub aggregates security findings from AWS services (GuardDuty, Inspector, Macie, IAM Access Analyzer) and third-party tools into a single pane of glass. Disabling it suppresses centralized finding aggregation and compliance checks, removing visibility into threats across the account. This action is a documented pre-ransomware and pre-exfiltration defense evasion technique. |[Domain: Cloud], [Platform: AWS], [Data Source: AWS CloudTrail], [Service: AWS Security Hub], [Rule Type: Custom Query (KQL)], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 + |<> |Identifies sensitive AWS IAM operations performed via AWS CloudShell based on the user agent string. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. While convenient for administrators, CloudShell access from compromised console sessions can enable attackers to perform privileged operations without installing tools or using programmatic credentials. This rule detects high-risk actions such as creating IAM users, access keys, roles, or attaching policies when initiated from CloudShell, which may indicate post-compromise credential harvesting or privilege escalation activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Tactic: Persistence], [Tactic: Privilege Escalation], [Use Case: Threat Detection], [Resources: Investigation Guide] |None |4 +|<> |Detects the first time an AWS identity requests a service quota increase via the AWS Service Quotas API within a 7-day history window. Service quota increases are submitted to AWS Support and, when approved, raise the limits on EC2 instances, Lambda concurrency, VPC resources, and other services. An adversary who obtains AWS credentials may request quota increases as infrastructure preparation for large-scale cryptomining, DDoS amplification, phishing campaigns, or data exfiltration operations that require compute or network resources beyond the account's current limits. |[Domain: Cloud], [Platform: AWS], [Data Source: AWS CloudTrail], [Service: AWS Service Quotas], [Rule Type: New Terms], [Tactic: Resource Development], [Resources: Investigation Guide] |None |1 + |<> |Identifies when a single AWS principal makes GetServiceQuota API calls for the EC2 service quota L-1216C47A, across more than 10 AWS regions within a 30-second window. This quota represents the vCPU limit for on-demand EC2 instances. Adversaries commonly enumerate this quota across regions to assess capacity for large-scale instance deployment, including cryptocurrency mining, malware hosting, or command-and-control infrastructure. This behavior may indicate cloud infrastructure discovery using compromised credentials or a compromised workload. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Service Quotas], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |11 |<> |Identifies when a federated user logs into the AWS Management Console. Federated users are typically given temporary credentials to access AWS services. If a federated user logs into the AWS Management Console without using MFA, it may indicate a security risk, as MFA adds an additional layer of security to the authentication process. However, CloudTrail does not record whether a Federated User utilized MFA as part of authentication — that MFA decision often occurs at a third-party IdP (e.g., Okta, Azure AD, Google). As a result, CloudTrail fields such as MFAUsed / mfaAuthenticated appear as “No/false” for federated console logins even if IdP MFA was required. This alert should be correlated with IdP authentication logs to verify whether MFA was enforced for the session. Increase priority if you find a related "GetSigninToken" event whose source IP / ASN / geo or user-agent differs from the subsequent "ConsoleLogin" (possible token relay/abuse). Same-IP/UA pairs within a short window are more consistent with expected operator behavior and can be triaged with lower severity. |[Domain: Cloud], [Data Source: Amazon Web Services], [Data Source: AWS], [Data Source: AWS Sign-In], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |7 @@ -438,9 +454,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: Corelight], [Data Source: PAN-OS], [Data Source: Network Traffic], [Data Source: Zeek] |None |112 +|<> |Specially crafted DNS requests can manipulate a known overflow vulnerability in some Windows DNS servers, resulting in Remote Code Execution (RCE) or a Denial of Service (DoS) from crashing the service. |[Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Impact], [Resources: Investigation Guide], [Use Case: Vulnerability], [Data Source: Corelight], [Data Source: PAN-OS], [Data Source: Network Traffic], [Data Source: Zeek] |None |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: Fortinet], [Data Source: PAN-OS], [Data Source: pfSense], [Data Source: SonicWall], [Data Source: Suricata], [Resources: Investigation Guide] |None |116 +|<> |This rule detects network events that may indicate the use of Telnet traffic. Telnet is commonly used by system administrators to remotely control older or embedded systems using the command line shell. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. As a plain-text protocol, it may also expose usernames and passwords to anyone capable of observing the traffic. |[Domain: Endpoint], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Lateral Movement], [Tactic: Initial Access], [Data Source: Fortinet], [Data Source: PAN-OS], [Data Source: pfSense], [Data Source: SonicWall], [Data Source: Suricata], [Resources: Investigation Guide] |None |117 |<> |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 @@ -580,6 +596,8 @@ and their rule type is `machine_learning`. |<> |Authorization plugins are used to extend the authorization services API and implement mechanisms that are not natively supported by the OS, such as multi-factor authentication with third party software. Adversaries may abuse this feature to persist and/or collect clear text credentials as they traverse the registered plugins during user logon. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |112 +|<> |Identifies the first time, in a historical window, a host runs AzCopy copy or sync to Azure Blob, Data Lake, or File storage, or starts Azure Storage Explorer. These Microsoft utilities are legitimate data-transfer tools; ransomware and cloud-ransomware operators drop portable copies and use SAS-authenticated jobs to pull data from victim storage and push it to attacker-controlled accounts. |[Domain: Endpoint], [OS: Windows], [Platform: Windows], [Use Case: Threat Detection], [Tactic: Exfiltration], [Tactic: Collection], [Tactic: Execution], [Rule Type: New Terms], [Threat: Rhysida], [Use Case: Ransomware], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike] |None |1 + |<> |Identifies Azure AD Graph (graph.windows.net) requests originating from user-agent strings associated with offensive tooling, scripting libraries, or generic HTTP clients. First-party Microsoft components calling AAD Graph identify with specific user agents such as "Microsoft Azure Graph Client Library", "Microsoft ADO.NET Data Services", or "Microsoft.OData.Client". Anything outside that recognised set is either a developer prototyping against the legacy API or an enumeration tool walking the directory. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |3 |<> |Identifies Azure AD Graph (graph.windows.net) requests where the combination of calling OAuth client ("azure.aadgraphactivitylogs.properties.app_id") and signed-in user ("user.id") has not been observed in the tenant in a historical window. A user appearing against AAD Graph under an OAuth client that has not previously authenticated that user is a sign of a FOCI swap, a phished refresh token being redeemed for a new client, or an adversary running tooling under a client identity the user does not normally use. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 @@ -680,6 +698,8 @@ and their rule type is `machine_learning`. |<> |Identifies unusual high-privileged access to Azure Storage Account keys by users with Owner, Contributor, or Storage Account Contributor roles. This technique was observed in STORM-0501 ransomware campaigns where compromised identities with high-privilege Azure RBAC roles retrieved access keys to perform unauthorized operations on Storage Accounts. Microsoft recommends using Shared Access Signature (SAS) models instead of direct key access for improved security. This rule detects when a user principal with high-privilege roles accesses storage keys for the first time in 7 days. |[Domain: Cloud], [Domain: Identity], [Use Case: Threat Detection], [Data Source: Azure], [Data Source: Azure Activity Logs], [Tactic: Credential Access], [Resources: Investigation Guide] |None |2 +|<> |Identifies the first time an Azure Storage resource receives an anonymous data-plane read (GetBlob and related Get or List operations). Anonymous requests are used to probe public containers and to test stolen blob URLs before a SAS is appended. First-seen resource ID keeps volume down while still covering WireServer-related probes of status or extension blobs. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure Platform Logs], [Platform: Azure], [Service: Azure Storage], [Use Case: Threat Detection], [Tactic: Discovery], [Tactic: Collection], [Resources: Investigation Guide] |None |1 + |<> |Identifies successful GetBlob operations on Azure Storage Accounts using AzCopy user agent with SAS token authentication. AzCopy is a command-line utility for copying data to and from Azure Storage. While legitimate for data migration, adversaries may abuse AzCopy with compromised SAS tokens to exfiltrate data from Azure Storage Accounts. This rule detects the first occurrence of GetBlob operations from a specific storage account using this pattern. |[Domain: Cloud], [Domain: Storage], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Azure Storage], [Use Case: Threat Detection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |3 |<> |Identifies retrieval of Azure VM boot diagnostics data ("MICROSOFT.COMPUTE/VIRTUALMACHINES/RETRIEVEBOOTDIAGNOSTICSDATA/ACTION") by an identity that has not performed this operation recently. Boot diagnostics expose the VM serial console log and a console screenshot, which frequently contain plaintext boot-time output such as credentials, tokens, cloud-init/agent secrets, and command history. An adversary with VM read/contributor rights can retrieve this data over the control plane, without logging into the guest or touching the network, to harvest credentials. |[Domain: Cloud], [Domain: Endpoint], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 @@ -702,6 +722,12 @@ and their rule type is `machine_learning`. |<> |Identifies a successful write to an Azure virtual machine resource ("MICROSOFT.COMPUTE/VIRTUALMACHINES/WRITE"). This operation is the parent action behind VM userData injection, where an adversary with VM contributor rights writes a base64 startup payload into the VM "userData" field that executes on the next reboot (a control-plane persistence technique requiring no guest access). The Azure activity log does not record the "userData" value or which property changed, so this behavior is indistinguishable from any other VM write at detection time. This is a building block rule and does not generate alerts on its own; it captures the VM write population so it can be correlated with other signals and baselined over time to tune a higher-fidelity userData-injection detection. To investigate a candidate, retrieve the live "userData" from the VM with an Azure Resource Manager GET using "$expand=userData". |[Domain: Cloud], [Domain: Endpoint], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Asset Visibility], [Tactic: Persistence], [Rule Type: BBR] |None |1 +|<> |Identifies HTTP requests to Azure WireServer (168.63.129.16) for GoalState, certificates, versions, or HostGAPlugin vmSettings that do not use a known guest-agent user agent. These requests retrieve transport certificates and extension protectedSettings, including embedded SAS URLs. Azure Linux Agent, Windows guest agent, and related platform UAs are excluded. Requests with no user agent are also excluded; that pattern is common for the Windows guest agent. |[Domain: Cloud], [Domain: Network], [OS: Linux], [OS: Windows], [Platform: Azure], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Discovery], [Data Source: Network Packet Capture], [Resources: Investigation Guide] |None |1 + +|<> |Identifies OpenSSL generating a CN=LinuxTransport certificate or decrypting CMS/PKCS7 payloads with a key that is not the Azure Linux Agent certificate under /var/lib/waagent. Adversaries can scrape WireServer certificates, mint a LinuxTransport identity, and decrypt extension protectedSettings with openssl cms -decrypt or smime -decrypt. |[Domain: Endpoint], [Domain: Cloud], [OS: Linux], [Use Case: Threat Detection], [Platform: Azure], [Platform: Linux], [Tactic: Credential Access], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1 + +|<> |Identifies shells, LOLBins, GTFOBins, and scripting runtimes connecting to the Azure WireServer / HostGAPlugin address 168.63.129.16 on ports 80 or 32526. The guest agent uses this fabric endpoint for GoalState, certificates, and vmSettings. Adversaries with code execution on an Azure VM (including via Run Command) use curl, PowerShell, openssl, bun, or similar tools to enumerate versions, pull transport certificates, and read HostGAPlugin /vmSettings. Azure guest-agent binaries and system python used by waagent are excluded. Descendants of the guest agent are not excluded: Run Command payloads execute in that tree. |[Domain: Endpoint], [Domain: Cloud], [OS: Linux], [OS: Windows], [Platform: Azure], [Platform: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1 + |<> |Detects execution of bpftool commands used to detach eBPF programs or links, or to delete or modify eBPF maps. These actions can disable, alter, or interfere with kernel-level instrumentation and enforcement mechanisms implemented through eBPF. In environments relying on eBPF-based networking, observability, or security controls, unexpected use of these operations may indicate defense evasion or runtime tampering. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Threat: Rootkit], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |2 |<> |Detects execution of bpftool commands used to load, attach, run, or pin eBPF programs, as well as create or update eBPF maps and links. These operations interact directly with the Linux eBPF subsystem and can modify kernel-level behavior. While commonly used by legitimate networking or observability tooling, unexpected or interactive usage may indicate eBPF-based rootkit activity, policy tampering, or unauthorized kernel instrumentation. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Threat: Rootkit], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |2 @@ -956,7 +982,7 @@ and their rule type is `machine_learning`. |<> |This rule correlates any Elastic Defend alert with an email security related alert by target user name. This may indicate the successful execution of a phishing attack. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Check Point Harmony Email & Collaboration], [Domain: Email], [Domain: Endpoint] |None |4 -|<> |This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto Networks (PANW) and Fortinet Fortigate by host.ip and source.ip. This may indicate that this host is compromised and triggering multi-datasource alerts. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Fortinet], [Data Source: PAN-OS] |None |7 +|<> |This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto Networks (PANW), Fortinet Fortigate and Suricata by host.ip and source.ip. This may indicate that this host is compromised and triggering multi-datasource alerts. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Fortinet], [Data Source: PAN-OS], [Data Source: Suricata] |None |8 |<> |Generates a detection alert for each Elastic Security alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Elastic Security alerts in the app. |[Data Source: Elastic Security], [Use Case: Threat Detection], [Resources: Investigation Guide], [Promotion: External Alerts] |None |2 @@ -990,6 +1016,10 @@ and their rule type is `machine_learning`. |<> |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 |2 +|<> |Detects a first-party FOCI tooling client (Azure CLI, PowerShell, VS Code, Graph CLI, Azure AD PowerShell, or Visual Studio) redeeming a device-bound Primary Refresh Token (PRT) for Microsoft Graph, SharePoint/OneDrive, or Exchange Online from an IP that is not among that user and device's Windows Sign-In or WAM addresses. Replay events are limited to compliant or Intune-managed devices: the stolen cookie keeps the workstation deviceid, so compliant-device Conditional Access can succeed off-box. |[Domain: Cloud], [Domain: Identity], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Platform: Entra ID], [Tactic: Credential Access], [Tactic: Defense Evasion], [Tactic: Initial Access], [Resources: Investigation Guide], [Rule Type: ESQL] |None |1 + +|<> |Detects a first-party FOCI tooling client (Azure CLI, PowerShell, VS Code, Graph CLI, Azure AD PowerShell, or Visual Studio) redeeming a device-bound Primary Refresh Token (PRT) for Microsoft Graph, SharePoint/OneDrive, or Exchange Online from a source IP that has not been seen with that deviceid. Replay events are limited to compliant or Intune-managed devices. Adversaries who steal a WAM PRT SSO cookie replay it off-box; the token keeps the workstation deviceid, so this pair is new even when Windows Sign-In for that device is outside a correlation window. |[Domain: Cloud], [Domain: Identity], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Platform: Entra ID], [Tactic: Credential Access], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Rule Type: New Terms] |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 @@ -1112,6 +1142,10 @@ and their rule type is `machine_learning`. |<> |Identifies when a Microsoft Entra ID user signs in from a device that is not typically used by the user and is not managed, which may indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a new device to obtain a Primary Refresh Token (PRT) and maintain persistent access. |[Domain: Cloud], [Domain: Identity], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Platform: Entra ID], [Resources: Investigation Guide] |None |4 +|<> |Identifies the first-seen registration of a Windows Hello for Business (WHfB) credential for a Microsoft Entra ID user from a given source ASN in a tenant, based on a prefixed historic window. Enrollment is commonly part of legitimate onboarding or passwordless rollout and is not inherently malicious. Adversaries who have obtained a token that satisfies fresh (NGC) multi-factor authentication, for example by borrowing an existing WHfB key or passkey, can also enroll their own WHfB credential to establish durable, phishing-resistant persistence that survives password resets and standard session revocation. Correlate first-seen enrollments with the sign-in and device state that preceded them. |[Domain: Cloud], [Domain: Identity], [Platform: Entra ID], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Persistence], [Rule Type: New Terms], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Resources: Investigation Guide] |None |1 + +|<> |Identifies a Microsoft Entra ID sign-in that is satisfied by a phishing-resistant, device-bound credential (Windows Hello for Business, FIDO2 security key, or passkey) while carrying no device identifier. Windows Hello for Business (WHfB) and passkey credentials are bound to a device's TPM, so a genuine sign-in with one of these methods is normally accompanied by the registered device it lives on. A WHfB or passkey assertion that authenticates with an empty `device_detail.device_id` indicates the underlying key material is being used away from its bound device, for example by an adversary who extracted the key (or signed an assertion with it) and replayed it from attacker infrastructure to mint device-agnostic tokens. This is the core primitive of the "borrowing Windows Hello keys" technique and is a strong precursor to attacker device registration and Primary Refresh Token (PRT) issuance. Cross-tenant (B2B) sign-ins are excluded because they are a common benign source of empty device identifiers. |[Domain: Cloud], [Domain: Identity], [Platform: Entra ID], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Initial Access], [Rule Type: New Terms], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Resources: Investigation Guide] |None |1 + |<> |Identifies the use of dsquery.exe for domain trust discovery purposes. Adversaries may use this command-line utility to enumerate trust relationships that may be used for Lateral Movement opportunities in Windows multi-domain forest environments. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [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 |215 |<> |Identifies the use of nltest.exe for domain trust discovery purposes. Adversaries may use this command-line utility to enumerate domain trusts and gain insight into trust relationships, as well as the state of Domain Controller (DC) replication in a Microsoft Windows NT Domain. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Data Source: Sysmon] |None |219 @@ -1224,6 +1258,8 @@ and their rule type is `machine_learning`. |<> |Identifies the creation or execution of files or processes with names containing the Right-to-Left Override (RTLO) character, which can be used to disguise the file extension and trick users into executing malicious files. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |5 +|<> |This rule detects when a web server process creates a file with a double extension, where the real extension is a non-web extension. This is a common technique used by attackers to bypass security measures and to hide the true nature of the file. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Use Case: Vulnerability], [Tactic: Persistence], [Tactic: Initial Access], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Rule Type: Event Correlation (EQL)], [Resources: Investigation Guide] |None |1 + |<> |Identifies unusual files downloaded from outside the local network that have the potential to be abused for code execution. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Rule Type: BBR] |None |6 |<> |Finder Sync plugins enable users to extend Finder’s functionality by modifying the user interface. Adversaries may abuse this feature by adding a rogue Finder Plugin to repeatedly execute malicious payloads for persistence. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |213 @@ -1248,6 +1284,10 @@ and their rule type is `machine_learning`. |<> |Detects a new user agent used for a GitHub user not previously seen in the last 14 days. |[Domain: Cloud], [Use Case: Threat Detection], [Use Case: UEBA], [Tactic: Initial Access], [Rule Type: BBR], [Data Source: Github] |None |207 +|<> |Identifies a NetFlow, IPFIX, or sFlow exporter IP that has not previously sent decoded flow records in the same data stream namespace during the prior 2 hours. This low-risk building-block signal records exporter novelty for correlation with later detection alerts in which the same address is the source of suspicious activity. |[Domain: Network], [Use Case: Network Security Monitoring], [Use Case: Threat Detection], [Rule Type: BBR], [Data Source: NetFlow], [Data Source: GoFlow2], [Resources: Investigation Guide] |None |2 + +|<> |Identifies a newly observed NetFlow, IPFIX, or sFlow exporter IP followed by another detection alert with medium-or-higher severity or an elevated risk score, where that exporter IP is the source of the detected activity in the same data stream namespace. This correlation adds behavioral evidence that can help distinguish routine exporter onboarding from a potentially unauthorized or compromised exporter introduced as part of defense evasion. |[Domain: Network], [Use Case: Network Security Monitoring], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Rule Type: Higher-Order Rule], [Data Source: Elastic Security], [Data Source: NetFlow], [Data Source: GoFlow2], [Resources: Investigation Guide] |None |2 + |<> |Identifies a successful SonicWall VPN- or WAN-zone administrator or remote-user login from a source IP that was not previously observed with the same user on the same appliance during the prior 14 days. This may indicate stolen credentials, compromised administrator access, or unauthorized remote access. |[Domain: Network], [Domain: Identity], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Data Source: SonicWall Firewall Logs], [Rule Type: New Terms], [Resources: Investigation Guide] |None |1 |<> |This rule detects the first time a principal calls AWS CloudFormation CreateStack, CreateStackSet or CreateStackInstances API. CloudFormation is used to create a collection of cloud resources called a stack, via a defined template file. An attacker with the appropriate privileges could leverage CloudFormation to create specific resources needed to further exploit the environment. This is a new terms rule that looks for the first instance of this behavior for a role or IAM user within a particular account. |[Domain: Cloud], [Platform: AWS], [Data Source: AWS CloudTrail], [Service: AWS CloudFormation], [Tactic: Execution], [Rule Type: New Terms], [Resources: Investigation Guide] |None |9 @@ -1430,7 +1470,7 @@ and their rule type is `machine_learning`. |<> |Detects the first time a human GKE caller lists secrets cluster-wide or in default or kube-system from a source autonomous system that is not attributed to common cloud provider organizations. This can indicate remote secret enumeration using stolen credentials from an unusual network. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 -|<> |Detects when the same GKE identity creates or modifies a Role or ClusterRole with high-risk permissions (wildcard access, RBAC escalation verbs, or access to secrets / privileged APIs) and also creates or patches a DaemonSet, Deployment, or CronJob within five minutes. This correlation is consistent with RBAC-based privilege escalation followed by payload deployment. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 +|<> |Detects when the same GKE identity creates or modifies a Role or ClusterRole with high-risk permissions (wildcard access, RBAC escalation verbs, or access to secrets / privileged APIs) and also creates or patches a DaemonSet, Deployment, or CronJob within five minutes. This correlation is consistent with RBAC-based privilege escalation followed by payload deployment. |[Domain: Cloud], [Domain: Kubernetes], [Domain: Containers], [Data Source: GCP], [Data Source: Google Cloud Platform], [Data Source: GCP Audit Logs], [Platform: GCP], [Platform: Kubernetes], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide], [Rule Type: ESQL] |None |2 |<> |Detects write operations performed by GKE service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse or unauthorized privilege escalation. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 @@ -1778,7 +1818,7 @@ and their rule type is `machine_learning`. |<> |This rule detects the creation or modification of sensitive Kubernetes configuration files on Linux systems. These files include Kubernetes manifests, PKI files, and configuration files that are critical for the operation of Kubernetes clusters. Monitoring these files helps identify potential unauthorized changes or misconfigurations that could lead to security vulnerabilities in Kubernetes environments. Attackers may attempt to modify these files to gain persistence or to deploy malicious containers within the Kubernetes cluster. |[Domain: Endpoint], [Domain: Kubernetes], [Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 -|<> |Detects a sequence where a principal creates or modifies a Role/ClusterRole to include high-risk permissions (e.g., wildcard access or escalation verbs) and then creates or patches a workload resource (DaemonSet, Deployment, or CronJob) shortly after, which may indicate RBAC-based privilege escalation followed by payload deployment. This pattern is often used by adversaries to gain unauthorized access to sensitive resources and deploy malicious payloads. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |3 +|<> |Detects a sequence where a principal creates or modifies a Role/ClusterRole to include high-risk permissions (e.g., wildcard access or escalation verbs) and then creates or patches a workload resource (DaemonSet, Deployment, or CronJob) shortly after, which may indicate RBAC-based privilege escalation followed by payload deployment. This pattern is often used by adversaries to gain unauthorized access to sensitive resources and deploy malicious payloads. |[Data Source: Kubernetes], [Data Source: Kubernetes API Server Audit Logs], [Domain: Containers], [Domain: Kubernetes], [Platform: Kubernetes], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide], [Rule Type: Event Correlation (EQL)] |None |4 |<> |Detects write operations performed by Kubernetes service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse, misconfigured permissions, or unauthorized privilege escalation. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |3 @@ -1808,7 +1848,7 @@ and their rule type is `machine_learning`. |<> |Identifies suspicious file creations in the startup folder of a remote system. An adversary could abuse this to move laterally by dropping a malicious script or executable that will be executed after a reboot or user logon. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |315 -|<> |An adversary can establish persistence by installing a new launch agent that executes at login by using launchd or launchctl to load a plist into the appropriate directories. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |112 +|<> |An adversary can establish persistence by installing a new launch agent that executes at login by using launchd or launchctl to load a plist into the appropriate directories. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |113 |<> |This rule monitors for the usage of the most common audio recording utilities on unix systems by an uncommon process parent. Adversaries may collect audio data from users or systems for a variety of reasons including espionage, credential theft, or reconnaissance. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Collection], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |2 @@ -1816,6 +1856,8 @@ and their rule type is `machine_learning`. |<> |Detects applications making a curl request to a known public IP address lookup web service. Malware tends to perform this action to assess potential targets. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |1 +|<> |Adversaries may create or modify Linux firewall rules with DROP, ACCEPT, or REJECT actions to affect how a host receives or sends network traffic. This activity may be used to bypass security controls, block defensive tooling, or gain unauthorized access to the network. |[Domain: Endpoint], [OS: Linux], [Platform: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Auditd Manager], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide], [Rule Type: Event Correlation (EQL)] |None |1 + |<> |Identifies attempts to create a new group. Attackers may create new groups to establish persistence on a system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |11 |<> |This rule monitors for potential memory dumping through gdb. Attackers may leverage memory dumping techniques to attempt secret extraction from privileged processes. Tools that display this behavior include "truffleproc" and "bash-memory-dump". This behavior should not happen by default, and should be investigated thoroughly. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |108 @@ -1916,13 +1958,13 @@ and their rule type is `machine_learning`. |<> |Identifies the first occurrence of SSO, SAML, or federated authentication errors for a user. These errors may indicate token manipulation, SAML assertion tampering, or OAuth phishing attempts. Modern adversaries often target SSO mechanisms through token theft, SAML response manipulation, or exploiting federated authentication weaknesses rather than traditional brute force attacks. |[Domain: Identity], [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] |None |215 -|<> |Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |9 +|<> |Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |10 -|<> |Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |418 +|<> |Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |419 |<> |Identifies the occurrence of files uploaded to OneDrive being detected as Malware by the file scanning engine. Attackers can use File Sharing and Organization Repositories to spread laterally within the company and amplify their access. Users can inadvertently share these files without knowing their maliciousness, giving adversaries an opportunity to gain initial access to other endpoints in the environment. |[Domain: Cloud], [Data Source: Microsoft 365], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |213 -|<> |Identifies when an excessive number of files are downloaded from OneDrive or SharePoint by an authorized user or application in a short period of time. This may indicate a potential data exfiltration event, especially if the downloads are performed using OAuth authentication which could suggest an OAuth phishing attack such as Device Code Authentication phishing. |[Domain: Cloud], [Domain: SaaS], [Domain: Storage], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Data Source: SharePoint], [Data Source: OneDrive], [Use Case: Threat Detection], [Tactic: Collection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |9 +|<> |Identifies when an excessive number of files are downloaded from OneDrive or SharePoint by an authorized user or application in a short period of time. This may indicate a potential data exfiltration event, especially if the downloads are performed using OAuth authentication which could suggest an OAuth phishing attack such as Device Code Authentication phishing. |[Domain: Cloud], [Domain: SaaS], [Domain: Storage], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Data Source: SharePoint], [Data Source: OneDrive], [Use Case: Threat Detection], [Tactic: Collection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |10 |<> |Detects Microsoft 365 audit "UserLoggedIn" events consistent with Tycoon 2FA phishing-as-a-service (PhaaS) adversary-in-the-middle (AiTM) activity: the Microsoft Authentication Broker requesting access where the object identifier matches Microsoft Graph or Exchange Online, or the Office web client application authenticating to itself, combined with Node.js-style user agents (node, axios, undici). Tycoon 2FA bypasses MFA by relaying authentication and capturing session material, often targeting Microsoft 365 and Gmail. Baseline legitimate automation and developer tooling before tuning. |[Domain: Cloud], [Domain: Identity], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Threat: Tycoon2FA], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 @@ -1948,7 +1990,7 @@ and their rule type is `machine_learning`. |<> |Identifies when custom applications are allowed in Microsoft Teams. If an organization requires applications other than those available in the Teams app store, custom applications can be developed as packages and uploaded. An adversary may abuse this behavior to establish persistence in an environment. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |214 -|<> |Identifies a one-on-one Microsoft Teams chat created by a user from a foreign tenant whose display name, member profile, or email local-part resembles IT help desk or Microsoft security staff. Adversaries abuse cross-tenant Teams external access to impersonate support personnel and socially engineer victims into granting remote access or disclosing credentials. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |1 +|<> |Identifies a one-on-one Microsoft Teams chat created by a user from a foreign tenant whose display name, member profile, or email local-part resembles IT help desk or Microsoft security staff. Adversaries abuse cross-tenant Teams external access to impersonate support personnel and socially engineer victims into granting remote access or disclosing credentials. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |2 |<> |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 @@ -2072,7 +2114,7 @@ and their rule type is `machine_learning`. |<> |Correlates process telemetry for shells and major cloud/Kubernetes CLIs when command lines match token or credential material access patterns (GCP, Azure, AWS, GitHub, kubectl, DigitalOcean, OCI). Flags hosts where multiple cloud targets appear within a five-minute window. |[Domain: Endpoint], [Domain: Cloud], [OS: Windows], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Sysmon], [Resources: Investigation Guide] |None |1 -|<> |This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |9 +|<> |This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |10 |<> |This rule correlates multiple security alerts associated with the same ATT&CK tactic on a single host within a defined time window. By requiring alerts from multiple distinct detection rules, this detection helps identify hosts exhibiting concentrated malicious behavior, which may indicate an active intrusion or post-compromise activity. The rule is intended to assist analysts in prioritizing triage toward hosts with higher likelihood of compromise rather than signaling a single discrete event. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |5 @@ -2130,7 +2172,7 @@ and their rule type is `machine_learning`. |<> |This rule monitors for the execution of the cat command, followed by a connection attempt by the same process. Cat is capable of transfering data via tcp/udp channels by redirecting its read output to a /dev/tcp or /dev/udp channel. This activity is highly suspicious, and should be investigated. Attackers may leverage this capability to transfer tools or files to another host in the network or exfiltrate data while attempting to evade detection in the process. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |12 -|<> |Identifies DNS queries to commonly abused Top Level Domains by common LOLBINs or executables running from world writable directories or unsigned binaries. This behavior matches on common malware C2 abusing less formal domain names. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Data Source: Sysmon] |None |4 +|<> |Identifies DNS queries to commonly abused Top Level Domains by common LOLBINs or executables running from world writable directories or unsigned binaries. This behavior matches on common malware C2 abusing less formal domain names. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Data Source: Sysmon] |None |5 |<> |Detects network connections originating from a binary located in a potentially suspicious location, followed by a file creation event. This behavior is consistent with C2 agents such as Poseidon and Athena, connecting to a C2 framework such as Mythic. The agent polls the C2 for commands through a web request, after which the command gets executed. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1 @@ -2190,7 +2232,7 @@ and their rule type is `machine_learning`. |<> |This rule detects Suricata high severity alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Network], [Data Source: Suricata] |None |3 -|<> |This rule identifies outbound IPSEC NAT Traversal (NAT-T) traffic to an external destination IP that was not observed during the previous 5 days. IPSEC is a VPN technology that allows one system to talk to another using encrypted tunnels. NAT Traversal encapsulates IPSEC ESP traffic in UDP and, once a NAT device is detected, both peers float to UDP port 4500 for the tunnel data channel. Newly observed external NAT-T peers may indicate unauthorized VPN use or an adversary tunneling command and control or exfiltration traffic over the Internet. |[Tactic: Command and Control], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: PAN-OS], [Data Source: Network Traffic], [Data Source: pfSense], [Data Source: Zeek], [Resources: Investigation Guide] |None |113 +|<> |This rule identifies outbound IPSEC NAT Traversal (NAT-T) traffic to an external destination IP that was not observed during the previous 5 days. IPSEC is a VPN technology that allows one system to talk to another using encrypted tunnels. NAT Traversal encapsulates IPSEC ESP traffic in UDP and, once a NAT device is detected, both peers float to UDP port 4500 for the tunnel data channel. Newly observed external NAT-T peers may indicate unauthorized VPN use or an adversary tunneling command and control or exfiltration traffic over the Internet. |[Tactic: Command and Control], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: PAN-OS], [Data Source: Network Traffic], [Data Source: pfSense], [Data Source: Zeek], [Resources: Investigation Guide] |None |114 |<> |This rule detects Palo Alto Network alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Network], [Data Source: PAN-OS] |None |4 @@ -2200,6 +2242,8 @@ and their rule type is `machine_learning`. |<> |Detects when the ScreenConnect client (ConnectWise Control) connects to a newly observed host server that is not the official ScreenConnect cloud. ScreenConnect is a common RMM/remote access tool abused for C2 and persistence. Self-hosted or non-standard relay servers may indicate abuse or compromise. The rule aggregates by server host (parsed from the client command line), requires first-time observation within the rule window, and limits to a single host to reduce noise. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |4 +|<> |Identifies newly observed execution of SoftPerfect Network Scanner or Advanced IP/Port Scanner on a Windows host. Adversaries commonly use these legitimate scanners during post-compromise discovery to map live hosts, open ports, and reachable systems, then select targets for lateral movement. |[Domain: Endpoint], [OS: Windows], [Platform: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: New Terms], [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 |1 + |<> |This rule detects the execution of Node.js pre or post-install scripts. These scripts are executed by the Node.js package manager (npm) during the installation of packages. Adversaries may abuse this technique to execute arbitrary commands on the system and establish persistence. This activity was observed in the wild as part of the Shai-Hulud worm. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike], [Data Source: SentinelOne] |None |4 |<> |Nping ran on a Linux host. Nping is part of the Nmap tool suite and has the ability to construct raw packets for a wide variety of security testing applications, including denial of service testing. |[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 |213 @@ -2292,7 +2336,7 @@ and their rule type is `machine_learning`. |<> |Detects the successful hijack of Microsoft Compatibility Appraiser scheduled task to establish persistence with an integrity level of system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |318 -|<> |Identifies potential hijacking of the Microsoft Update Orchestrator Service to establish persistence with an integrity level of SYSTEM. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Use Case: Vulnerability], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: Windows Security Event Logs], [Data Source: SentinelOne] |None |319 +|<> |Identifies potential hijacking of the Microsoft Update Orchestrator Service to establish persistence with an integrity level of SYSTEM. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Use Case: Vulnerability], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne] |None |320 |<> |An adversary can use Windows Management Instrumentation (WMI) to install event filters, providers, consumers, and bindings that execute code when a defined event occurs. Adversaries may use the capabilities of WMI to subscribe to an event and execute arbitrary code when that event occurs, providing persistence on a system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [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 |319 @@ -2412,7 +2456,7 @@ and their rule type is `machine_learning`. |<> |A machine learning job has detected data exfiltration to a particular geo-location (by region name). Data transfers to geo-locations that are outside the normal traffic patterns of an organization could indicate exfiltration over command and control channels. |[Use Case: Data Exfiltration Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |7 -|<> |Detects the use of curl to upload files to an internet server. Threat actors often will collect and exfiltrate data on a system to their C2 server for review. Many threat actors have been observed using curl to upload the collected data. Use of curl in this way, while not inherently malicious, should be considered highly abnormal and suspicious activity. |[Domain: Endpoint], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Exfiltration], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Sysmon], [Data Source: Auditd Manager], [Data Source: Windows Security Event Logs] |None |9 +|<> |Detects the use of curl to upload files to an internet server. Threat actors often will collect and exfiltrate data on a system to their C2 server for review. Many threat actors have been observed using curl to upload the collected data. Use of curl in this way, while not inherently malicious, should be considered highly abnormal and suspicious activity. |[Domain: Endpoint], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Exfiltration], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Sysmon], [Data Source: Auditd Manager], [Data Source: Windows Security Event Logs] |None |10 |<> |Detects the use of wget to upload files to an internet server. Threat actors often will collect data on a system and attempt to exfiltrate it back to their command and control servers. Use of wget in this way, while not inherently malicious, should be considered highly abnormal and suspicious activity. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Exfiltration], [Data Source: Auditd Manager], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |3 @@ -2442,11 +2486,15 @@ and their rule type is `machine_learning`. |<> |Identifies the Windows Error Reporting Protected Process Light (PPL) binary WerFaultSecure.exe being started by a process other than the Windows Error Reporting service, with command-line arguments used to take a secure memory dump of a target process. Because MiniDumpWriteDump suspends all threads of the target while the dump is produced, an attacker can suspend WerFaultSecure.exe mid-dump to leave the targeted EDR or antivirus suspended ("frozen") without ever terminating it, a defense-evasion technique publicly known as EDR-Freeze. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |1 +|<> |Identifies anomalous execution of BrowserCore.exe, the Windows component used by Chromium-based browsers for native messaging with the Web Account Manager (WAM). Adversaries abuse BrowserCore to extract Entra ID Primary Refresh Tokens (PRTs) without interactive browser context, enabling session hijacking. Legitimate BrowserCore launches carry a chrome-extension:// argument from the browser native-messaging host. |[Domain: Endpoint], [OS: Windows], [Platform: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Rule Type: ESQL], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Windows Security Event Logs], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR] |None |2 + |<> |Identifies processes loading Active Directory related modules followed by a network connection to the ADWS dedicated TCP port. Adversaries may abuse the ADWS Windows service that allows Active Directory to be queried via this web service. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |7 |<> |Identifies when a browser process navigates to the Microsoft Help page followed by spawning an elevated process. This may indicate a successful exploitation for privilege escalation abusing a vulnerable Windows Installer repair setup. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Resources: Investigation Guide] |None |207 -|<> |Detects when a scripting interpreter makes an outbound network connection to an Ethereum blockchain endpoint for command and control purposes. Adversaries may leverage Ethereum blockchain infrastructure as a covert C2 channel to receive commands and exfiltrate data, as observed in campaigns like SleepyDuck malware. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 +|<> |Detects when curl or nscurl is spawned by a shell or osascript to make a JSON-RPC request to a blockchain endpoint for command and control purposes. Adversaries may leverage blockchain smart contracts as a covert C2 channel to retrieve commands or payload staging information, as observed in ClickFix campaigns. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1 + +|<> |Detects when a scripting interpreter makes an outbound network connection to an Ethereum blockchain endpoint for command and control purposes. Adversaries may leverage Ethereum blockchain infrastructure as a covert C2 channel to receive commands and exfiltrate data, as observed in campaigns like SleepyDuck malware. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |3 |<> |Identifies creation of a ":changelist" NTFS alternate data stream or a Windows service Args registry value pointing to a ":changelist" path. Microsoft Defender's Boot-Time Removal (BTR.sys) driver reads an RC4-encrypted transaction blob from a driver ADS named ":changelist", referenced by HKLM\SYSTEM\*ControlSet*\Services\*\Args. Adversaries can reproduce this staging outside Defender to abuse BTR.sys as a signed kernel primitive for arbitrary file and registry operations. This rule focuses on non-System writers and excludes Microsoft-signed MRT.exe running as SYSTEM, which may perform related remediation staging. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |2 @@ -2472,6 +2520,8 @@ and their rule type is `machine_learning`. |<> |Identifies Curl for Windows making an HTTP request. Adversaries could abuse Curl to download files or upload data to a remote URL. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Data Source: Sysmon], [Resources: Investigation Guide] |None |8 +|<> |This rule identifies potential fileless ELF execution where a process is launched from an anonymous temporary executable path that appears as "/#" in "process.executable". This pattern may be associated with "O_TMPFILE" and "execveat" with "AT_EMPTY_PATH", which can allow execution without a normal filesystem pathname. |[Domain: Endpoint], [OS: Linux], [Platform: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Rule Type: Event Correlation (EQL)], [Data Source: Auditd Manager], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |1 + |<> |Identifies the Foxmail client spawning a child process with arguments pointing to user-profile AppData paths or remote shares. This may indicate exploitation of a Foxmail vulnerability for initial access and execution via a malicious email. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Windows Security Event Logs], [Data Source: Elastic Endgame], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |209 |<> |This rule detects potential exploitation of CVE-2025-48384 via Git. This vulnerability allows attackers to execute arbitrary code by leveraging Git's recursive clone feature to fetch and execute malicious scripts from a remote repository. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |2 @@ -2524,7 +2574,7 @@ and their rule type is `machine_learning`. |<> |Identifies the execution of the unshadow utility which is part of John the Ripper, a password-cracking tool on the host machine. Malicious actors can use the utility to retrieve the combined contents of the '/etc/shadow' and '/etc/password' files. Using the combined file generated from the utility, the malicious threat actors can use them as input for password-cracking utilities or prepare themselves for future operations by gathering credential information of the victim. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |114 -|<> |Monitors for the execution of different processes that might be used by attackers for malicious intent. An alert from this rule should be investigated further, as hack tools are commonly used by blue teamers and system administrators as well. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |109 +|<> |Monitors for the execution of different processes that might be used by attackers for malicious intent. An alert from this rule should be investigated further, as hack tools are commonly used by blue teamers and system administrators as well. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |110 |<> |Identifies multiple consecutive login attempts executed by one process targeting a local linux user account within a short time interval. Adversaries might brute force login attempts across different users with a default wordlist or a set of customly crafted passwords in an attempt to gain access to these accounts. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |15 @@ -2568,7 +2618,7 @@ and their rule type is `machine_learning`. |<> |Identifies registry modification to force the system to fall back to NTLMv1 for authentication. This modification is possible with local administrator privileges and is commonly referred to as a `NetNTLMv1 downgrade attack`. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Sysmon], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |5 -|<> |This rule identifies a potential port scan from an internal IP address. A port scan is a method utilized by attackers to systematically scan a target system for open ports, allowing them to identify available services and potential vulnerabilities. By mapping out the open ports, attackers can gather critical information to plan and execute targeted attacks, gaining unauthorized access, compromising security, and potentially leading to data breaches, unauthorized control, or further exploitation of the targeted system. This rule defines a threshold-based approach to detect connection attempts from a single internal source to a wide range of destination ports on a single destination. |[Domain: Network], [Tactic: Discovery], [Tactic: Reconnaissance], [Use Case: Network Security Monitoring], [Data Source: PAN-OS], [Resources: Investigation Guide] |None |15 +|<> |This rule identifies a potential port scan from an internal IP address. A port scan is a method utilized by attackers to systematically scan a target system for open ports, allowing them to identify available services and potential vulnerabilities. By mapping out the open ports, attackers can gather critical information to plan and execute targeted attacks, gaining unauthorized access, compromising security, and potentially leading to data breaches, unauthorized control, or further exploitation of the targeted system. This rule defines a threshold-based approach to detect connection attempts from a single internal source to a wide range of destination ports on a single destination. |[Domain: Network], [Tactic: Discovery], [Tactic: Reconnaissance], [Use Case: Network Security Monitoring], [Data Source: PAN-OS], [Resources: Investigation Guide] |None |16 |<> |This threshold rule monitors for the rapid execution of unix utilities that are capable of conducting network scans. Adversaries may leverage built-in tools such as ping, netcat or socat to execute ping sweeps across the network while attempting to evade detection or due to the lack of network mapping tools available on the compromised host. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |8 @@ -2750,11 +2800,13 @@ and their rule type is `machine_learning`. |<> |Identifies potential SQL injection attempts against Microsoft SQL Server by detecting obfuscated T-SQL patterns in SQL Server Audit events. Attackers use CHAR concatenation, CONVERT-based subqueries, and CASE/UNION constructs to bypass input validation and extract data or execute unauthorized statements. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Data Source: Windows Application Event Logs], [Resources: Investigation Guide] |None |2 +|<> |Identifies a high number of failed inbound SSH authentication attempts on a macOS host within a short time window, using sshd authentication messages collected by the macOS Security Events integration. Adversaries may perform password brute force or password spraying against exposed SSH services to obtain unauthorized access. |[OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: macOS Security Events], [Resources: Investigation Guide] |None |2 + |<> |Detects potential SSH password grabbing via the use of strace on sshd processes. Attackers may use strace to capture sensitive information, such as passwords, by tracing system calls made by the sshd process. This rule looks for a sequence of events where an sshd process ends followed closely by the start of a strace process. This may be indicative of an attacker attempting to capture SSH credentials. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |3 |<> |Identifies the use of Windows OpenSSH or Plink to create a reverse SSH port forward or reverse dynamic SOCKS proxy. Adversaries may abuse reverse forwarding to expose an internal service or proxy listener through an external SSH server, establishing an outbound tunnel that bypasses direct inbound connectivity controls. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Windows Security Event Logs], [Data Source: Crowdstrike], [Data Source: Sysmon], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |2 -|<> |This rule identifies a potential SYN-Based port scan. A SYN port scan is a technique employed by attackers to scan a target network for open ports by sending SYN packets to multiple ports and observing the response. Attackers use this method to identify potential entry points or services that may be vulnerable to exploitation, allowing them to launch targeted attacks or gain unauthorized access to the system or network, compromising its security and potentially leading to data breaches or further malicious activities. This rule defines a threshold-based approach to detect connection attempts from a single source to a large number of unique destination ports, while limiting the number of packets per port. |[Domain: Network], [Tactic: Discovery], [Tactic: Reconnaissance], [Use Case: Network Security Monitoring], [Data Source: PAN-OS], [Resources: Investigation Guide] |None |14 +|<> |This rule identifies a potential SYN-Based port scan. A SYN port scan is a technique employed by attackers to scan a target network for open ports by sending SYN packets to multiple ports and observing the response. Attackers use this method to identify potential entry points or services that may be vulnerable to exploitation, allowing them to launch targeted attacks or gain unauthorized access to the system or network, compromising its security and potentially leading to data breaches or further malicious activities. This rule defines a threshold-based approach to detect connection attempts from a single source to a large number of unique destination ports, while limiting the number of packets per port. |[Domain: Network], [Tactic: Discovery], [Tactic: Reconnaissance], [Use Case: Network Security Monitoring], [Data Source: PAN-OS], [Resources: Investigation Guide] |None |15 |<> |This rule detects the execution of Gitleaks, a tool used to search for high-entropy strings and secrets in code repositories, which may indicate an attempt to access credentials. |[Domain: Endpoint], [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 |3 @@ -2776,6 +2828,8 @@ and their rule type is `machine_learning`. |<> |Identifies multiple SSH login failures followed by a successful one from the same source address. Adversaries can attempt to login into multiple users with a common or known password to gain access to accounts. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |16 +|<> |Identifies a burst of failed inbound SSH authentication attempts on a macOS host followed shortly by a successful SSH authentication on the same host, using sshd authentication messages collected by the macOS Security Events integration. A successful login immediately after repeated failures indicates that a password brute force or password spraying attack against an exposed SSH service has likely succeeded. |[OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Initial Access], [Data Source: macOS Security Events], [Resources: Investigation Guide] |None |1 + |<> |Identifies the creation of a sudo binary located at /usr/bin/sudo. Attackers may hijack the default sudo binary and replace it with a custom binary or script that can read the user's password in clear text to escalate privileges or enable persistence onto the system every time the sudo binary is executed. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |113 |<> |This rule monitors for the execution of a suspicious sudo command that is leveraged in CVE-2019-14287 to escalate privileges to root. Sudo does not verify the presence of the designated user ID and proceeds to execute using a user ID that can be chosen arbitrarily. By using the sudo privileges, the command "sudo -u#-1" translates to an ID of 0, representing the root user. This exploit may work for sudo versions prior to v1.28. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Use Case: Vulnerability], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |110 @@ -2946,9 +3000,9 @@ and their rule type is `machine_learning`. |<> |Identifies the use of osascript to execute scripts via standard input that may prompt a user with a rogue dialog for credentials. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |215 -|<> |Identifies remote access to the Windows Protected Storage Service through the IPC$ share. Attackers may abuse this named pipe to interact with the Protected Storage Service and extract sensitive credentials, certificates, or DPAPI backup keys. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Lateral Movement], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs] |None |1 +|<> |Identifies remote access to the Windows Protected Storage Service through the IPC$ share. Attackers may abuse this named pipe to interact with the Protected Storage Service and extract sensitive credentials, certificates, or DPAPI backup keys. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Lateral Movement], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs] |None |2 -|<> |Identifies abuse of the Console Window Host (conhost.exe) to execute commands via proxy. This behavior is used as a defense evasion technique to blend-in malicious activity with legitimate Windows software. |[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], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |4 +|<> |Identifies abuse of the Console Window Host (conhost.exe) to execute commands via proxy. This behavior is used as a defense evasion technique to blend-in malicious activity with legitimate Windows software. |[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], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |5 |<> |Identifies attempts to execute commands via proxy using the Windows OpenSSH client. This may indicate an attempt to bypass application control via trusted Windows binaries. |[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], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |3 @@ -2976,7 +3030,7 @@ and their rule type is `machine_learning`. |<> |This rule detects network events that may indicate the use of RPC traffic from the Internet. RPC is commonly used by system administrators to remotely control a system for maintenance or to use shared resources. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. |[Tactic: Initial Access], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: Corelight], [Data Source: Fortinet], [Data Source: Network Traffic], [Data Source: PAN-OS], [Data Source: pfSense], [Data Source: Zeek], [Resources: Investigation Guide] |None |113 -|<> |This rule detects network events that may indicate the use of RPC traffic to the Internet. RPC is commonly used by system administrators to remotely control a system for maintenance or to use shared resources. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. |[Tactic: Initial Access], [Tactic: Lateral Movement], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: Corelight], [Data Source: Fortinet], [Data Source: PAN-OS], [Data Source: Network Traffic], [Data Source: pfSense], [Data Source: Zeek], [Resources: Investigation Guide] |None |112 +|<> |This rule detects network events that may indicate the use of RPC traffic to the Internet. RPC is commonly used by system administrators to remotely control a system for maintenance or to use shared resources. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. |[Tactic: Initial Access], [Tactic: Lateral Movement], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: Corelight], [Data Source: Fortinet], [Data Source: PAN-OS], [Data Source: Network Traffic], [Data Source: pfSense], [Data Source: Zeek], [Resources: Investigation Guide] |None |113 |<> |This rule leverages the new_terms rule type to identify the installation of RPM packages by an unusual parent process. RPM is a package management system used in Linux systems such as Red Hat, CentOS and Fedora. Attacks may backdoor RPM packages to gain initial access or install malicious RPM packages to maintain persistence. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6 @@ -3030,7 +3084,7 @@ and their rule type is `machine_learning`. |<> |This rule detects the configuration of a GitHub Actions self-hosted runner using the Runner.Listener binary. When a machine is registered to a remote repository, its owner gains the ability to execute arbitrary workflow commands on that host. Unexpected or unauthorized runner registration may indicate adversarial activity aimed at establishing remote code execution via malicious GitHub workflows. |[Domain: Endpoint], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Initial 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 |3 -|<> |Detects an MSI installer execution followed by the execution of commonly abused Remote Management Software like ScreenConnect. This behavior may indicate abuse where an attacker triggers an MSI install then connects via a guest link with a known session key. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Data Source: Windows Security Event Logs], [Data Source: Elastic Endgame] |None |4 +|<> |Detects an MSI installer execution followed by the execution of commonly abused Remote Management Software like ScreenConnect. This behavior may indicate abuse where an attacker triggers an MSI install then connects via a guest link with a known session key. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Data Source: Windows Security Event Logs], [Data Source: Elastic Endgame] |None |5 |<> |Detects use of the systemsetup command to enable remote SSH Login. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |113 @@ -3264,7 +3318,7 @@ and their rule type is `machine_learning`. |<> |A sudoers file specifies the commands that users or groups can run and from which terminals. Adversaries can take advantage of these configurations to execute commands as other users or spawn processes with higher privileges. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |211 -|<> |This detection correlates Suricata alerts with Elastic Defend network events to identify the source process performing the network activity. |[Domain: Endpoint], [Domain: Network], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Suricata], [Resources: Investigation Guide] |None |4 +|<> |This detection correlates Suricata alerts with Elastic Defend network events to identify the source process performing the network activity. |[Domain: Endpoint], [Domain: Network], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Suricata], [Resources: Investigation Guide] |None |5 |<> |Detects potential lateral movement or post-compromise activity by correlating alerts where the host.ip of one alert matches the source.ip of a subsequent alert. This behavior may indicate a compromised host being used to authenticate to another system or resource, including cloud services. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |4 @@ -3572,7 +3626,7 @@ and their rule type is `machine_learning`. |<> |Detects the usage of commonly used system time discovery techniques, which attackers may use during the reconnaissance phase after compromising a system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Rule Type: BBR], [Data Source: Windows Security Event Logs] |None |114 -|<> |Files that are placed in the "/etc/init.d/" directory in Unix can be used to start custom applications, services, scripts or commands during start-up. Init.d has been mostly replaced in favor of Systemd. However, the "systemd-sysv-generator" can convert init.d files to service unit files that run at boot. Adversaries may add or alter files located in the "/etc/init.d/" directory to execute malicious code upon boot in order to gain persistence on the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: SentinelOne] |None |119 +|<> |Files that are placed in the "/etc/init.d/" directory in Unix can be used to start custom applications, services, scripts or commands during start-up. Init.d has been mostly replaced in favor of Systemd. However, the "systemd-sysv-generator" can convert init.d files to service unit files that run at boot. Adversaries may add or alter files located in the "/etc/init.d/" directory to execute malicious code upon boot in order to gain persistence on the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: SentinelOne] |None |120 |<> |Detects when the SystemConfiguration preferences plist file is accessed by an unusual or suspicious process. This may indicate an attempt to gain situational awareness on a target system by reading network configuration details. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 @@ -3768,7 +3822,7 @@ and their rule type is `machine_learning`. |<> |This rule monitors for the unusual occurrence of outbound network connections to suspicious top level domains. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |3 -|<> |This rule monitors for the unusual occurrence of outbound network connections to suspicious webservice domains. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6 +|<> |This rule monitors for the unusual occurrence of outbound network connections to suspicious webservice domains. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |7 |<> |Identifies unusual instances of dllhost.exe making outbound network connections. This may indicate adversarial Command and Control activity. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide], [Data Source: SentinelOne] |None |213 @@ -3920,7 +3974,7 @@ and their rule type is `machine_learning`. |<> |This is an example of how to detect an unwanted web client user agent. This search matches the user agent for sqlmap 1.3.11, which is a popular FOSS tool for testing web applications for SQL injection vulnerabilities. |[Data Source: APM], [Resources: Investigation Guide] |None |105 -|<> |Detects HTTP requests to web servers whose URL or query string references cloud instance metadata endpoints or equivalent encoded variants. Attackers exploit server-side request forgery (SSRF) vulnerabilities in web applications to reach link-local metadata services on AWS, GCP, Azure, and similar cloud providers and harvest temporary credentials, tokens, or instance details. |[Domain: Web], [Domain: Cloud], [Domain: Network], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Initial Access], [Data Source: Nginx], [Data Source: Apache], [Data Source: Apache Tomcat], [Data Source: IIS], [Data Source: Traefik], [Data Source: Zeek], [Resources: Investigation Guide] |None |1 +|<> |Detects HTTP requests to web servers whose URL or query string references cloud instance metadata endpoints or equivalent encoded variants. Attackers exploit server-side request forgery (SSRF) vulnerabilities in web applications to reach link-local metadata services on AWS, GCP, Azure, and similar cloud providers and harvest temporary credentials, tokens, or instance details. |[Domain: Web], [Domain: Cloud], [Domain: Network], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Initial Access], [Data Source: Nginx], [Data Source: Apache], [Data Source: Apache Tomcat], [Data Source: IIS], [Data Source: Traefik], [Data Source: Zeek], [Resources: Investigation Guide] |None |2 |<> |This rule detects potential web server discovery or fuzzing activity by identifying a high volume of HTTP GET requests resulting in 404 or 403 status codes from a single source IP address within a short timeframe. Such patterns may indicate that an attacker is attempting to discover hidden or unlinked resources on a web server, which can be a precursor to more targeted attacks. |[Domain: Web], [Use Case: Threat Detection], [Tactic: Reconnaissance], [Data Source: Nginx], [Data Source: Apache], [Data Source: Apache Tomcat], [Data Source: IIS], [Data Source: Traefik], [Resources: Investigation Guide] |None |6 @@ -3942,7 +3996,7 @@ and their rule type is `machine_learning`. |<> |Identifies the registration of a Werfault Debugger. Attackers may abuse this mechanism to execute malicious payloads every time the utility is executed with the "-pr" parameter. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Sysmon], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |209 -|<> |Identifies suspicious use of whoami.exe which displays user, group, and privileges information for the user who is currently logged on to the local system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: Windows Security Event Logs] |None |219 +|<> |Identifies suspicious use of whoami.exe which displays user, group, and privileges information for the user who is currently logged on to the local system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: Windows Security Event Logs] |None |220 |<> |This rule identifies the execution of commands that enumerates account or group information. Adversaries may use built-in applications to get a listing of local system or domain accounts and groups. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend] |None |8 diff --git a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc index a51b986f85..cccc4d0274 100644 --- a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc +++ b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc @@ -6,6 +6,7 @@ include::rule-details/aws-account-closed.asciidoc[] include::rule-details/aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc[] include::rule-details/aws-attempt-to-leave-organization.asciidoc[] include::rule-details/aws-backup-recovery-point-deleted.asciidoc[] +include::rule-details/aws-backup-resource-enumeration-via-long-term-access-key.asciidoc[] include::rule-details/aws-backup-vault-deleted-or-vault-lock-removed.asciidoc[] include::rule-details/aws-batch-job-submitted-with-container-override-by-unusual-identity.asciidoc[] include::rule-details/aws-bedrock-api-key-phantom-user-activity-outside-bedrock.asciidoc[] @@ -148,6 +149,7 @@ include::rule-details/aws-lambda-layer-shared-externally.asciidoc[] include::rule-details/aws-lateral-movement-from-kubernetes-sa-via-assumerolewithwebidentity.asciidoc[] include::rule-details/aws-management-console-brute-force-of-root-user-identity.asciidoc[] include::rule-details/aws-management-console-root-login.asciidoc[] +include::rule-details/aws-organizations-delegated-administrator-registered.asciidoc[] include::rule-details/aws-potential-cryptomining-via-ecs-task-definition-deployment.asciidoc[] include::rule-details/aws-rds-db-instance-made-public.asciidoc[] include::rule-details/aws-rds-db-instance-restored.asciidoc[] @@ -159,6 +161,7 @@ include::rule-details/aws-rds-db-snapshot-shared-with-another-account.asciidoc[] include::rule-details/aws-rds-snapshot-deleted.asciidoc[] include::rule-details/aws-rds-snapshot-export.asciidoc[] include::rule-details/aws-rare-source-as-organization-activity.asciidoc[] +include::rule-details/aws-root-console-login-password-spraying.asciidoc[] include::rule-details/aws-route-53-domain-transfer-lock-disabled.asciidoc[] include::rule-details/aws-route-53-domain-transferred-to-another-account.asciidoc[] include::rule-details/aws-route-53-private-hosted-zone-associated-with-a-vpc.asciidoc[] @@ -167,6 +170,7 @@ include::rule-details/aws-s3-bucket-acl-modified-to-allow-public-access-by-new-i include::rule-details/aws-s3-bucket-configuration-deletion.asciidoc[] include::rule-details/aws-s3-bucket-enumeration-or-brute-force.asciidoc[] include::rule-details/aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc[] +include::rule-details/aws-s3-bucket-mfa-delete-disabled.asciidoc[] 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[] @@ -176,7 +180,9 @@ 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[] include::rule-details/aws-s3-unauthenticated-bucket-access-by-rare-source.asciidoc[] +include::rule-details/aws-ses-account-email-sending-enabled.asciidoc[] include::rule-details/aws-ses-email-identity-verified-then-deleted.asciidoc[] +include::rule-details/aws-ses-enumeration-via-long-term-access-key.asciidoc[] include::rule-details/aws-ses-full-access-policy-attached-to-iam-entity-by-unusual-user.asciidoc[] include::rule-details/aws-sns-rare-protocol-subscription-by-user.asciidoc[] include::rule-details/aws-sns-topic-created-by-rare-user.asciidoc[] @@ -199,7 +205,9 @@ include::rule-details/aws-sts-role-chaining.asciidoc[] include::rule-details/aws-sagemaker-execution-role-passed-by-unusual-principal.asciidoc[] include::rule-details/aws-sagemaker-notebook-lifecycle-configuration-with-suspicious-script-content.asciidoc[] include::rule-details/aws-secrets-manager-rapid-secrets-retrieval.asciidoc[] +include::rule-details/aws-security-hub-disabled.asciidoc[] include::rule-details/aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc[] +include::rule-details/aws-service-quota-increase-requested-by-rare-identity.asciidoc[] include::rule-details/aws-service-quotas-multi-region-getservicequota-requests.asciidoc[] include::rule-details/aws-sign-in-console-login-with-federated-user.asciidoc[] include::rule-details/aws-sign-in-root-password-recovery-requested.asciidoc[] @@ -281,6 +289,7 @@ include::rule-details/attempted-private-key-access.asciidoc[] include::rule-details/attempts-to-brute-force-an-okta-user-account.asciidoc[] include::rule-details/authentication-via-unusual-pam-grantor.asciidoc[] include::rule-details/authorization-plugin-modification.asciidoc[] +include::rule-details/azcopy-or-azure-storage-explorer-usage-on-unusual-host.asciidoc[] include::rule-details/azure-ad-graph-access-with-suspicious-user-agent.asciidoc[] include::rule-details/azure-ad-graph-access-with-unusual-client-and-user.asciidoc[] include::rule-details/azure-ad-graph-access-with-unusual-user-and-asn.asciidoc[] @@ -331,6 +340,7 @@ include::rule-details/azure-storage-account-deletion-by-unusual-user.asciidoc[] 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-anonymous-blob-access-to-unusual-resource.asciidoc[] include::rule-details/azure-storage-blob-retrieval-via-azcopy.asciidoc[] include::rule-details/azure-vm-boot-diagnostics-retrieved.asciidoc[] include::rule-details/azure-vm-extension-crud-operation-with-unusual-source-asn.asciidoc[] @@ -342,6 +352,9 @@ include::rule-details/azure-vnet-firewall-policy-deleted.asciidoc[] include::rule-details/azure-vnet-full-network-packet-capture-enabled.asciidoc[] include::rule-details/azure-vnet-network-watcher-deleted.asciidoc[] include::rule-details/azure-virtual-machine-configuration-modified.asciidoc[] +include::rule-details/azure-wireserver-http-request-from-unexpected-user-agent.asciidoc[] +include::rule-details/azure-wireserver-openssl-certificate-decrypt-or-linuxtransport-generation.asciidoc[] +include::rule-details/azure-wireserver-unusual-process-connection.asciidoc[] include::rule-details/bpf-program-tampering-via-bpftool.asciidoc[] include::rule-details/bpf-program-or-map-load-via-bpftool.asciidoc[] include::rule-details/bpf-filter-applied-using-tc.asciidoc[] @@ -486,6 +499,8 @@ include::rule-details/entra-id-custom-domain-added-or-verified.asciidoc[] include::rule-details/entra-id-device-registration-with-phishing-kit-default-os-build.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-device-bound-prt-replay-via-first-party-app-from-unusual-ip.asciidoc[] +include::rule-details/entra-id-device-bound-prt-from-unusual-device-ip.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[] @@ -547,6 +562,8 @@ include::rule-details/entra-id-user-sign-in-brute-force-attempted.asciidoc[] include::rule-details/entra-id-user-sign-in-with-unusual-authentication-type.asciidoc[] include::rule-details/entra-id-user-sign-in-with-unusual-client.asciidoc[] include::rule-details/entra-id-user-sign-in-with-unusual-non-managed-device.asciidoc[] +include::rule-details/entra-id-windows-hello-for-business-credential-registered.asciidoc[] +include::rule-details/entra-id-windows-hello-or-passkey-sign-in-from-unregistered-device.asciidoc[] include::rule-details/enumerating-domain-trusts-via-dsquery-exe.asciidoc[] include::rule-details/enumerating-domain-trusts-via-nltest-exe.asciidoc[] include::rule-details/enumeration-command-spawned-via-wmiprvse.asciidoc[] @@ -603,6 +620,7 @@ include::rule-details/file-and-directory-permissions-modification.asciidoc[] include::rule-details/file-made-immutable-by-chattr.asciidoc[] include::rule-details/file-or-directory-deletion-command.asciidoc[] include::rule-details/file-with-right-to-left-override-character-rtlo-created-executed.asciidoc[] +include::rule-details/file-with-suspicious-double-extension-created-by-web-server.asciidoc[] include::rule-details/file-with-suspicious-extension-downloaded.asciidoc[] include::rule-details/finder-sync-plugin-registered-and-enabled.asciidoc[] include::rule-details/first-occurrence-github-event-for-a-personal-access-token-pat.asciidoc[] @@ -615,6 +633,8 @@ include::rule-details/first-occurrence-of-personal-access-token-pat-use-for-a-gi include::rule-details/first-occurrence-of-private-repo-event-from-specific-github-personal-access-token-pat.asciidoc[] include::rule-details/first-occurrence-of-user-agent-for-a-github-personal-access-token-pat.asciidoc[] include::rule-details/first-occurrence-of-user-agent-for-a-github-user.asciidoc[] +include::rule-details/first-seen-network-flow-exporter.asciidoc[] +include::rule-details/first-seen-network-flow-exporter-followed-by-suspicious-source-activity.asciidoc[] include::rule-details/first-seen-sonicwall-remote-access-login-by-user-and-source.asciidoc[] include::rule-details/first-time-aws-cloudformation-stack-creation.asciidoc[] include::rule-details/first-time-python-accessed-sensitive-credential-files.asciidoc[] @@ -899,6 +919,7 @@ include::rule-details/launch-service-creation-and-immediate-loading.asciidoc[] include::rule-details/linux-audio-recording-activity-detected.asciidoc[] include::rule-details/linux-clipboard-activity-detected.asciidoc[] include::rule-details/linux-external-ip-address-discovery-via-curl.asciidoc[] +include::rule-details/linux-firewall-rule-creation-or-modification.asciidoc[] include::rule-details/linux-group-creation.asciidoc[] include::rule-details/linux-process-hooking-via-gdb.asciidoc[] include::rule-details/linux-ssh-x11-forwarding.asciidoc[] @@ -1091,6 +1112,7 @@ include::rule-details/newly-observed-palo-alto-network-alert.asciidoc[] include::rule-details/newly-observed-process-exhibiting-high-cpu-usage.asciidoc[] include::rule-details/newly-observed-rc4-kerberos-service-ticket-request.asciidoc[] include::rule-details/newly-observed-screenconnect-host-server.asciidoc[] +include::rule-details/newly-seen-commonly-abused-network-scanner.asciidoc[] include::rule-details/node-js-pre-or-post-install-script-execution.asciidoc[] include::rule-details/nping-process-activity.asciidoc[] include::rule-details/nsenter-to-pid-namespace-via-auditd.asciidoc[] @@ -1212,8 +1234,10 @@ include::rule-details/potential-disabling-of-selinux.asciidoc[] include::rule-details/potential-docker-escape-via-nsenter.asciidoc[] include::rule-details/potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc[] include::rule-details/potential-edr-freeze-via-werfaultsecure-abuse.asciidoc[] +include::rule-details/potential-entra-id-prt-extraction-via-browsercore.asciidoc[] include::rule-details/potential-enumeration-via-active-directory-web-service.asciidoc[] include::rule-details/potential-escalation-via-vulnerable-msi-repair.asciidoc[] +include::rule-details/potential-etherhiding-c2-via-curl-json-rpc-request.asciidoc[] include::rule-details/potential-etherhiding-c2-via-blockchain-connection.asciidoc[] include::rule-details/potential-evasion-via-boot-time-removal-tool.asciidoc[] include::rule-details/potential-evasion-via-filter-manager.asciidoc[] @@ -1227,6 +1251,7 @@ include::rule-details/potential-fake-captcha-phishing-attack.asciidoc[] include::rule-details/potential-file-download-via-a-headless-browser.asciidoc[] include::rule-details/potential-file-transfer-via-certreq.asciidoc[] include::rule-details/potential-file-transfer-via-curl-for-windows.asciidoc[] +include::rule-details/potential-fileless-execution-via-o-tmpfile.asciidoc[] include::rule-details/potential-foxmail-exploitation.asciidoc[] include::rule-details/potential-git-cve-2025-48384-exploitation.asciidoc[] include::rule-details/potential-http-downgrade-attack.asciidoc[] @@ -1366,6 +1391,7 @@ include::rule-details/potential-root-effective-shell-from-non-standard-path-via- include::rule-details/potential-sap-netweaver-exploitation.asciidoc[] include::rule-details/potential-sap-netweaver-webshell-creation.asciidoc[] include::rule-details/potential-sql-injection-against-microsoft-sql-server.asciidoc[] +include::rule-details/potential-ssh-brute-force-detected-via-macos-security-events.asciidoc[] include::rule-details/potential-ssh-password-grabbing-via-strace.asciidoc[] include::rule-details/potential-ssh-reverse-port-forwarding.asciidoc[] include::rule-details/potential-syn-based-port-scan-detected.asciidoc[] @@ -1379,6 +1405,7 @@ include::rule-details/potential-shell-via-wildcard-injection-detected.asciidoc[] include::rule-details/potential-spike-in-web-server-error-logs.asciidoc[] include::rule-details/potential-subnet-scanning-activity-from-compromised-host.asciidoc[] include::rule-details/potential-successful-ssh-brute-force-attack.asciidoc[] +include::rule-details/potential-successful-ssh-brute-force-attack-via-macos-security-events.asciidoc[] include::rule-details/potential-sudo-hijacking.asciidoc[] include::rule-details/potential-sudo-privilege-escalation-via-cve-2019-14287.asciidoc[] include::rule-details/potential-sudo-token-manipulation-via-process-injection.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 7fe9aed88e..d3f4c893c2 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 @@ -41,7 +41,7 @@ Specially crafted DNS requests can manipulate a known overflow vulnerability in * Data Source: Network Traffic * Data Source: Zeek -*Version*: 112 +*Version*: 113 *Rule authors*: 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 2e3ac58f4d..6ae141ca52 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 @@ -43,7 +43,7 @@ This rule detects network events that may indicate the use of Telnet traffic. Te * Data Source: Suricata * Resources: Investigation Guide -*Version*: 116 +*Version*: 117 *Rule authors*: 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 f7c212a1f2..7557993fb7 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*: 2 +*Version*: 3 *Rule authors*: @@ -104,7 +104,15 @@ 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*)) + source.as.organization.name:(* and not (Amazon* or AMAZON*)) and + not ( + user.id:( + *oic.prod-aks.azure.com* or + *container.googleapis.com* + ) and + source.as.organization.name:("Microsoft Corporation" or "Google LLC") +) and +not user.id:((*oidc.s3* and *ocp*) or (*s3* and *amazonaws.com* and *oidc*)) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/aws-backup-resource-enumeration-via-long-term-access-key.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-backup-resource-enumeration-via-long-term-access-key.asciidoc new file mode 100644 index 0000000000..e37ea0dde0 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-backup-resource-enumeration-via-long-term-access-key.asciidoc @@ -0,0 +1,118 @@ +[[aws-backup-resource-enumeration-via-long-term-access-key]] +=== AWS Backup Resource Enumeration via Long-Term Access Key + +Detects enumeration of AWS Backup resources using long-term IAM access keys (AKIA* prefix). AWS Backup protects EC2 instances, EBS volumes, RDS databases, DynamoDB tables, EFS file systems, and S3 buckets. An adversary who obtains long-term access keys may enumerate backup vaults, backup plans, and protected resources as a precursor to ransomware. Identifying which resources have recent backups (indicating high-value data) and what vault access policies can be modified to delete or corrupt the backups before encrypting the primary data. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListBackupVaults.html +* https://hackingthe.cloud/aws/enumeration/enumerate_services_via_aws_backup/ + +*Tags*: + +* Domain: Cloud +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Backup +* Rule Type: Custom Query (KQL) +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Backup Resource Enumeration via Long-Term Access Key* + + +AWS Backup vaults and plans are the last line of recovery for ransomware victims. Adversaries performing ransomware preparation systematically enumerate backup vaults to locate recovery points, assess vault lock configuration, and identify which vaults can be deleted or which backup plans can be disabled before encrypting the primary data stores. + +Long-term access keys (AKIA* prefix) are the most commonly exfiltrated credential type, appearing in source code, .env files, and CI/CD configurations. Their use for backup enumeration is particularly suspicious because backup management is almost never performed by individual IAM users with static keys in modern environments. + + +*Possible investigation steps* + + +- Identify the IAM user from aws.cloudtrail.user_identity.arn and confirm whether this user should have backup management access. +- Review source.ip and source.as.organization.name against known infrastructure. Backup enumeration from an unexpected IP with a long-term key is a high-risk indicator. +- Query for subsequent backup write operations by this key: DeleteBackupVault, DeleteRecoveryPoint, DeleteBackupPlan, UpdateRegionSettings. +- Correlate with other enumeration activity from the same access key: EC2 Describe calls, S3 ListBuckets, RDS DescribeDBInstances — broad enumeration suggests ransomware reconnaissance. +- Determine whether Vault Lock is enabled on critical backup vaults (GetBackupVaultLockConfiguration). + + +*Response and remediation* + + +- Immediately deactivate the long-term access key. +- Enable Vault Lock (WORM) on critical backup vaults to prevent deletion for a compliance period. +- Review all backup vault access policies for unauthorized modifications. +- Enable AWS Backup audit manager reports to detect future unauthorized backup modifications. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. AWS Backup management events are logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "backup.amazonaws.com" + and event.action: ( + "ListBackupVaults" or + "ListBackupJobs" or + "ListBackupPlans" or + "ListProtectedResources" or + "ListRecoveryPointsByBackupVault" or + "GetBackupPlan" or + "GetBackupVaultAccessPolicy" or + "DescribeBackupJob" or + "DescribeRecoveryPoint" + ) + and event.outcome: "success" + and aws.cloudtrail.user_identity.access_key_id: AKIA* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-lateral-movement-from-kubernetes-sa-via-assumerolewithwebidentity.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-lateral-movement-from-kubernetes-sa-via-assumerolewithwebidentity.asciidoc index b01eb0bed1..98acd8656d 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-lateral-movement-from-kubernetes-sa-via-assumerolewithwebidentity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-lateral-movement-from-kubernetes-sa-via-assumerolewithwebidentity.asciidoc @@ -11,9 +11,9 @@ Detects when credentials issued through `AssumeRoleWithWebIdentity` for a Kubern *Risk score*: 73 -*Runs every*: 1h +*Runs every*: 30m -*Searches indices from*: now-24h ({ref}/common-options.html#date-math[Date Math format], see also <>) +*Searches indices from*: now-1h ({ref}/common-options.html#date-math[Date Math format], see also <>) *Maximum alerts per execution*: 100 @@ -36,7 +36,7 @@ Detects when credentials issued through `AssumeRoleWithWebIdentity` for a Kubern * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 1 +*Version*: 2 *Rule authors*: @@ -68,7 +68,7 @@ use the bundled fields to scope time, identity, and network context before drill - **`Esql.post_exploit_count`**, **`Esql.event_action_values`**, **`Esql.attack_phases`**: which distinct APIs fired on the same key; flag unexpected IAM, secrets, or `RunInstances` alongside recon. - **`Esql.total_calls`**: volume beyond “three distinct actions”—helps separate quick probes from sustained abuse. -- **`Esql.source_ip_values`**, **`Esql.source_asn_names`**, **`Esql.user_agent_values`**: compare to known cluster egress, +- **`source.ip`**, **`source.as.organization.name`**, **`Esql.user_agent_original_values`**: compare to known cluster egress, NAT, or approved automation; divergent ASNs or clients can indicate token use off-cluster. **Next pivots** @@ -145,8 +145,6 @@ FROM logs-aws.cloudtrail-* Esql.post_exploit_count = COUNT_DISTINCT(event.action), Esql.attack_phases = VALUES(phase), Esql.event_action_values = VALUES(event.action), - Esql.source_ip_values = VALUES(source.ip), - Esql.source_as_organization_name_values = VALUES(source.as.organization.name), Esql.user_name_values = VALUES(user.name), Esql.user_agent_original_values = VALUES(user_agent.original), Esql.cloud_account_id_values = VALUES(cloud.account.id), @@ -154,10 +152,10 @@ FROM logs-aws.cloudtrail-* Esql.first_seen = MIN(@timestamp), Esql.last_seen = MAX(@timestamp), Esql.total_calls = COUNT(*) - BY access_key + BY access_key, source.ip, source.`as`.number, source.`as`.organization.name | WHERE access_key is not null and Esql.assume_count >= 1 AND Esql.post_exploit_count >= 3 | EVAL aws.cloudtrail.user_identity.access_key_id = MV_FIRST(access_key) -| KEEP aws.cloudtrail.user_identity.access_key_id, Esql.* +| KEEP aws.cloudtrail.user_identity.access_key_id, source.ip, source.`as`.number, source.`as`.organization.name, Esql.* ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/aws-organizations-delegated-administrator-registered.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-organizations-delegated-administrator-registered.asciidoc new file mode 100644 index 0000000000..e1506b249d --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-organizations-delegated-administrator-registered.asciidoc @@ -0,0 +1,120 @@ +[[aws-organizations-delegated-administrator-registered]] +=== AWS Organizations Delegated Administrator Registered + +Detects when an AWS member account is registered as a delegated administrator for an AWS service via the RegisterDelegatedAdministrator API. Delegated administrators receive service-level administrative access across the entire organization without being the management account. An attacker who compromises a principal with organizations permissions can abuse overly permissive managed policies to register a member account they control as a delegated administrator, then use that privileged access to escalate privileges organization-wide and compromise all member accounts. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/organizations/latest/APIReference/API_RegisterDelegatedAdministrator.html +* https://cymulate.com/blog/aws-delegated-admin-org-takeover/ + +*Tags*: + +* Domain: Cloud +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Organizations +* Rule Type: Custom Query (KQL) +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Organizations Delegated Administrator Registered* + + +AWS allows organizations to delegate service-level administrative access to a member account via RegisterDelegatedAdministrator. The delegated account gains organization-wide administrative privileges for the specified service without being the management account. Adversaries who compromise a principal in the management account with overly permissive Organizations policies can register an attacker-controlled member account as a delegated administrator, then use that foothold to escalate privileges across all accounts in the organization. + +This technique was documented by Cymulate, who found that AmazonGuardDutyFullAccess v1 (before AWS corrected it) granted organizations:RegisterDelegatedAdministrator without resource restrictions, allowing any principal with that policy to elevate a member account to organization-wide admin for sensitive services such as Identity Center or CloudFormation StackSets. + + +*Possible investigation steps* + + +- Identify the caller in aws.cloudtrail.user_identity.arn and user.name. Verify they are an authorized cloud platform administrator. +- Review aws.cloudtrail.request_parameters for the servicePrincipal (which AWS service was delegated) and accountId (which member account was elevated). Confirm the member account belongs to your organization's account inventory. +- Determine whether this delegation was planned. Compare against your organization's current delegated administrator configuration via organizations:ListDelegatedAdministrators. +- Check whether the newly elevated member account subsequently made cross-account API calls or modified permission sets, IAM roles, or CloudFormation stacks. +- Review which managed policies are attached to the calling principal. Policies with broad organizations:* grants without resource restrictions may be exploited for this technique. + + +*Response and remediation* + + +- If unauthorized, deregister the delegated administrator with organizations:DeregisterDelegatedAdministrator. +- Revoke active sessions for the calling identity and audit all management account activity. +- Review and tighten IAM policies attached to principals in the management account — ensure organizations:RegisterDelegatedAdministrator is restricted to a dedicated, MFA-required role. +- Enumerate all delegated administrators in the organization to identify any additional unauthorized delegations. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. Organizations management events are logged in the organization management account by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "organizations.amazonaws.com" + and event.action: "RegisterDelegatedAdministrator" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* 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: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-root-console-login-password-spraying.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-root-console-login-password-spraying.asciidoc new file mode 100644 index 0000000000..20ba0d90db --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-root-console-login-password-spraying.asciidoc @@ -0,0 +1,147 @@ +[[aws-root-console-login-password-spraying]] +=== AWS Root Console Login Password Spraying + +Identifies failed authentication attempts against the AWS Management Console root user from the same source IP address targeting multiple AWS accounts. Password spraying uses few attempts per target across many accounts to avoid lockout, making per-account volume an unreliable signal. This rule detects the cross-account breadth pattern: a single source IP generating root ConsoleLogin failures across two or more distinct AWS accounts. Requires an AWS Organizations-level CloudTrail trail aggregating events from member accounts. + +*Rule type*: threshold + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-1h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://securitylabs.datadoghq.com/articles/aws-root-user-bruteforce-campaign/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Platform: AWS +* Data Source: AWS CloudTrail +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Rule Type: Threshold +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Root Console Login Password Spraying* + + +Password spraying is a credential access technique where an attacker tries a small number of commonly used or leaked passwords across many accounts. Unlike brute force, the per-account attempt count is intentionally low — often 2–8 attempts — to stay below lockout thresholds and evade high-volume detections. Attackers targeting AWS root accounts typically hold a pre-enumerated list of root account email addresses and route attempts through proxy or residential IP infrastructure. + +This rule fires when a single source IP generates failed root `ConsoleLogin` events against two or more distinct AWS accounts within a 1 hour window, requiring an AWS Organizations-level CloudTrail trail. The cross-account breadth is the defining spray signal; brute force against a single account is covered by a separate rule. + + +*Possible investigation steps* + + +- **Assess the source IP.** +Determine whether the IP belongs to a known corporate range, VPN, or expected admin location. Use threat intelligence tools to check if it is flagged as a proxy, Tor exit node, or residential proxy service. + +- **Review the user agent string.** +Outdated browser user agents (for example, Chrome 85 or Firefox 120) are common indicators of spray-campaign tooling. Cross-reference `user_agent.original` across the contributing events in Timeline. + +- **Check for a subsequent successful login.** +Query CloudTrail for a `ConsoleLogin` success for the root identity in the same timeframe. A success immediately after failures indicates the spray succeeded — escalate immediately. + +- **Examine follow-on API calls.** +If a successful login did occur, review high-risk API calls that followed: `CreateUser`, `CreateAccessKey`, `AttachRolePolicy`, `DeleteTrail`, or `StopLogging`. + +- **Widen the scope across accounts.** +If your organization uses AWS Organizations, check whether the same source IP triggered root login failures in other member accounts during the same window. + + +*False positive analysis* + + +- **Mistyped credentials.** A root credential custodian mistyping the password multiple times is the most likely benign cause. Confirm whether the source IP is a known admin location and whether a successful login followed shortly after. +- **Stale automation.** Misconfigured scripts or browser sessions with cached root credentials may retry on failure. Check whether the user agent matches known internal tooling. + + +*Response and remediation* + + +- **If no successful root login is found:** + - Rotate the root password to a strong, unique credential stored in an offline vault. + - Confirm MFA is enabled and enforced on the root account. + - Block the source IP at AWS WAF or network ACLs if confirmed malicious. + +- **If a successful root login is found:** + - Treat as Priority-1 account compromise and immediately follow the *AWS Management Console Root Login* investigation guide. + - Initiate an emergency root password reset and MFA re-enrollment. + - Preserve all CloudTrail events from ±1 hour around the login in an immutable evidence bucket. + - Audit all API calls made during the session for persistence: new users, access keys, policy changes. + + +*Additional information* + + +- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html[AWS root user best practices] +- https://github.com/aws-samples/aws-incident-response-playbooks[AWS IR Playbooks — Credential Compromise] + + +==== Setup + + + +*Setup* + + +This rule requires an AWS Organizations-level CloudTrail trail that aggregates management events from all member accounts into a single destination. A single-account trail will only ever contain one `cloud.account.id` value and the cross-account cardinality signal will never fire. + +To configure an org-level trail: in the AWS CloudTrail console, create a trail scoped to your AWS Organization and enable it in all regions. Ensure the Elastic AWS integration is ingesting from the aggregated trail destination. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and +event.provider:signin.amazonaws.com and +event.action:ConsoleLogin and +aws.cloudtrail.user_identity.type:Root and +event.outcome:failure + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-mfa-delete-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-mfa-delete-disabled.asciidoc new file mode 100644 index 0000000000..eaa1c9b408 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-mfa-delete-disabled.asciidoc @@ -0,0 +1,110 @@ +[[aws-s3-bucket-mfa-delete-disabled]] +=== AWS S3 Bucket MFA Delete Disabled + +Detects when MFA Delete is disabled on an Amazon S3 bucket. MFA Delete is an additional layer of security for versioned S3 buckets that requires multi-factor authentication to permanently delete object versions or disable versioning. When MFA Delete is disabled, an adversary with S3 write access and a compromised long-term access key can permanently delete object versions, a critical step in ransomware attacks that target S3 versioning as a backup mechanism. MFA Delete is configured via PutBucketVersioning with the MfaDelete parameter set to Disabled. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketVersioning.html +* https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/ +* https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c + +*Tags*: + +* Domain: Cloud +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 +* Rule Type: Custom Query (KQL) +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket MFA Delete Disabled* + + +MFA Delete protects versioned S3 buckets by requiring MFA authentication to permanently delete object versions or change the versioning state. This protection is specifically designed to prevent ransomware from destroying version history after encrypting the current object copies. Disabling MFA Delete removes this safeguard and is a recognized ransomware preparation step. + +Importantly, only the AWS account root user can enable or disable MFA Delete. A `PutBucketVersioning` call disabling MFA Delete from a non-root identity is a strong indicator of root credential compromise or unauthorized use. + + +*Possible investigation steps* + + +- Identify the caller from `aws.cloudtrail.user_identity.type`. If this is not a `Root` identity, treat it as high-confidence unauthorized access. +- Check `aws.cloudtrail.request_parameters` to confirm `VersioningConfiguration={... MfaDelete=Disabled}` is present. +- Review all API calls by the same identity in the surrounding window for other data-destruction or encryption-related actions. +- Check whether object versioning remains enabled on the affected bucket. If both versioning and MFA Delete are disabled, the bucket has no object-level recovery protection. +- Investigate whether MFA was presented (`aws.cloudtrail.additional_eventdata` contains MFA information for requests that required it). + + +*Response and remediation* + + +- If unauthorized, immediately re-enable MFA Delete using root credentials and verify that object version history is intact. +- Rotate all credentials associated with the calling identity. +- Review S3 object versions for any permanent deletions that occurred after MFA Delete was disabled. +- Enable AWS Config rules to detect versioning and MFA Delete configuration changes. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. S3 management events are logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "s3.amazonaws.com" + and event.action: "PutBucketVersioning" + and event.outcome: "success" + and aws.cloudtrail.flattened.request_parameters.VersioningConfiguration.MfaDelete: "Disabled" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-security-hub-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-security-hub-disabled.asciidoc new file mode 100644 index 0000000000..95230db0e6 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-security-hub-disabled.asciidoc @@ -0,0 +1,116 @@ +[[aws-security-hub-disabled]] +=== AWS Security Hub Disabled + +Detects when AWS Security Hub is disabled in a region. Security Hub aggregates security findings from AWS services (GuardDuty, Inspector, Macie, IAM Access Analyzer) and third-party tools into a single pane of glass. Disabling it suppresses centralized finding aggregation and compliance checks, removing visibility into threats across the account. This action is a documented pre-ransomware and pre-exfiltration defense evasion technique. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-disable.html + +*Tags*: + +* Domain: Cloud +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Security Hub +* Rule Type: Custom Query (KQL) +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Security Hub Disabled* + + +AWS Security Hub aggregates security findings from GuardDuty, Inspector, IAM Access Analyzer, Macie, and partner products. Disabling it is a one-API-call action (DisableSecurityHub) that immediately stops new findings from appearing in the hub and breaks compliance posture checks (CIS, PCI DSS, AWS Foundational Security Best Practices). Threat actors performing pre-ransomware activity commonly disable security services to reduce detection during the exfiltration and encryption phases. + + +*Possible investigation steps* + + +- Identify the caller in aws.cloudtrail.user_identity.arn and user.name. Determine whether this is a human operator, a CI/CD service role, or an automated account lifecycle script. +- Check source.ip against known office CIDRs, VPN endpoints, and CI/CD runner IPs. A call from an unexpected geography or cloud provider IP is a strong indicator of credential compromise. +- Query CloudTrail for all API calls from this identity in the same time window. Look for co-occurring DeleteDetector or UpdateDetector with enable false (GuardDuty), DisableMacie or UpdateMacieSession with status PAUSED (Macie), DeleteTrail, StopLogging, PutEventSelectors (reducing event selectors), or DeleteFlowLogs calls — a multi-service security teardown is high confidence ransomware/wiperware preparation. +- Determine whether Security Hub was re-enabled shortly after (indicating a momentary operational toggle) or remained disabled. +- Check whether this corresponds to a known change window or approved infrastructure operation. + + +*False positive analysis* + + +- Regional decommissioning: teams shutting down an AWS region may disable Security Hub as part of account cleanup. Validate against a change management ticket. +- Cost optimization: Security Hub has a cost per finding. Some teams disable it in non-production accounts. If this fires in a dev/test account with known cost controls, correlate with account tags. + + +*Response and remediation* + + +- If unauthorized, re-enable Security Hub immediately and review all findings that were suppressed during the disabled period using the Security Hub finding history API. +- Revoke active sessions for the calling identity. +- Review other security services (GuardDuty, Macie, Inspector) to confirm they remain enabled. +- Enable AWS Config rule securityhub-enabled to detect future disablement automatically. +- If the caller was a compromised IAM user, rotate all access keys and review all actions in the compromised session. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. No additional CloudTrail data event selectors are required — `securityhub:DisableSecurityHub` is a management-plane API logged by default in any CloudTrail trail with management event logging enabled. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "securityhub.amazonaws.com" + and event.action: "DisableSecurityHub" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-service-quota-increase-requested-by-rare-identity.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-service-quota-increase-requested-by-rare-identity.asciidoc new file mode 100644 index 0000000000..086cf5f36a --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-service-quota-increase-requested-by-rare-identity.asciidoc @@ -0,0 +1,105 @@ +[[aws-service-quota-increase-requested-by-rare-identity]] +=== AWS Service Quota Increase Requested by Rare Identity + +Detects the first time an AWS identity requests a service quota increase via the AWS Service Quotas API within a 7-day history window. Service quota increases are submitted to AWS Support and, when approved, raise the limits on EC2 instances, Lambda concurrency, VPC resources, and other services. An adversary who obtains AWS credentials may request quota increases as infrastructure preparation for large-scale cryptomining, DDoS amplification, phishing campaigns, or data exfiltration operations that require compute or network resources beyond the account's current limits. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/servicequotas/2019-06-24/apireference/API_RequestServiceQuotaIncrease.html +* https://www.rapid7.com/blog/post/dr-threat-actors-aws-workmail-phishing-campaigns/ + +*Tags*: + +* Domain: Cloud +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Service Quotas +* Rule Type: New Terms +* Tactic: Resource Development +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Service Quota Increase Requested by Rare Identity* + + +AWS Service Quotas (formerly Service Limits) cap how many resources of each type an account can create. Default limits exist to prevent accidental runaway provisioning, but an adversary who requests an increase can scale operations far beyond what the default limits allow: requesting 1000 EC2 On-Demand vCPUs enables cryptomining at industrial scale; requesting higher SES sending limits enables large-scale phishing campaigns; requesting higher Lambda concurrency enables large-scale credential-stuffing operations. + + +*Possible investigation steps* + + +- Identify the caller from aws.cloudtrail.user_identity.arn and user.name. +- Review aws.cloudtrail.request_parameters for the serviceCode (which AWS service), the quotaCode (which specific limit), and the requested value. +- Determine whether the requested quota increase aligns with a known infrastructure project. +- Check whether the same identity has recently created resources in the service being scaled (EC2 RunInstances, Lambda CreateFunction, SES SendEmail). +- Review whether this is the first quota increase request for this service from this identity or a continuation of a known capacity planning effort. + + +*Response and remediation* + + +- If unauthorized, submit a cancellation request to AWS Support for the quota increase. +- Revoke active sessions for the requesting identity. +- Apply an SCP restricting servicequotas:RequestServiceQuotaIncrease to approved cloud-operations roles that require prior approval. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. Service Quotas management events are logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "servicequotas.amazonaws.com" + and event.action: "RequestServiceQuotaIncrease" + and event.outcome: "success" + and not user_agent.original: (*Terraform* or *Pulumi* or *Ansible* or "cloudformation.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Acquire Infrastructure +** ID: T1583 +** Reference URL: https://attack.mitre.org/techniques/T1583/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-ses-account-email-sending-enabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ses-account-email-sending-enabled.asciidoc new file mode 100644 index 0000000000..c58303eb67 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-ses-account-email-sending-enabled.asciidoc @@ -0,0 +1,115 @@ +[[aws-ses-account-email-sending-enabled]] +=== AWS SES Account Email Sending Enabled + +Detects when account-level email sending is explicitly enabled in Amazon SES, via the v1 UpdateAccountSendingEnabled API with Enabled: true or the v2 PutAccountSendingAttributes API with SendingEnabled: true. Account-level sending is commonly paused by an administrator, or by automation wired to CloudWatch reputation alarms when bounce or complaint rates rise. An attacker who compromises an AWS account may re-enable sending to restore a paused capability as part of phishing infrastructure setup, allowing bulk email under the victim organization's trusted sending domain. Neither API can resume sending that AWS itself has paused. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/ses/latest/APIReference/API_UpdateAccountSendingEnabled.html +* https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_PutAccountSendingAttributes.html +* https://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/ +* https://www.rapid7.com/blog/post/dr-threat-actors-aws-workmail-phishing-campaigns/ + +*Tags*: + +* Domain: Cloud +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS SES +* Rule Type: Custom Query (KQL) +* Tactic: Resource Development +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SES Account Email Sending Enabled* + + +ses:UpdateAccountSendingEnabled (v1) and ses:PutAccountSendingAttributes (v2) both control whether the entire AWS account can send email in the current region, and both log under event.provider ses.amazonaws.com, so a caller can reach the same outcome through either API version. Enabling account-level sending is a one-step action that lifts a pause set by an administrator or by CloudWatch-driven automation. Per the v2 documentation neither API can resume sending that AWS has paused, so this is not a path out of an AWS enforcement action. In normal operations these APIs are rarely called. An attacker with SES permissions may call either one to restore paused sending capability, or to enable sending in a region where it was not previously active. + + +*Possible investigation steps* + + +- Identify the caller in aws.cloudtrail.user_identity.arn and user.name. Determine whether this is a known SES administrator or an anomalous identity. +- Verify whether account-level sending was previously disabled (ses:GetAccountSendingEnabled in v1, or ses:GetAccount returning SendingEnabled false in v2) and cross-reference prior CloudTrail events for both APIs. +- Query CloudTrail for co-occurring events from the same identity: IAM privilege escalation (AttachUserPolicy, AttachRolePolicy), SES identity creation (VerifyEmailIdentity, CreateEmailIdentity), or SES template/suppression-list manipulation. +- Check the account's SES sending statistics for any unusual spike in sent email volume following this event. +- Determine whether this corresponds to a legitimate remediation of a bounce/complaint rate issue with a change management ticket. + + +*False positive analysis* + + +- Legitimate SES operations teams re-enabling sending after a planned suspension will trigger this rule. These events are rare; validate against change records. + + +*Response and remediation* + + +- If unauthorized, disable account-level sending immediately via ses:UpdateAccountSendingEnabled with Enabled: false, or ses:PutAccountSendingAttributes with SendingEnabled: false. +- Revoke active sessions for the calling identity. +- Review SES send statistics for unauthorized email activity during the enabled window. +- Check all SES email identities and sending authorization policies for unauthorized entries. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. No additional data event selectors are required — `ses:UpdateAccountSendingEnabled` and `ses:PutAccountSendingAttributes` are management-plane APIs logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ses.amazonaws.com" + and event.action: ("UpdateAccountSendingEnabled" or "PutAccountSendingAttributes") + and event.outcome: "success" + and aws.cloudtrail.request_parameters: (*enabled=true* or *Enabled=true*) + and not user_agent.original: (*Terraform* or *terraform* or *Pulumi* or *pulumi* or *Ansible* or "batch.amazonaws.com" or "cloudformation.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Stage Capabilities +** ID: T1608 +** Reference URL: https://attack.mitre.org/techniques/T1608/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-ses-enumeration-via-long-term-access-key.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ses-enumeration-via-long-term-access-key.asciidoc new file mode 100644 index 0000000000..0c7fa8f81a --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-ses-enumeration-via-long-term-access-key.asciidoc @@ -0,0 +1,117 @@ +[[aws-ses-enumeration-via-long-term-access-key]] +=== AWS SES Enumeration via Long-Term Access Key + +Detects enumeration of Amazon Simple Email Service (SES) resources using long-term IAM access keys (AKIA* prefix). Long-term access keys are associated with IAM users and are the credential type most commonly exfiltrated from repositories, configuration files, and environment variables. An adversary who obtains a long-term key may enumerate SES to discover verified email identities, sending quotas, and DKIM/MAIL FROM domain configurations as a precursor to phishing or spam campaigns launched from the compromised account's verified domains. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/ses/latest/APIReference/API_ListIdentities.html +* https://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/ +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.discovery.ses-enumerate/ + +*Tags*: + +* Domain: Cloud +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS SES +* Rule Type: Custom Query (KQL) +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SES Enumeration via Long-Term Access Key* + + +Amazon SES verified identities (email addresses and domains) are the sending credentials that allow SES to send email on behalf of a domain. Adversaries who exfiltrate long-term IAM keys may enumerate SES to identify available verified domains for phishing, discover DKIM configurations, or check sending limits before launching a bulk email campaign. + +Long-term keys (AKIA* prefix) are lower-security than assumed-role credentials: they do not expire and are frequently exposed in source code, .env files, CI/CD configuration, and developer workstations. This makes them the most common compromised credential type in cloud environments. + + +*Possible investigation steps* + + +- Identify the IAM user behind the long-term key from aws.cloudtrail.user_identity.arn. +- Check whether this access key has been rotated recently (GetAccessKeyLastUsed, ListAccessKeys). Confirm the user who owns the key initiated this activity. +- Review source.ip and source.as.organization.name against known developer or automation infrastructure. API calls from unexpected geographies using a long-term key are high-risk. +- Query CloudTrail for subsequent SES write operations (SendEmail, SendRawEmail, VerifyEmailIdentity, UpdateAccountSendingEnabled) using the same access key. +- Check GitHub, GitLab, and CI/CD logs for any public exposure of this key. + + +*Response and remediation* + + +- Immediately deactivate the long-term access key (UpdateAccessKey --status Inactive). +- Rotate all credentials associated with the IAM user. +- Review all SES quotas and sending history to determine whether unauthorized email was sent. +- Migrate automation that used this key to IAM roles with short-lived assumed-role credentials. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. SES management APIs are logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ses.amazonaws.com" + and event.action: ( + "ListIdentities" or + "GetAccountSendingEnabled" or + "GetSendQuota" or + "ListEmailIdentities" or + "GetEmailIdentity" or + "DescribeActiveReceiptRuleSet" or + "ListReceiptRuleSets" + ) + and event.outcome: "success" + and aws.cloudtrail.user_identity.access_key_id: AKIA* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/rule-details/azcopy-or-azure-storage-explorer-usage-on-unusual-host.asciidoc b/docs/detections/prebuilt-rules/rule-details/azcopy-or-azure-storage-explorer-usage-on-unusual-host.asciidoc new file mode 100644 index 0000000000..ab7ca52df3 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azcopy-or-azure-storage-explorer-usage-on-unusual-host.asciidoc @@ -0,0 +1,184 @@ +[[azcopy-or-azure-storage-explorer-usage-on-unusual-host]] +=== AzCopy or Azure Storage Explorer Usage on Unusual Host + +Identifies the first time, in a historical window, a host runs AzCopy copy or sync to Azure Blob, Data Lake, or File storage, or starts Azure Storage Explorer. These Microsoft utilities are legitimate data-transfer tools; ransomware and cloud-ransomware operators drop portable copies and use SAS-authenticated jobs to pull data from victim storage and push it to attacker-controlled accounts. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* 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://www.cisa.gov/news-events/cybersecurity-advisories/aa23-319a +* https://www.cisa.gov/sites/default/files/2025-04/aa23-319a-stopransomware-rhysida-ransomware_2.pdf +* https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10 +* https://learn.microsoft.com/en-us/azure/storage/storage-explorer/vs-azure-tools-storage-explorer-blobs +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Platform: Windows +* Use Case: Threat Detection +* Tactic: Exfiltration +* Tactic: Collection +* Tactic: Execution +* Rule Type: New Terms +* Threat: Rhysida +* Use Case: Ransomware +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AzCopy or Azure Storage Explorer Usage on Unusual Host* + + +AzCopy and Azure Storage Explorer are Microsoft utilities for moving data to and from Azure Storage. Threat actors abuse them as living-off-the-land binaries: they run `azcopy copy` with SAS URLs against `*.blob.core.windows.net` (GetBlob from a victim account, PutBlob to an attacker account, or Blob-to-Blob between them) and launch Storage Explorer to browse or move the same data. CISA's Rhysida advisory is one example of that tradecraft. + +This is a new-terms rule: it alerts the first time a `host.id` matches in the history window (7 days). AzCopy `copy`/`sync` whose command line includes an Azure Storage hostname, or Storage Explorer (`StorageExplorer.exe`, `StorageExplorer-windows-x64.exe`, `StorageExplorer-windows-arm64.exe`, `StorageExplorer-windowsx64.exe`), fires once per host. Recurring use on the same host will not re-alert until the history window expires. + + +*Possible investigation steps* + + +- Confirm which utility fired the alert. For AzCopy, inspect `process.command_line` for `copy` vs `sync`, `--from-to` (`BlobLocal`, `LocalBlob`, `BlobBlob`), and the SAS URL host, container, and `sp`/`se` parameters. For Storage Explorer, note the installer vs application name and silent-install flags such as `/VERYSILENT`. +- Identify source and destination. AzCopy command lines often contain a local path and one or two `https://.blob.core.windows.net/...` URLs. Treat Blob-to-Blob copies as direct tenant-to-attacker movement even when no files touch disk. +- Check `process.executable` and `process.parent.executable`. A copy from a user-writable or staging path, especially spawned by PowerShell or a scripting host, is more suspicious than a packaged install. +- Compare `process.name` with `process.pe.original_file_name` and `process.code_signature.subject_name`. A Microsoft-signed binary from an unusual path is still the Rhysida/Storm-0501 tradecraft; a renamed unsigned copy is additional evasion. +- Pivot to Azure Storage diagnostic logs for the same window: GetBlob, PutBlob, and BlobBlob with user agent `AzCopy*` or `Microsoft Azure Storage Explorer*` and SAS authentication. Correlate with the SIEM rule "Azure Storage Blob Retrieval via AzCopy". +- Review network telemetry from the same `process.entity_id` to `*.blob.core.windows.net` or `*.dfs.core.windows.net` and estimate volume. +- Hunt sibling activity on the host: other Azure LOLBINs, rclone, or bulk archive creation preceding the copy. + + +*False positive analysis* + + +- Authorized AzCopy migrations and first-time Storage Explorer use on a host will match. This rule alerts only the first time a given `host.id` matches within 7 days; allowlist by host, user, or approved destination if that first alert is expected. +- Do not treat a trusted Microsoft signature as benign by itself; CISA's Rhysida advisory describes the official AzCopy and Storage Explorer binaries. + + +*Response and remediation* + + +- If exfiltration is confirmed, isolate the host, stop AzCopy and Storage Explorer processes, and preserve the command line (SAS URLs are credentials). +- Revoke the SAS tokens and account keys that appear in the command line; rotate storage account keys and any related Entra ID credentials. +- Identify which blobs were read or written (GetBlob/PutBlob/ListBlobs for the same account and time window) and assess data exposure. +- Remove staged binaries under unusual paths and investigate how they were delivered. +- Hunt for additional AzCopy, Storage Explorer, or rclone activity on other hosts in the same window. + + +*Related rules* + + +- Azure Storage Blob Retrieval via AzCopy: cloud-side GetBlob with AzCopy user agent and SAS authentication. +- Potential Data Exfiltration via Rclone: similar endpoint abuse of a different cloud-sync utility. + + +==== 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] + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:process and event.type:start and +( + ( + (process.name:"azcopy.exe" or process.pe.original_file_name:"azcopy.exe") and + process.args:("copy" or "sync") and + process.command_line:(*blob.core.windows.net* or *dfs.core.windows.net* or *file.core.windows.net* or *blob.storage.azure.net*) + ) or + process.name:("StorageExplorer.exe" or "StorageExplorer-windows-x64.exe" or "StorageExplorer-windows-arm64.exe" or "StorageExplorer-windowsx64.exe") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* 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: 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/ +* 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: Cloud API +** ID: T1059.009 +** Reference URL: https://attack.mitre.org/techniques/T1059/009/ diff --git a/docs/detections/prebuilt-rules/rule-details/azure-storage-anonymous-blob-access-to-unusual-resource.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-storage-anonymous-blob-access-to-unusual-resource.asciidoc new file mode 100644 index 0000000000..0c69fd6b0c --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-storage-anonymous-blob-access-to-unusual-resource.asciidoc @@ -0,0 +1,141 @@ +[[azure-storage-anonymous-blob-access-to-unusual-resource]] +=== Azure Storage Anonymous Blob Access to Unusual Resource + +Identifies the first time an Azure Storage resource receives an anonymous data-plane read (GetBlob and related Get or List operations). Anonymous requests are used to probe public containers and to test stolen blob URLs before a SAS is appended. First-seen resource ID keeps volume down while still covering WireServer-related probes of status or extension blobs. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.platformlogs-* + +*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/azure/azure-monitor/reference/tables/storagebloblogs +* https://learn.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent +* https://cybercx.com.au/blog/azure-ssrf-metadata/ +* https://www.netspi.com/blog/technical-blog/cloud-pentesting/decrypting-vm-extension-settings-with-azure-wireserver/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure Platform Logs +* Platform: Azure +* Service: Azure Storage +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Storage Anonymous Blob Access to Unusual Resource* + + +StorageRead platform logs record `AuthenticationType` as Anonymous when no SAS, OAuth, or account key is presented. +A first-seen `azure.resource.id` (typically the blob service +`/subscriptions/.../storageAccounts//blobServices/default`) means this resource has not had anonymous Get or +List traffic in the history window. + +WireServer SAS-replay chains often start with an anonymous GetBlob (HTTP 409/403) against the same object, then a +SAS 200. This rule does not require guest-agent path strings; those lab container names are not production +observables. + +`source.ip` is often empty. Use `source.address` (`ip:port`). + + +*Possible investigation steps* + + +- Review `event.action`, `azure.platformlogs.statusCode`, and `azure.platformlogs.uri`. +- HTTP 200 with Anonymous means the container or blob is publicly readable. HTTP 409/403 is a probe. +- Identify the account from `azure.resource.id` / `azure.resource.name` and check whether public access is intended. +- Search for SAS-authenticated GetBlob to the same account from the same source shortly after. +- If the URI contains `/$system/` or `md-hdd-`, correlate with WireServer access on VMs in the subscription. + + +*False positive analysis* + + +- Public blob websites and CDN origins. Exclude the `azure.resource.id` for approved public accounts. +- New accounts that enable StorageRead for the first time will alert on the first scanner hit. + + +*Response and remediation* + + +- Disable anonymous public access on accounts that should be private. +- If a follow-on SAS read exists, revoke that SAS and review how the URL was obtained. +- Keep StorageRead diagnostic logs enabled on storage accounts of interest. + + +==== Setup + + + +*Required Azure Storage Diagnostic Logs* + + +Enable StorageRead diagnostic logs on Azure Storage Accounts and stream them to the Event Hub used by the Azure +integration. Anonymous vs SAS is `azure.platformlogs.identity.type`. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.platformlogs and + azure.platformlogs.identity.type: Anonymous and + event.action: ( + GetBlob or GetBlobMetadata or GetBlobProperties or GetBlockList or + GetPageRanges or QueryBlobContents or ListBlobs or + GetContainerProperties or GetContainerMetadata or GetContainerAcl + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ +* 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/azure-wireserver-http-request-from-unexpected-user-agent.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-wireserver-http-request-from-unexpected-user-agent.asciidoc new file mode 100644 index 0000000000..666405cf84 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-wireserver-http-request-from-unexpected-user-agent.asciidoc @@ -0,0 +1,171 @@ +[[azure-wireserver-http-request-from-unexpected-user-agent]] +=== Azure WireServer HTTP Request from Unexpected User Agent + +Identifies HTTP requests to Azure WireServer (168.63.129.16) for GoalState, certificates, versions, or HostGAPlugin vmSettings that do not use a known guest-agent user agent. These requests retrieve transport certificates and extension protectedSettings, including embedded SAS URLs. Azure Linux Agent, Windows guest agent, and related platform UAs are excluded. Requests with no user agent are also excluded; that pattern is common for the Windows guest agent. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.http* + +*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://cybercx.com.au/blog/azure-ssrf-metadata/ +* https://www.netspi.com/blog/technical-blog/cloud-pentesting/decrypting-vm-extension-settings-with-azure-wireserver/ +* https://cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services +* https://learn.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16 + +*Tags*: + +* Domain: Cloud +* Domain: Network +* OS: Linux +* OS: Windows +* Platform: Azure +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Data Source: Network Packet Capture +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure WireServer HTTP Request from Unexpected User Agent* + + +Network Packet Capture with HTTP decoding on ports 80 and 32526 shows the URI that Elastic Defend network events +lack. The match is the WireServer path or query, not a scripting-tool user-agent allowlist. + +- `url.query` contains `comp=versions` (discovery) +- `url.query` contains `comp=goalstate` (incarnation, container, extension list, statusUploadBlob pointer) +- `url.query` contains `comp=certificates` (often with request header `x-ms-guest-agent-public-x509-cert`) +- `destination.port == 32526` and `url.path` in `/versions`, `/vmSettings` + +Excluded user agents from lab guest-agent traffic: `WALinuxAgent/*`, `VMAgent/*`, `Python-urllib/*`, +`cpprestsdk/*`, `ACMS/*`, and a missing user agent (Windows guest agent). Curl and Windows PowerShell are not +excluded and will fire. + +`/vmSettings` response bodies are often dropped when they exceed keyword `ignore_above`. The URI, port, and user +agent are sufficient. Do not enable body capture to chase this rule. + + +*Possible investigation steps* + + +- Confirm `url.path`, `url.query`, `destination.port`, and `user_agent.original`. +- GoalState (`comp=goalstate`) is reconnaissance; `comp=certificates` means the client presented a transport + certificate. Look on the host for `openssl req ... LinuxTransport` or a stolen `.crt`/`.key`. +- Correlate with endpoint network events from the same `host.name` to `168.63.129.16` and process start events for + openssl cms decrypt. +- Search StorageRead platform logs for anonymous or SAS GetBlob against the same storage account after the scrape. + + +*False positive analysis* + + +- Administrative curl or other non-agent clients against WireServer during incident response. Exclude the specific + user agent or host after the change window. +- A new Microsoft guest-agent build with an unfamiliar user agent will fire until that UA is excluded. +- Omitting the user agent looks like the Windows guest agent and is not matched. Do not treat a missing UA as + suspicious on its own. + + +*Response and remediation* + + +- Isolate the VM, rotate secrets recovered from vmSettings, and review extension protectedSettings. +- Enable Metadata Security Protocol in audit or enforce mode to restrict WireServer callers. + + +==== Setup + + + +*Setup* + + +Deploy the https://www.elastic.co/docs/reference/integrations/network_traffic[Network Packet Capture] integration +via Fleet on Azure virtual machines. Default HTTP port lists do not include HostGAPlugin. + +Required integration settings: + +- Enable **Capture HTTP Traffic**. +- Set HTTP ports to include **80** (WireServer GoalState, versions, certificates) and **32526** (HostGAPlugin + `/versions`, `/vmSettings`). Without 32526, HostGAPlugin requests are invisible. +- Enable **Monitor Processes** so HTTP events include `process.*` when available. +- Optional: **Send all headers** to retain `x-ms-version` and `x-ms-guest-agent-public-x509-cert` for investigation. + The rule matches URI, port, and user agent, not the certificate PEM. +- Do not enable request or response body capture for this rule. `/vmSettings` bodies are large and often dropped; + other WireServer XML is not required for the match. + + +==== Rule query + + +[source, js] +---------------------------------- +network where event.module == "network_traffic" and +destination.ip == "168.63.129.16" and +user_agent.original != null and +not user_agent.original : ( + "WALinuxAgent*", + "VMAgent*", + "Python-urllib*", + "cpprestsdk*", + "ACMS/*" +) and +( + url.query : ("*comp=versions*", "*comp=goalstate*", "*comp=certificates*") or + (destination.port == 32526 and url.path : ("/versions", "/vmSettings")) +) + +---------------------------------- + +*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 Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/rule-details/azure-wireserver-openssl-certificate-decrypt-or-linuxtransport-generation.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-wireserver-openssl-certificate-decrypt-or-linuxtransport-generation.asciidoc new file mode 100644 index 0000000000..a265e9b645 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-wireserver-openssl-certificate-decrypt-or-linuxtransport-generation.asciidoc @@ -0,0 +1,151 @@ +[[azure-wireserver-openssl-certificate-decrypt-or-linuxtransport-generation]] +=== Azure WireServer OpenSSL Certificate Decrypt or LinuxTransport Generation + +Identifies OpenSSL generating a CN=LinuxTransport certificate or decrypting CMS/PKCS7 payloads with a key that is not the Azure Linux Agent certificate under /var/lib/waagent. Adversaries can scrape WireServer certificates, mint a LinuxTransport identity, and decrypt extension protectedSettings with openssl cms -decrypt or smime -decrypt. + +*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://cybercx.com.au/blog/azure-ssrf-metadata/ +* https://www.netspi.com/blog/technical-blog/cloud-pentesting/decrypting-vm-extension-settings-with-azure-wireserver/ +* https://cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services +* https://gtfobins.github.io/gtfobins/openssl/ + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* OS: Linux +* Use Case: Threat Detection +* Platform: Azure +* Platform: Linux +* Tactic: Credential Access +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure WireServer OpenSSL Certificate Decrypt or LinuxTransport Generation* + + +CyberCX-style WireServer abuse on Linux generates `openssl req -x509 -subj /CN=LinuxTransport`, posts the public +certificate to WireServer `comp=certificates`, then runs `openssl cms -decrypt` or `openssl smime -decrypt` with +`temp.key`, `wireserver.key`, or another non-waagent key to unwrap protectedSettings. + +Benign Azure Linux Agent activity looks like: + +`openssl cms -inform DER -decrypt -recip /var/lib/waagent/.crt -inkey /var/lib/waagent/.prv` + +The Azure Linux Agent is excluded by certificate path in process arguments (`/var/lib/waagent/*`) and by +parent executables `/usr/sbin/waagent` and `/usr/bin/waagent`. This does not exclude Python or +`run-command-extension` as parents because attacker scripts invoked via Run Command use those parents +with a non-waagent key. The agent itself also runs `openssl req ... /CN=LinuxTransport` with output +under `/var/lib/waagent/`; that argument path exclusion covers it. + + +*Possible investigation steps* + + +- Review `process.command_line` and `process.args` for `LinuxTransport`, `wireserver.key`, `temp.key`, `payload.p7m`, + or `payload.pfx`. +- Inspect parent and grandparent: Run Command (`/var/lib/waagent/run-command/`) or an interactive shell is higher + risk than a one-off admin session with a ticket. +- Correlate with network events from curl to `168.63.129.16` ports 80 and 32526 on the same host. +- Search StorageRead logs for anonymous or SAS GetBlob of the same storage account after the decrypt. +- Hunt for the generated key files (`temp.key`, `wireserver.key`) on disk and in `/tmp`. + + +*False positive analysis* + + +- The Azure Linux Agent decrypt path under `/var/lib/waagent/` and waagent parent executables + (`/usr/sbin/waagent`, `/usr/bin/waagent`) are excluded. +- Legitimate certificate tooling that uses `-subj /CN=LinuxTransport` is unexpected; treat as suspicious until proven + otherwise. + + +*Response and remediation* + + +- Isolate the VM, delete attacker-generated keys and decrypted payloads, and rotate secrets that were in + protectedSettings (SAS, connection strings, CSE script contents). +- Rotate the VM managed identity and review extension configuration. +- Revoke any SAS that was replayed from the decrypted settings. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start") and process.name == "openssl" and +( + ( + process.args in ("cms", "smime") and process.args == "-decrypt" + ) or + ( + process.args == "req" and process.args : "*LinuxTransport*" + ) +) and +not process.args like "/var/lib/waagent/*" and +not process.parent.executable like ( + "/usr/sbin/waagent", + "/usr/bin/waagent" +) + +---------------------------------- + +*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: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ diff --git a/docs/detections/prebuilt-rules/rule-details/azure-wireserver-unusual-process-connection.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-wireserver-unusual-process-connection.asciidoc new file mode 100644 index 0000000000..06ef703698 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/azure-wireserver-unusual-process-connection.asciidoc @@ -0,0 +1,163 @@ +[[azure-wireserver-unusual-process-connection]] +=== Azure WireServer Unusual Process Connection + +Identifies shells, LOLBins, GTFOBins, and scripting runtimes connecting to the Azure WireServer / HostGAPlugin address 168.63.129.16 on ports 80 or 32526. The guest agent uses this fabric endpoint for GoalState, certificates, and vmSettings. Adversaries with code execution on an Azure VM (including via Run Command) use curl, PowerShell, openssl, bun, or similar tools to enumerate versions, pull transport certificates, and read HostGAPlugin /vmSettings. Azure guest-agent binaries and system python used by waagent are excluded. Descendants of the guest agent are not excluded: Run Command payloads execute in that tree. + +*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://www.netspi.com/blog/technical-blog/cloud-pentesting/decrypting-vm-extension-settings-with-azure-wireserver/ +* https://cybercx.com.au/blog/azure-ssrf-metadata/ +* https://cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services +* https://learn.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16 + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* OS: Linux +* OS: Windows +* Platform: Azure +* Platform: Windows +* 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* + + + +*Investigating Azure WireServer Unusual Process Connection* + + +`168.63.129.16` is the Azure host-only WireServer (TCP 80) and HostGAPlugin (TCP 32526) address. Elastic Defend +network events record the destination IP, port, and initiating process. They do not include the HTTP path; pair this +alert with Network Packet Capture HTTP events when available (`comp=certificates`, `/vmSettings`, `/versions`). + +Do not treat "child of waagent / WindowsAzureGuestAgent" as benign. Azure Run Command and Custom Script Extension +launch attacker scripts as descendants of those agents. Exclude only the agent binaries themselves, which this query +already omits by matching curl, PowerShell, and similar tools. + +`process.Ext.ancestry` is often empty on these network events, so EQL `descendant of` is not reliable here. + + +*Possible investigation steps* + + +- Review `process.name`, `process.executable`, and `process.command_line` on nearby process start events. Look for + `comp=certificates`, `32526`, `vmSettings`, `LinuxTransport`, or `openssl cms -decrypt`. +- Note `destination.port`: 32526 from curl or PowerShell is uncommon for legitimate guest-agent traffic (agents use + `WaAppAgent.exe`, `WindowsAzureGuestAgent.exe`, `CollectGuestLogs.exe`, or `/usr/bin/python3.10` / waagent). +- Correlate with `169.254.169.254` IMDS access from the same process, especially `/metadata/v1/instanceinfo` (no + Metadata header) or `/metadata/identity/oauth2/token`. +- Check Azure Activity Logs for `runCommand/action` or extensions/write against this VM. +- Search StorageRead platform logs for subsequent SAS GetBlob of vmsettings or cse objects. + + +*False positive analysis* + + +- In-house monitoring that wraps curl to WireServer. Exclude by `process.executable` or a signed parent after + validating the script contents. +- Do not exclude all children of the guest agent; that hides Run Command abuse. + + +*Response and remediation* + + +- Isolate the VM, rotate its managed identity and any SAS recovered from vmSettings, and review extension + protectedSettings for injected configuration. +- Remove unauthorized Run Command resources and Custom Script extensions. +- Consider Azure Metadata Security Protocol (audit/enforce) to restrict which processes may call WireServer. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category: network and host.os.type: (linux or windows) and + destination.ip: "168.63.129.16" and destination.port: (80 or 32526) and + ( + process.name: ( + bash or dash or sh or tcsh or csh or zsh or ksh or fish or mksh or busybox or + bun or bun.exe or node or node.exe or nodejs or deno or deno.exe or + java or java.exe or javaw or javaw.exe or + curl or curl.exe or wget or wget.exe or + powershell.exe or pwsh.exe or pwsh or cmd.exe or + certutil.exe or bitsadmin.exe or mshta.exe or rundll32.exe or + wscript.exe or cscript.exe or regsvr32.exe or + openssl or openssl.exe or nc or ncat or netcat or socat or + python.exe or pythonw.exe or perl or perl.exe or ruby or ruby.exe or + php or php.exe or lua or lua.exe + ) or + process.executable: ( + ./* or /tmp/* or /var/tmp/* or /dev/shm/* or /run/* or /var/run/* or + /home/*/* or /root/* or *\:\\Users\\* or *\:\\ProgramData\\* + ) + ) and + not process.executable: ( + /usr/sbin/waagent or /usr/bin/waagent or /usr/bin/python3* or + /usr/lib/systemd/systemd-resolved or /lib/systemd/systemd-resolved or + *\:\\WindowsAzure\\Packages\\* or *\:\\WindowsAzure\\GuestAgent*\\* or + *\:\\WindowsAzure\\SecAgent\\* + ) + +---------------------------------- + +*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 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/elastic-defend-and-network-security-alerts-correlation.asciidoc b/docs/detections/prebuilt-rules/rule-details/elastic-defend-and-network-security-alerts-correlation.asciidoc index b7a485e816..c7eb16c43d 100644 --- a/docs/detections/prebuilt-rules/rule-details/elastic-defend-and-network-security-alerts-correlation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/elastic-defend-and-network-security-alerts-correlation.asciidoc @@ -1,7 +1,7 @@ [[elastic-defend-and-network-security-alerts-correlation]] === Elastic Defend and Network Security Alerts Correlation -This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto Networks (PANW) and Fortinet Fortigate by host.ip and source.ip. This may indicate that this host is compromised and triggering multi-datasource alerts. +This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto Networks (PANW), Fortinet Fortigate and Suricata by host.ip and source.ip. This may indicate that this host is compromised and triggering multi-datasource alerts. *Rule type*: esql @@ -27,8 +27,9 @@ This rule correlate any Elastic Defend alert with a set of suspicious events fro * Data Source: Elastic Defend * Data Source: Fortinet * Data Source: PAN-OS +* Data Source: Suricata -*Version*: 7 +*Version*: 8 *Rule authors*: @@ -119,13 +120,13 @@ FROM logs-* metadata _id // Suricata (data_stream.dataset == "suricata.eve" and message in ("Command and Control Traffic", "Potentially Bad Traffic", "A Network Trojan was detected", "Detection of a Network Scan", "Domain Observed Used for C2 Detected", "Malware Command and Control Activity Detected")) -// extract source.ip from PANW or Fortigate events and host.ip from Elastic Defend alert -|eval fw_alert_source_ip = CASE(data_stream.dataset in ("panw.panos", "fortinet_fortigate.log"), source.ip, null), +// extract source.ip from PANW, Fortigate or Suricata events and host.ip from Elastic Defend alert +|eval fw_alert_source_ip = CASE(data_stream.dataset in ("panw.panos", "fortinet_fortigate.log", "suricata.eve"), source.ip, null), elastic_defend_alert_host_ip = CASE(event.module == "endpoint" and data_stream.dataset == "endpoint.alerts", host.ip, null) | eval Esql.source_ip = COALESCE(fw_alert_source_ip, elastic_defend_alert_host_ip) | where Esql.source_ip is not null -// group by host_source_ip shared between FG/PANW and Elastic Defend +// group by host_source_ip shared between FG/PANW/Suricata and Elastic Defend | stats Esql.alerts_count = COUNT(*), Esql.event_module_distinct_count = COUNT_DISTINCT(event.module), Esql.message_values_distinct_count = COUNT_DISTINCT(message), diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-device-bound-prt-from-unusual-device-ip.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-device-bound-prt-from-unusual-device-ip.asciidoc new file mode 100644 index 0000000000..6cb3c39838 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/entra-id-device-bound-prt-from-unusual-device-ip.asciidoc @@ -0,0 +1,175 @@ +[[entra-id-device-bound-prt-from-unusual-device-ip]] +=== Entra ID Device-Bound PRT from Unusual Device IP + +Detects a first-party FOCI tooling client (Azure CLI, PowerShell, VS Code, Graph CLI, Azure AD PowerShell, or Visual Studio) redeeming a device-bound Primary Refresh Token (PRT) for Microsoft Graph, SharePoint/OneDrive, or Exchange Online from a source IP that has not been seen with that deviceid. Replay events are limited to compliant or Intune-managed devices. Adversaries who steal a WAM PRT SSO cookie replay it off-box; the token keeps the workstation deviceid, so this pair is new even when Windows Sign-In for that device is outside a correlation window. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* 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.armadin.com/blog-posts/prtremote-extract-prt-cookies-remotely-with-interactivetoken-scheduled-task +* https://github.com/armadin-public/PRTremote +* https://github.com/dmcxblue/ANIMO/blob/master/helpers/scripts/GrabTokenAzureAD/PrtExtractor.cs +* https://github.com/rvrsh3ll/TokenTactics +* https://github.com/Gerenios/AADInternals + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Platform: Entra ID +* Tactic: Credential Access +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Rule Type: New Terms + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Device-Bound PRT from Unusual Device IP* + + +This rule fires when a tooling FOCI client redeems a device-bound PRT from a `source.ip` that has not appeared with that `device_id` in the prior 5 days. Unlike **Entra ID Device-Bound PRT Replay via First-Party App from Unusual IP**, it does not need a Windows Sign-In or WAM event in the same window — so a workstation that last signed in yesterday still alerts when the cookie is redeemed from a new address. + +PRTremote and similar harvest tools steal a WAM PRT SSO cookie and POST it from attacker infrastructure. The issued token keeps the *workstation* deviceid, so Conditional Access that requires a compliant device can succeed. Replay events must be `is_compliant` or `is_managed`. The stolen cookie nonce is typically valid for about five minutes; that is the attacker’s redeem window, not this rule’s history. + +This is not ConsentFix / OAuth-code phishing. Those flows show `OAuth2:Authorize` with `Redirect` and often lack a bound compliant device. + + +*Possible investigation steps* + + +- Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.device_detail.device_id`, `azure.signinlogs.properties.device_detail.display_name`, and `source.ip`. Confirm `incoming_token_type` is `primaryRefreshToken` and `device_detail.is_compliant` / `is_managed` are true. +- Compare `azure.signinlogs.properties.app_display_name` and `user_agent.original` with the resource (`resource_display_name`). A cookie POST through WAM can show a Trident/MSIE user agent on the Azure CLI client ID; that is the same IE stack legitimate Windows `az login` uses when it brokers through WAM, so it is triage context, not a detection key. TokenTactics commonly presents as Microsoft Office (that client is omitted here; hunt it separately if harvest is already confirmed). +- Hunt prior Windows Sign-In / `Windows-AzureAD-Authentication-Provider/1.0` events for the same deviceid. If those IPs differ from `source.ip`, treat this as the same story as the ES|QL companion. A Microsoft-owned ASN (including 8075) does not clear the alert. +- Hunt endpoint telemetry for the same user or device display name as `host.name`: InteractiveToken scheduled tasks, `svchost.exe` (Schedule) → `cmd.exe` → `BrowserCore.exe`, or files `formatted_nonce.txt` / `prt_cookie.txt`. +- Review Graph, SharePoint, and mailbox activity after the sign-in for directory, file, or mail enumeration. + + +*False positive analysis* + + +- Developers who run Azure CLI, Graph CLI, or VS Code from a new network while WAM still attaches the workstation deviceid. Exception known Cloud Shell / jump-host IPs after confirming the client actually ran there. +- First use of a tooling client on a new device, or the first time a laptop appears on a new ISP, will fire once per `(device_id, source.ip)` pair and then age out of novelty. +- Hybrid-joined workstations that report both `is_compliant` and `is_managed` as false (no Intune) will not match. Hunt those deviceids separately if harvest is already confirmed. +- Microsoft Teams, Office, OneDrive SyncEngine, Authentication Broker, Outlook Mobile, Bing, Azure Portal, and Office 365 Management are excluded. Do not treat their absence as a miss. + + +*Response and remediation* + + +- Contact the user to confirm whether they ran the first-party client from `source.ip`. +- If unauthorized, revoke refresh tokens and primary refresh tokens for the user. The deviceid on the token is often the *legitimate* workstation — do not delete that device as if it were a ROADtx registration until you confirm otherwise. +- Isolate the workstation, hunt for InteractiveToken scheduled tasks and BrowserCore harvest, and treat the admin identity that registered the task as a second compromised principal. + + +==== Setup + + +The Azure Fleet integration (or Filebeat Azure module) with Microsoft Entra ID sign-in logs is required. Ingest `SignInLogs` and `NonInteractiveUserSignInLogs` into `logs-azure.signinlogs-*`. + +See https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins[Microsoft Entra ID sign-in logs] and the https://docs.elastic.co/integrations/azure[Azure integration]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.signinlogs and + event.outcome: success and + azure.signinlogs.properties.status.error_code: 0 and + azure.signinlogs.properties.incoming_token_type: "primaryRefreshToken" and + azure.signinlogs.properties.device_detail.device_id: * and + source.ip: * and + ( + azure.signinlogs.properties.device_detail.is_compliant: true or + azure.signinlogs.properties.device_detail.is_managed: true + ) and azure.signinlogs.properties.app_id: ( + "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or + "1950a258-227b-4e31-a9cf-717495945fc2" or + "aebc6443-996d-45c2-90f0-388ff96faa56" or + "14d82eec-204b-4c2f-b7e8-296a70dab67e" or + "1b730954-1685-4b74-9bfd-dac224a7b894" or + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" + ) and azure.signinlogs.properties.resource_id: ( + "00000003-0000-0000-c000-000000000000" or + "00000003-0000-0ff1-ce00-000000000000" or + "6a9b9266-8161-4a7b-913a-a9eda19da220" or + "00000002-0000-0ff1-ce00-000000000000" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-device-bound-prt-replay-via-first-party-app-from-unusual-ip.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-device-bound-prt-replay-via-first-party-app-from-unusual-ip.asciidoc new file mode 100644 index 0000000000..763ea09a95 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/entra-id-device-bound-prt-replay-via-first-party-app-from-unusual-ip.asciidoc @@ -0,0 +1,226 @@ +[[entra-id-device-bound-prt-replay-via-first-party-app-from-unusual-ip]] +=== Entra ID Device-Bound PRT Replay via First-Party App from Unusual IP + +Detects a first-party FOCI tooling client (Azure CLI, PowerShell, VS Code, Graph CLI, Azure AD PowerShell, or Visual Studio) redeeming a device-bound Primary Refresh Token (PRT) for Microsoft Graph, SharePoint/OneDrive, or Exchange Online from an IP that is not among that user and device's Windows Sign-In or WAM addresses. Replay events are limited to compliant or Intune-managed devices: the stolen cookie keeps the workstation deviceid, so compliant-device Conditional Access can succeed off-box. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-24h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.armadin.com/blog-posts/prtremote-extract-prt-cookies-remotely-with-interactivetoken-scheduled-task +* https://github.com/armadin-public/PRTremote +* https://github.com/dmcxblue/ANIMO/blob/master/helpers/scripts/GrabTokenAzureAD/PrtExtractor.cs +* https://github.com/rvrsh3ll/TokenTactics +* https://github.com/Gerenios/AADInternals + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Platform: Entra ID +* Tactic: Credential Access +* Tactic: Defense Evasion +* Tactic: Initial Access +* Resources: Investigation Guide +* Rule Type: ESQL + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Device-Bound PRT Replay via First-Party App from Unusual IP* + + +Adversaries who steal a WAM PRT SSO cookie (BrowserCore / InteractiveToken harvest) redeem it off-box for Microsoft Graph, SharePoint/OneDrive, or Exchange Online using a first-party FOCI client. PRTremote uses Azure CLI (`04b07795-8ddb-461a-bbee-02f9e1bf7b46`); TokenTactics and AADInternals can use Azure AD PowerShell (`1b730954-1685-4b74-9bfd-dac224a7b894`) or Microsoft Office (`d3590ed6-52b3-4102-aeff-aad2292ab01c`) when refreshing a PRT into a Graph, Outlook, or SharePoint token. This rule keys on CLI / PowerShell / VS Code / Visual Studio, not Teams, Office, OneDrive SyncEngine, Authentication Broker, Outlook Mobile, Bing, or Azure Portal — those clients routinely egress on a different IP than Windows Sign-In. Hunt Office-client PRT separately if harvest is already confirmed. The issued access token carries the *workstation* `deviceid`, so Conditional Access policies that require a compliant device can succeed even though the redeeming IP is not the device. Replay events must be `is_compliant` or `is_managed` so the join tracks a stolen enrolled workstation PRT, not an unmanaged ROADtx device. + +This is not ConsentFix / OAuth-code phishing. Those flows show `OAuth2:Authorize` with `Redirect` and often lack a bound compliant device on the Graph token. Do not close this alert by following the first-party OAuth phishing playbook alone. + + + +*Possible investigation steps* + + +- Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.device_detail.device_id`, and `source.ip`. Confirm `incoming_token_type` on the replay events is `primaryRefreshToken` and `device_detail.is_compliant` / `is_managed` are true. `Esql.resource_display_name_values` should be Microsoft Graph, Office 365 SharePoint Online, OneDrive for Business, and/or Office 365 Exchange Online. +- Treat `Esql.source_ip_device_values` as the workstation (Windows Sign-In / `Windows-AzureAD-Authentication-Provider/1.0`) — the device the PRT was bound to, and the likely theft origin. Treat `source.ip` / `Esql.source_ip_replay_values` as Graph / SharePoint / Exchange PRT IPs that are not in that device-session set (the replay actor). On-box FOCI from the workstation IP is excluded from the replay set. The harvest emulation showed workstation public IP versus attacker SNAT — including Azure ASN 8075, so a Microsoft-owned ASN does not clear the alert. The stolen PRT cookie nonce is typically valid for about five minutes; that is the attacker’s redeem window, not this rule’s lookback. The workstation may have signed in hours earlier, so the query correlates 24 hours of Windows Sign-In / WAM IPs with the replay. +- Inspect `Esql.app_display_name_values` and `Esql.user_agent_original_values`. A cookie POST through WAM can show a Trident/MSIE user agent on the Azure CLI client ID; that is the same IE stack legitimate Windows `az login` uses when it brokers through WAM, so it is triage context, not a detection key. TokenTactics Graph refresh commonly presents as Microsoft Office (omitted here). A follow-on `python-requests/*` Graph token from the same session is tooling, not the first-party binary on the workstation. +- Hunt endpoint telemetry for the same user or `device_detail.display_name` as `host.name`: `svchost.exe` (Schedule) → `cmd.exe` → `BrowserCore.exe` with `<` / `>` redirection, or files `formatted_nonce.txt` / `prt_cookie.txt`. +- Intune audit (`create-clientcertificate`) is enrollment context only; it will not fire on the harvest. Use it as optional join on user OID, not as coverage. +- Review Graph, SharePoint, and mailbox activity after the replay for directory, file, or mail enumeration. + + +*False positive analysis* + + +- Developers who run Azure CLI, Graph CLI, or VS Code from a different egress than Windows Sign-In while WAM still attaches the workstation deviceid. Exception known Cloud Shell / jump-host IPs after confirming the client actually ran there. +- Microsoft Teams, Office, OneDrive SyncEngine, Authentication Broker, Outlook Mobile, Bing, Azure Portal, and Office 365 Management Graph PRT are excluded. Do not treat their absence as a miss; they are omitted because split-tunnel M365 egress is routine. +- First sign-in of a new device can have sparse Windows Sign-In history in the 24-hour window; widen the hunt before responding. +- Hybrid-joined workstations that report both `is_compliant` and `is_managed` as false (no Intune) will not match the replay branch. Hunt those deviceids separately if harvest is already confirmed. + + +*Response and remediation* + + +- Contact the user to confirm whether they ran the first-party client in `Esql.app_display_name_values` from the replay IP. +- If unauthorized, revoke refresh tokens and primary refresh tokens for the user. The deviceid on the token is often the *legitimate* workstation — do not delete that device as if it were a ROADtx registration until you confirm otherwise. +- Isolate the workstation, hunt for InteractiveToken scheduled tasks and BrowserCore harvest, and treat the admin identity that registered the task as a second compromised principal. + + +==== Setup + + +The Azure Fleet integration (or Filebeat Azure module) with Microsoft Entra ID sign-in logs is required. Ingest `SignInLogs` and `NonInteractiveUserSignInLogs` into `logs-azure.signinlogs-*` so Windows Sign-In / WAM device activity and FOCI Graph, SharePoint, and Exchange token issuance are both available for the join. + +See https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins[Microsoft Entra ID sign-in logs] and the https://docs.elastic.co/integrations/azure[Azure integration]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-* +// find successful sign-in events where a managed device exists +| where event.dataset == "azure.signinlogs" + and azure.signinlogs.properties.status.error_code == 0 + and azure.signinlogs.properties.device_detail.device_id is not null + +// filter for device sign-in events from Windows Sign-In or WAM (login session) +| eval Esql.is_device_session = azure.signinlogs.properties.app_display_name == "Windows Sign In" + or user_agent.original == "Windows-AzureAD-Authentication-Provider/1.0" + +// filter for tooling FOCI clients that can redeem a PRT (replay) +| eval Esql.is_prt_replay = azure.signinlogs.properties.app_id in ( + "04b07795-8ddb-461a-bbee-02f9e1bf7b46", // Microsoft Azure CLI + "1950a258-227b-4e31-a9cf-717495945fc2", // Microsoft Azure PowerShell + "aebc6443-996d-45c2-90f0-388ff96faa56", // Visual Studio Code + "14d82eec-204b-4c2f-b7e8-296a70dab67e", // Microsoft Graph Command Line Tools + "1b730954-1685-4b74-9bfd-dac224a7b894", // Azure Active Directory PowerShell + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" // Visual Studio + ) + + // target resource are common adversary targets for access + and azure.signinlogs.properties.resource_id in ( + "00000003-0000-0000-c000-000000000000", // Microsoft Graph + "00000003-0000-0ff1-ce00-000000000000", // Office 365 SharePoint Online + "6a9b9266-8161-4a7b-913a-a9eda19da220", // OneDrive for Business + "00000002-0000-0ff1-ce00-000000000000" // Office 365 Exchange Online + ) + and azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken" + and ( + azure.signinlogs.properties.device_detail.is_compliant == true + or azure.signinlogs.properties.device_detail.is_managed == true + ) + +// device session or PRT replay event have to exist +| where Esql.is_device_session or Esql.is_prt_replay + +// aggregate entities for both device session and PRT replay events +// aggregate by user and device +| stats + Esql.source_ip_device_values = values(source.ip) where Esql.is_device_session, + Esql.source_ip_replay_values = values(source.ip) where Esql.is_prt_replay, + Esql.event_count_replay = count(*) where Esql.is_prt_replay, + Esql.event_count_device_session = count(*) where Esql.is_device_session, + Esql.user_principal_name_values = values(azure.signinlogs.properties.user_principal_name), + Esql.app_display_name_values = values(azure.signinlogs.properties.app_display_name) where Esql.is_prt_replay, + Esql.resource_id_values = values(azure.signinlogs.properties.resource_id) where Esql.is_prt_replay, + Esql.resource_display_name_values = values(azure.signinlogs.properties.resource_display_name) where Esql.is_prt_replay, + Esql.device_display_name_values = values(azure.signinlogs.properties.device_detail.display_name), + Esql.user_agent_original_values = values(user_agent.original) where Esql.is_prt_replay, + Esql.device_is_compliant_values = values(azure.signinlogs.properties.device_detail.is_compliant) where Esql.is_prt_replay, + Esql.device_is_managed_values = values(azure.signinlogs.properties.device_detail.is_managed) where Esql.is_prt_replay, + Esql.authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement) where Esql.is_prt_replay, + Esql.conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status) where Esql.is_prt_replay, + Esql.earliest_timestamp = min(@timestamp), + Esql.latest_timestamp = max(@timestamp) + by azure.signinlogs.properties.user_id, azure.signinlogs.properties.device_detail.device_id + +// filter for PRT replay events that have at least one replay IP +| where Esql.event_count_replay > 0 + and Esql.event_count_device_session > 0 + and Esql.source_ip_replay_values is not null + and Esql.source_ip_device_values is not null + +// expand the replay IP list and keep only IPs that are not in the device-session set +| mv_expand Esql.source_ip_replay_values +| where not mv_contains(Esql.source_ip_device_values, Esql.source_ip_replay_values) +| eval Esql.source_ip_replay = Esql.source_ip_replay_values, + user.id = azure.signinlogs.properties.user_id, + source.ip = Esql.source_ip_replay_values +| keep + user.id, + source.ip, + azure.signinlogs.properties.user_id, + azure.signinlogs.properties.device_detail.device_id, + Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-windows-hello-for-business-credential-registered.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-windows-hello-for-business-credential-registered.asciidoc new file mode 100644 index 0000000000..fa087f55fc --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/entra-id-windows-hello-for-business-credential-registered.asciidoc @@ -0,0 +1,117 @@ +[[entra-id-windows-hello-for-business-credential-registered]] +=== Entra ID Windows Hello for Business Credential Registered + +Identifies the first-seen registration of a Windows Hello for Business (WHfB) credential for a Microsoft Entra ID user from a given source ASN in a tenant, based on a prefixed historic window. Enrollment is commonly part of legitimate onboarding or passwordless rollout and is not inherently malicious. Adversaries who have obtained a token that satisfies fresh (NGC) multi-factor authentication, for example by borrowing an existing WHfB key or passkey, can also enroll their own WHfB credential to establish durable, phishing-resistant persistence that survives password resets and standard session revocation. Correlate first-seen enrollments with the sign-in and device state that preceded them. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.auditlogs-* + +*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://dirkjanm.io/borrowing-windows-hello-keys/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Platform: Entra ID +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Persistence +* Rule Type: New Terms +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Windows Hello for Business Credential Registered* + + +This is a first-seen (new_terms) signal: a WHfB credential was registered for a tenant/user/source-ASN combination not observed in the prior 14 days. Enrollment is often legitimate onboarding, but adversaries abuse the same action as persistence - after borrowing an existing WHfB key or passkey to satisfy fresh MFA, they enroll their own credential, which survives password resets and ordinary session revocation. + + +*Possible investigation steps* + +- Identify the target (`target_resources.0.user_principal_name`) and initiator (`initiated_by.user.userPrincipalName`), confirm whether WHfB enrollment was expected, and check whether the source ASN is new for that user. +- Correlate with `azure.signinlogs` shortly before for a deviceless WHfB/passkey sign-in, device-code flow, or attacker device registration/PRT issuance; an additional credential from a new ASN on an established account is more suspicious. Examine the preceding sign-in's source IP/geo and user agent for automation or hosting/VPS origins. + + +*False positive analysis* + +- First-time WHfB enrollment during onboarding/passwordless rollout is expected; repeat enrollments from the same tenant/user/ASN within 14 days don't fire. +- Users traveling or switching ISP/VPN may appear as a new ASN - validate against known networks before treating as suspicious. + + +*Response and remediation* + +- If unauthorized, delete the WHfB credential and any attacker-registered device via Graph or the Entra portal, revoke sessions and refresh tokens (delete devices first, to break device-bound PRT persistence), reset credentials, and re-enroll from a trusted device. +- Review the sign-in that authorized the enrollment to determine the initial access vector. + + +==== Setup + + + +*Required Microsoft Entra ID Audit Logs* + +This rule requires the Azure integration with Microsoft Entra ID Audit logs enabled and collected via Azure Event Hub. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" and + azure.auditlogs.operation_name: "Add Windows Hello for Business credential" and + event.outcome: ("Success" or "success") and + azure.tenant_id: * and + azure.auditlogs.properties.initiated_by.user.userPrincipalName: * and + source.as.number: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-windows-hello-or-passkey-sign-in-from-unregistered-device.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-windows-hello-or-passkey-sign-in-from-unregistered-device.asciidoc new file mode 100644 index 0000000000..290d541222 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/entra-id-windows-hello-or-passkey-sign-in-from-unregistered-device.asciidoc @@ -0,0 +1,129 @@ +[[entra-id-windows-hello-or-passkey-sign-in-from-unregistered-device]] +=== Entra ID Windows Hello or Passkey Sign-in from Unregistered Device + +Identifies a Microsoft Entra ID sign-in that is satisfied by a phishing-resistant, device-bound credential (Windows Hello for Business, FIDO2 security key, or passkey) while carrying no device identifier. Windows Hello for Business (WHfB) and passkey credentials are bound to a device's TPM, so a genuine sign-in with one of these methods is normally accompanied by the registered device it lives on. A WHfB or passkey assertion that authenticates with an empty `device_detail.device_id` indicates the underlying key material is being used away from its bound device, for example by an adversary who extracted the key (or signed an assertion with it) and replayed it from attacker infrastructure to mint device-agnostic tokens. This is the core primitive of the "borrowing Windows Hello keys" technique and is a strong precursor to attacker device registration and Primary Refresh Token (PRT) issuance. Cross-tenant (B2B) sign-ins are excluded because they are a common benign source of empty device identifiers. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.signinlogs-* + +*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://dirkjanm.io/borrowing-windows-hello-keys/ +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Platform: Entra ID +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Initial Access +* Rule Type: New Terms +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Windows Hello or Passkey Sign-in from Unregistered Device* + + +WHfB and passkey credentials are bound to a device's TPM, so a legitimate sign-in with one of these methods is normally accompanied by its registered device. A same-tenant sign-in with an empty `device_detail.device_id` means the key material is being used away from its bound device - the core signal of the "borrowing Windows Hello keys" technique, where an adversary replays a WHfB/NGC key or passkey to mint device-agnostic tokens from their own infrastructure. + + +*Possible investigation steps* + +- Identify the user via `user_principal_name` and confirm `authentication_details.authentication_method` is WHfB, FIDO2, or a passkey with `device_detail.device_id` empty (a `device_id` present on an unmanaged device is a different, noisier condition, not this rule). +- Review `app_id`/`resource_display_name` for Graph or Device Registration Service access right after, check `source.ip`, `source.geo.*`, and `user_agent.original` for automation (python-requests) or hosting/VPS ASNs (ROADtools/roadtx), and pivot on `user_id` in `azure.auditlogs` for a subsequent "Register device" or "Add Windows Hello for Business credential" event; if the user didn't enroll a new key/passkey, treat it as compromised. + + +*False positive analysis* + +- Initial passwordless onboarding can briefly produce this sign-in before device registration completes; correlate with the registration timeline. + + +*Response and remediation* + +- Treat the key/passkey as compromised: delete the credential and any attacker-registered device via Graph/the Entra portal, revoke sessions/refresh tokens (delete devices first, since that breaks device-bound PRT persistence), and re-enroll from a trusted device. +- Hunt for device registrations and PRT issuance after the sign-in, and consider Conditional Access requiring device compliance for sensitive resources. + + +==== Setup + + + +*Required Microsoft Entra ID Sign-In Logs* + +This rule requires the Azure integration with Microsoft Entra ID Sign-In logs to be enabled and configured to collect sign-in logs via Azure Event Hub. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and + event.category: "authentication" and + azure.signinlogs.result_signature: "SUCCESS" and + azure.signinlogs.properties.user_type: "Member" and + azure.signinlogs.properties.authentication_details.authentication_method: ( + "Windows Hello for Business" or *passkey* or FIDO2* or *Passkey* + ) and + azure.signinlogs.properties.device_detail.device_id: ("" or not *) and + azure.signinlogs.properties.cross_tenant_access_type: "none" and + azure.signinlogs.properties.user_principal_name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* 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/file-with-suspicious-double-extension-created-by-web-server.asciidoc b/docs/detections/prebuilt-rules/rule-details/file-with-suspicious-double-extension-created-by-web-server.asciidoc new file mode 100644 index 0000000000..4ab46572ec --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/file-with-suspicious-double-extension-created-by-web-server.asciidoc @@ -0,0 +1,188 @@ +[[file-with-suspicious-double-extension-created-by-web-server]] +=== File with Suspicious Double Extension Created by Web Server + +This rule detects when a web server process creates a file with a double extension, where the real extension is a non-web extension. This is a common technique used by attackers to bypass security measures and to hide the true nature of the file. + +*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*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Persistence +* Tactic: Initial Access +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Rule Type: Event Correlation (EQL) +* 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 File with Suspicious Double Extension Created by Web Server* + + +This rule identifies Linux web server processes creating files whose names combine a web-executable suffix with a misleading image, archive, script, or binary extension, a pattern often used to conceal malicious content and bypass upload controls. For example, an attacker exploiting an upload endpoint may write `shell.php.jpg` into a served directory, then rely on a permissive or manipulated server configuration to execute it as a web shell for persistent remote access. + + +*Possible investigation steps* + + +- Record the file’s full path, ownership, permissions, timestamps, cryptographic hash, MIME type, and magic bytes, then safely inspect its contents for obfuscated code, command execution, credential theft, or web-shell functionality. +- Review virtual-host, handler, rewrite, and directory configuration to determine whether the file is web-accessible or interpreted as executable content despite its final extension. +- Correlate the creation time with HTTP access, application, proxy, and authentication logs to identify the originating request, source address, user session, upload endpoint, and related reconnaissance or exploitation attempts. +- Examine the creating process lineage and subsequent activity for spawned shells, interpreters, system utilities, outbound connections, privilege escalation, persistence changes, or additional file writes. +- Hunt across endpoints and web logs for the file hash, naming pattern, source address, request indicators, and similar artifacts, and isolate the server while preserving evidence if malicious activity is confirmed. + + +*False positive analysis* + + +- A legitimate upload or content-management workflow may preserve a user-supplied filename such as `template.php.jpg`; verify the associated HTTP request, authenticated user, expected upload path, file MIME type, and application behavior. +- A deployment, backup, or testing process run through a web application may generate files such as `page.jsp.zip` or `handler.cgi.sh`; verify the change record, process lineage, file contents, ownership, and whether the destination is expected and non-executable. + + +*Response and remediation* + + +- Isolate the affected web server from untrusted networks, restrict administrative access, preserve the suspicious file and relevant logs, and block identified source addresses, hashes, domains, and URLs. +- Remove the double-extension file and any related web shells, unauthorized accounts, SSH keys, cron jobs, systemd units, startup scripts, modified web-server handlers, and attacker-created files after preserving forensic copies. +- Rotate exposed application, database, service-account, API, and administrative credentials, revoke active sessions and tokens, and replace potentially compromised TLS or SSH keys. +- Escalate immediately to incident response if the web server spawned shells, made suspicious outbound connections, accessed credentials, gained elevated privileges, or produced evidence of lateral movement or additional compromised hosts. +- Rebuild the server from a known-good image or restore verified clean application content and configuration, patch the exploited web application or server component, and validate integrity before returning it to service. +- Prevent recurrence by enforcing upload allowlists and content validation, storing uploads outside executable web roots, disabling script execution in upload directories, applying least-privilege permissions, and monitoring for similar filenames and web-process child activity. + + +==== 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] +---------------------------------- +file where host.os.type == "linux" and event.action != "deletion" and +( + process.name in ( + "nginx", "apache2", "httpd", "caddy", "lighttpd", "httpd.worker", "httpd-worker", "httpd-prefork", + "php-cgi", "php-fcgi", "php-cgi.cagefs", "frankenphp", "lshttpd", "litespeed", "openlitespeed", + "fcgiwrap", "uwsgi", "daphne", "uvicorn", "hypercorn", "granian", "waitress-serve", "flask", "puma", + "unicorn", "unicorn_rails", "thin", "rackup", "mongrel_rails", "starman", "plackup", "twiggy", + "hypnotoad", "starlet", "unitd", "unitd-debug", "java", "node", "nodejs", "varnishd" + ) or + process.name like ( + "php-fpm*", "lsphp*", "gunicorn*", "*.cgi", "*.fcgi", "mono*", "xsp*", "mod-mono-server*", + "fastcgi-mono-server*", "python*", "ruby*", "perl*", "lua*" + ) +) and +file.name like~ ( + "*.php.*", "*.php3.*", "*.php4.*", "*.php5.*", "*.php7.*", "*.php8.*", "*.phtml.*", "*.pht.*", + "*.asp.*", "*.aspx.*", "*.ashx.*", "*.asmx.*", "*.jsp.*", "*.jspx.*", "*.cfm.*", "*.cfc.*", + "*.cshtml.*", "*.razor.*", "*.cgi.*", "*.fcgi.*", "*.php;*", "*.asp;*", "*.aspx;*", "*.jsp;*" +) and +file.extension in~ ( + "jpg", "jpeg", "png", "gif", "webp", "bmp", "ico", "tif", "tiff", "svg", "zip", + "sh", "elf" +) + +---------------------------------- + +*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: 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/ diff --git a/docs/detections/prebuilt-rules/rule-details/first-seen-network-flow-exporter-followed-by-suspicious-source-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/first-seen-network-flow-exporter-followed-by-suspicious-source-activity.asciidoc new file mode 100644 index 0000000000..6ffc3e5c44 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/first-seen-network-flow-exporter-followed-by-suspicious-source-activity.asciidoc @@ -0,0 +1,196 @@ +[[first-seen-network-flow-exporter-followed-by-suspicious-source-activity]] +=== First Seen Network Flow Exporter Followed by Suspicious Source Activity + +Identifies a newly observed NetFlow, IPFIX, or sFlow exporter IP followed by another detection alert with medium-or-higher severity or an elevated risk score, where that exporter IP is the source of the detected activity in the same data stream namespace. This correlation adds behavioral evidence that can help distinguish routine exporter onboarding from a potentially unauthorized or compromised exporter introduced as part of defense evasion. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/solutions/security/detect-and-alert/about-building-block-rules +* https://www.elastic.co/docs/reference/integrations/netflow +* https://www.elastic.co/docs/reference/integrations/goflow2 +* https://datatracker.ietf.org/doc/html/rfc7011 +* https://sflow.org/sflow_version_5.txt + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Rule Type: Higher-Order Rule +* Data Source: Elastic Security +* Data Source: NetFlow +* Data Source: GoFlow2 +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Seen Network Flow Exporter Followed by Suspicious Source Activity* + + +This higher-order rule correlates the building-block alert "First Seen Network Flow Exporter" with a later detection +alert that has medium-or-higher severity or an elevated risk score within 30 minutes. The new exporter's `observer.ip` +must equal the later alert's `source.ip`, and both alerts must share the same `data_stream.namespace`. + +This relationship provides stronger evidence than suspicious flows merely reported by the exporter. It indicates that +the exporter address itself was subsequently identified as the source of separately detected activity. It does not by +itself prove telemetry injection, exporter compromise, or the addition of a rogue collector. A rogue collector receives +flow exports and generally requires network-device configuration or audit telemetry to detect directly. + + +*Possible investigation steps* + + +- Review the `observer.ip`, `source.ip`, correlation timestamps, and suspicious rule names and IDs surfaced in the + alert. Pivot to the contributing alerts to review their risk score, destination, host, and user context. +- Confirm that `observer.ip` belongs to the newly observed exporter and that NAT, shared addressing, or stale asset + records did not cause the correlation. +- Examine the second alert's rule name and determine what behavior associated the exporter address with `source.ip`. +- Verify the exporter's owner, device type, software version, management plane, recent configuration changes, and + approved collector destinations. +- Review authentication, process, network-device audit, and configuration telemetry for the exporter around the + correlation window. +- Compare observation domains, exporter version, uptime, sequence values, templates, sampling configuration, and flow + volume with established exporters. +- Search for additional alerts involving the exporter address and for malformed, implausible, or conflicting flow + records received from it. + + +*False positive analysis* + + +- Validate recent device onboarding, migrations, disaster-recovery activation, penetration tests, vulnerability scans, + and monitoring validation. +- Determine whether `source.ip` represents the exporter itself or a shared NAT, proxy, scanner, or management address. +- Confirm that the correlated source alert is a meaningful behavioral detection rather than an expected administrative + or discovery event. + + +*Response and remediation* + + +- If the exporter is unauthorized or compromised, restrict it at the collector boundary and isolate its management + plane as appropriate. +- Preserve flow records, source alerts, configuration history, authentication events, and network evidence. +- Remove unauthorized export configuration, restore trusted device configuration, rotate affected credentials, and + review collector ACLs and authentication. + + +==== Setup + + + +*Setup* + + +Enable the building-block rule "First Seen Network Flow Exporter" and detection rules that can identify suspicious +activity with `source.ip` populated. The building-block rule requires decoded NetFlow, IPFIX, or sFlow records from the +Elastic NetFlow (`netflow.log`) or GoFlow2 (`goflow2.sflow`) integration. + +The higher-order rule searches Elastic Security alert indices. The correlated source alert must preserve the exporter +address in `source.ip` and preserve `data_stream.namespace`; alerts without either field cannot contribute to this +correlation. Building-block, higher-order, machine-learning, new-terms, threat-match, and deprecated-rule alerts are +excluded as the second event. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM .alerts-security.* +| WHERE event.kind == "signal" + AND data_stream.namespace IS NOT NULL + AND ( + (kibana.alert.rule.rule_id == "dfe3f626-4224-417e-aff1-8ef9a72c3191" AND observer.ip IS NOT NULL) + OR + (source.ip IS NOT NULL + AND kibana.alert.rule.name IS NOT NULL + AND kibana.alert.rule.rule_id IS NOT NULL + AND kibana.alert.rule.rule_id != "dfe3f626-4224-417e-aff1-8ef9a72c3191" + AND (kibana.alert.risk_score >= 47 OR kibana.alert.severity IN ("medium", "high", "critical")) + AND KQL("""NOT kibana.alert.building_block_type : *""") + AND NOT kibana.alert.rule.type IN ("machine_learning", "new_terms", "threat_match") + AND NOT kibana.alert.rule.name LIKE "Deprecated - *" + AND NOT KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)) + ) +| EVAL + Esql.is_exporter_alert = kibana.alert.rule.rule_id == "dfe3f626-4224-417e-aff1-8ef9a72c3191", + Esql.is_suspicious_source_alert = kibana.alert.rule.rule_id != "dfe3f626-4224-417e-aff1-8ef9a72c3191", + Esql.correlation_ip = CASE(Esql.is_exporter_alert, observer.ip, source.ip), + Esql.exporter_alert_timestamp = CASE(Esql.is_exporter_alert, @timestamp, null), + Esql.suspicious_source_alert_timestamp = CASE(Esql.is_suspicious_source_alert, @timestamp, null), + Esql.suspicious_rule_name = CASE(Esql.is_suspicious_source_alert, kibana.alert.rule.name, null), + Esql.suspicious_rule_id = CASE(Esql.is_suspicious_source_alert, kibana.alert.rule.rule_id, null) +| WHERE Esql.correlation_ip IS NOT NULL +| STATS + Esql.exporter_alert_count = SUM(CASE(Esql.is_exporter_alert, 1, 0)), + Esql.suspicious_source_alert_count = SUM(CASE(Esql.is_suspicious_source_alert, 1, 0)), + observer.ip = MAX(CASE(Esql.is_exporter_alert, Esql.correlation_ip, null)), + source.ip = MAX(CASE(Esql.is_suspicious_source_alert, Esql.correlation_ip, null)), + Esql.exporter_alert_timestamp = MIN(Esql.exporter_alert_timestamp), + Esql.suspicious_source_alert_timestamp = MAX(Esql.suspicious_source_alert_timestamp), + Esql.suspicious_rule_name_values = VALUES(Esql.suspicious_rule_name), + Esql.suspicious_rule_id_values = VALUES(Esql.suspicious_rule_id) + BY data_stream.namespace, Esql.correlation_ip +| EVAL Esql.time_diff_seconds = DATE_DIFF( + "second", Esql.exporter_alert_timestamp, Esql.suspicious_source_alert_timestamp + ) +| WHERE Esql.exporter_alert_count > 0 + AND Esql.suspicious_source_alert_count > 0 + AND Esql.time_diff_seconds >= 0 + AND Esql.time_diff_seconds <= 1800 +| KEEP + data_stream.namespace, + observer.ip, + source.ip, + Esql.correlation_ip, + Esql.exporter_alert_count, + Esql.suspicious_source_alert_count, + Esql.exporter_alert_timestamp, + Esql.suspicious_source_alert_timestamp, + Esql.suspicious_rule_name_values, + Esql.suspicious_rule_id_values, + Esql.time_diff_seconds + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/rule-details/first-seen-network-flow-exporter.asciidoc b/docs/detections/prebuilt-rules/rule-details/first-seen-network-flow-exporter.asciidoc new file mode 100644 index 0000000000..49ce980880 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/first-seen-network-flow-exporter.asciidoc @@ -0,0 +1,130 @@ +[[first-seen-network-flow-exporter]] +=== First Seen Network Flow Exporter + +Identifies a NetFlow, IPFIX, or sFlow exporter IP that has not previously sent decoded flow records in the same data stream namespace during the prior 2 hours. This low-risk building-block signal records exporter novelty for correlation with later detection alerts in which the same address is the source of suspicious activity. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-125m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/netflow +* https://www.elastic.co/docs/reference/integrations/goflow2 +* https://datatracker.ietf.org/doc/html/rfc7011 +* https://sflow.org/sflow_version_5.txt + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Rule Type: BBR +* Data Source: NetFlow +* Data Source: GoFlow2 +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Seen Network Flow Exporter* + + +This building-block rule detects a newly observed exporter identity from decoded NetFlow, IPFIX, or sFlow records. In +these datasets, `observer.ip` identifies the exporter or sampler. The `source.ip` and `destination.ip` fields identify +endpoints in the exported flow and must not be treated as the exporter transport connection. + +This signal establishes novelty only. It does not prove that the exporter is unauthorized or that the exporter itself +performed the activity represented by the flow records. The signal is intended for correlation with later detection +alerts whose `source.ip` equals this alert's `observer.ip`. + + +*Possible investigation steps* + + +- Identify the device assigned to `observer.ip` and verify its owner, model, location, and change record. +- Confirm the expected collector, data stream namespace, export protocol, observation domain, and template behavior. +- Compare `netflow.exporter.source_id`, `netflow.exporter.version`, sequence values, interfaces, sampling rate, and flow + volume with established exporters. +- Check for template churn, malformed records, implausible addresses or byte counts, and conflicting telemetry from + independent sensors. + + +*False positive analysis* + + +- Validate recent network-device onboarding, collector migrations, disaster-recovery activation, NAT changes, and + integration re-onboarding. + + +*Response and remediation* + + +- If unauthorized, block the exporter at the collector boundary and preserve the received records for investigation. +- Review collector authentication, network ACLs, and exporter configuration to prevent further telemetry injection. + + +==== Setup + + + +*Setup* + + +This rule requires at least one decoded flow-export data source: + +- Elastic NetFlow integration (`netflow.log`) for NetFlow or IPFIX records. +- Elastic GoFlow2 integration (`goflow2.sflow`) for sFlow records processed by GoFlow2. + +Verify that `observer.ip` contains the exporter or sampler address. Do not broaden this rule to generic firewall or +`network_traffic.flow` events: in those records, `source.ip` and `destination.ip` describe the observed traffic and do +not reliably identify the device exporting telemetry. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-netflow.log-*, logs-goflow2.sflow-* +| WHERE observer.ip IS NOT NULL AND data_stream.namespace IS NOT NULL +| STATS + Esql.event_count = COUNT(*), + Esql.first_time_seen = MIN(@timestamp), + Esql.data_stream_dataset_values = VALUES(data_stream.dataset) + BY data_stream.namespace, observer.ip +| EVAL Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, NOW()) +| WHERE Esql.recent <= 6 +| KEEP + data_stream.namespace, + observer.ip, + Esql.event_count, + Esql.first_time_seen, + Esql.data_stream_dataset_values, + Esql.recent + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc index 84bc473097..a68a096350 100644 --- a/docs/detections/prebuilt-rules/rule-details/gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc @@ -26,14 +26,19 @@ Detects when the same GKE identity creates or modifies a Role or ClusterRole wit * Domain: Cloud * Domain: Kubernetes +* Domain: Containers * Data Source: GCP * Data Source: Google Cloud Platform +* Data Source: GCP Audit Logs +* Platform: GCP +* Platform: Kubernetes * Use Case: Threat Detection * Tactic: Privilege Escalation * Tactic: Persistence * Resources: Investigation Guide +* Rule Type: ESQL -*Version*: 1 +*Version*: 2 *Rule authors*: @@ -112,7 +117,12 @@ from logs-gcp.audit-* metadata _id, _index, _version and not client.user.email in ( "system:addon-manager", "system:apiserver", - "system:kube-controller-manager" + "system:kube-controller-manager", + "system:serviceaccount:flux-system:kustomize-controller", + "system:serviceaccount:flux-system:helm-controller", + "system:serviceaccount:flux-system:source-controller", + "system:serviceaccount:flux-system:flux-operator", + "system:serviceaccount:flux-operator:flux-operator" ) and ( ( diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc index 81ef23fc63..1d63542f6f 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc @@ -26,13 +26,17 @@ Detects a sequence where a principal creates or modifies a Role/ClusterRole to i *Tags*: * Data Source: Kubernetes +* Data Source: Kubernetes API Server Audit Logs +* Domain: Containers * Domain: Kubernetes +* Platform: Kubernetes * Use Case: Threat Detection * Tactic: Privilege Escalation * Tactic: Persistence * Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) -*Version*: 3 +*Version*: 4 *Rule authors*: @@ -93,7 +97,13 @@ sequence by user.name with maxspan=5m [any where data_stream.dataset == "kubernetes.audit_logs" and `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and kubernetes.audit.objectRef.resource in ("roles", "clusterroles") and - kubernetes.audit.verb in ("create", "update", "patch")] + kubernetes.audit.verb in ("create", "update", "patch") and + /* GitOps controllers reconcile RBAC then workloads in the same window */ + not user.name in ( + "system:serviceaccount:flux-system:kustomize-controller", + "system:serviceaccount:flux-system:helm-controller", + "system:serviceaccount:flux-system:source-controller" + )] [any where data_stream.dataset == "kubernetes.audit_logs" and `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and kubernetes.audit.objectRef.resource in ("daemonsets", "deployments", "cronjobs") and diff --git a/docs/detections/prebuilt-rules/rule-details/launch-service-creation-and-immediate-loading.asciidoc b/docs/detections/prebuilt-rules/rule-details/launch-service-creation-and-immediate-loading.asciidoc index 9fd0cece35..3c0ca8a428 100644 --- a/docs/detections/prebuilt-rules/rule-details/launch-service-creation-and-immediate-loading.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/launch-service-creation-and-immediate-loading.asciidoc @@ -33,7 +33,7 @@ An adversary can establish persistence by installing a new launch agent that exe * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 112 +*Version*: 113 *Rule authors*: @@ -134,7 +134,7 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ ---------------------------------- sequence by host.id with maxspan=30s [file where host.os.type == "macos" and event.action == "launch_daemon"] by process.entity_id - [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "launchctl" and process.args == "load"] by process.parent.entity_id + [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "launchctl" and process.args in ("load", "bootstrap")] by process.parent.entity_id ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/linux-firewall-rule-creation-or-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/linux-firewall-rule-creation-or-modification.asciidoc new file mode 100644 index 0000000000..2f8329dc56 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/linux-firewall-rule-creation-or-modification.asciidoc @@ -0,0 +1,191 @@ +[[linux-firewall-rule-creation-or-modification]] +=== Linux Firewall Rule Creation or Modification + +Adversaries may create or modify Linux firewall rules with DROP, ACCEPT, or REJECT actions to affect how a host receives or sends network traffic. This activity may be used to bypass security controls, block defensive tooling, or gain unauthorized access to the network. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* +* auditbeat-* + +*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 +* Platform: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) + +*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 Linux Firewall Rule Creation or Modification* + + +This rule detects Linux firewall commands that create or modify DROP, ACCEPT, REJECT, deny, allow, or reject rules, which can weaken network controls, conceal malicious traffic, or open unauthorized access paths. An attacker with elevated privileges may add an ACCEPT rule permitting inbound SSH from a controlled address, then add DROP or REJECT rules that block connections to monitoring or management systems. + + +*Possible investigation steps* + + +- Review the full command line, execution user, privilege level, parent process, working directory, and related shell history to determine who initiated the change and whether it followed an approved administrative workflow. +- Reconstruct the resulting firewall policy and identify affected interfaces, protocols, ports, addresses, directions, and rule ordering to assess whether access was opened or security and management traffic was blocked. +- Compare the change with configuration-management activity, maintenance windows, change tickets, administrator baselines, and similar commands on peer hosts to distinguish expected operations from anomalous behavior. +- Correlate nearby authentication, process, file, and network events for suspicious logins, privilege escalation, remote-access tooling, firewall persistence changes, or connections newly enabled by the rule. +- If unauthorized, preserve the active ruleset and relevant telemetry, restore the approved policy through controlled procedures, isolate the host when necessary, and investigate the initiating account and adjacent systems for compromise. + + +*False positive analysis* + + +- An administrator may add or modify DROP, ACCEPT, REJECT, deny, allow, or reject rules during approved firewall maintenance; verify the command scope, initiating user, execution time, and corresponding change record. +- A startup script or configuration-management process may restore the approved firewall baseline after boot or deployment; confirm the parent process, command recurrence, and resulting ruleset match established host and peer baselines. + + +*Response and remediation* + + +- Isolate affected hosts from untrusted networks while preserving approved incident-response access, and block attacker-controlled addresses and newly exposed services at upstream firewalls. +- Preserve the active ruleset and relevant logs, then remove unauthorized DROP, ACCEPT, REJECT, deny, allow, or reject rules and restore the approved policy through configuration management. +- Remove firewall persistence from systemd units, cron jobs, startup scripts, network hooks, nftables configuration, iptables-persistent files, and UFW configuration. +- Revoke compromised credentials and active sessions, inspect for additional malware or privilege escalation, and reimage from a known-good source if root-level integrity cannot be established. +- Escalate immediately to incident response if the rules were created with root privileges, enabled unauthorized remote access, impaired monitoring, or appear on multiple systems. +- Harden the environment by restricting firewall administration through least privilege, enforcing reviewed ruleset baselines, securing configuration files, and alerting on future policy changes. + + +==== 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]. + + +*Additional data sources* + + +This rule also supports ECS-compatible process events from Elastic Endgame and the following integrations: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://www.elastic.co/docs/reference/integrations/auditd_manager[Auditd Manager] +- https://www.elastic.co/guide/en/beats/auditbeat/current/auditbeat-installation-configuration.html[Auditbeat] + + +==== 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 in ( + "iptables", "ip6tables", "iptables-nft", "ip6tables-nft", "iptables-legacy", + "ip6tables-legacy", "xtables-nft-multi", "xtables-legacy-multi" + ) and + process.args in ("-A", "--append", "-I", "--insert", "-R", "--replace", "-P", "--policy") and + process.args like~ ("DROP", "ACCEPT", "REJECT") + ) or + ( + process.name == "nft" and + process.args in ("add", "insert", "replace") and + process.args == "rule" and + process.args like~ ("DROP", "ACCEPT", "REJECT") and + not process.args in ("-c", "--check") + ) or + ( + process.name == "ufw" and + process.args like~ ("deny", "allow", "reject") and + not process.args in ("delete", "--dry-run") + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify System Firewall +** ID: T1562.004 +** Reference URL: https://attack.mitre.org/techniques/T1562/004/ diff --git a/docs/detections/prebuilt-rules/rule-details/m365-identity-user-account-lockouts.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-identity-user-account-lockouts.asciidoc index 220ece7a18..ec6ae7ec62 100644 --- a/docs/detections/prebuilt-rules/rule-details/m365-identity-user-account-lockouts.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/m365-identity-user-account-lockouts.asciidoc @@ -36,7 +36,7 @@ Detects a burst of Microsoft 365 user account lockouts within a short 5-minute w * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 9 +*Version*: 10 *Rule authors*: @@ -107,7 +107,7 @@ from logs-o365.audit-* event.category == "authentication" and event.provider in ("AzureActiveDirectory", "Exchange") and event.action in ("UserLoginFailed", "PasswordLogonInitialAuthUsingPassword") and - to_lower(o365.audit.ExtendedProperties.RequestType) rlike "(oauth.*||.*login.*)" and + to_lower(o365.audit.ExtendedProperties.RequestType) rlike "(oauth.*|.*login.*)" and o365.audit.LogonError == "IdsLocked" and to_lower(o365.audit.UserId) != "not available" and o365.audit.Target.Type in ("0", "2", "6", "10") and diff --git a/docs/detections/prebuilt-rules/rule-details/m365-identity-user-brute-force-attempted.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-identity-user-brute-force-attempted.asciidoc index d8632a6120..bca43848c5 100644 --- a/docs/detections/prebuilt-rules/rule-details/m365-identity-user-brute-force-attempted.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/m365-identity-user-brute-force-attempted.asciidoc @@ -36,7 +36,7 @@ Identifies brute-force authentication activity targeting Microsoft 365 user acco * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 418 +*Version*: 419 *Rule authors*: @@ -110,7 +110,7 @@ from logs-o365.audit-* event.category == "authentication" and event.provider in ("AzureActiveDirectory", "Exchange") and event.action in ("UserLoginFailed", "PasswordLogonInitialAuthUsingPassword") and - Esql.o365_audit_ExtendedProperties_RequestType_lower rlike "(oauth.*||.*login.*)" and + Esql.o365_audit_ExtendedProperties_RequestType_lower rlike "(oauth.*|.*login.*)" and Esql.o365_audit_LogonError != "IdsLocked" and Esql.o365_audit_LogonError not in ( "EntitlementGrantsNotFound", diff --git a/docs/detections/prebuilt-rules/rule-details/m365-onedrive-sharepoint-excessive-file-downloads.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-onedrive-sharepoint-excessive-file-downloads.asciidoc index 18ade66e47..bc8faf7416 100644 --- a/docs/detections/prebuilt-rules/rule-details/m365-onedrive-sharepoint-excessive-file-downloads.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/m365-onedrive-sharepoint-excessive-file-downloads.asciidoc @@ -36,7 +36,7 @@ Identifies when an excessive number of files are downloaded from OneDrive or Sha * Tactic: Exfiltration * Resources: Investigation Guide -*Version*: 9 +*Version*: 10 *Rule authors*: @@ -120,12 +120,14 @@ from logs-o365.audit-* metadata _id, _version, _index | eval session.id = coalesce(o365.audit.AppAccessContext.AADSessionId, session.id, null) | where session.id is not null | eval Esql.time_window_date_trunc = date_trunc(3 minutes, @timestamp) +// file.size is dynamically mapped in o365.audit and can be keyword or long across backing indices +| eval Esql.file_size_bytes = to_long(file.size) | stats Esql.file_directory_values = values(file.directory), Esql.file_extension_values = values(file.extension), Esql.application_name_values = values(application.name), Esql.file_name_count_distinct = count_distinct(file.name), - Esql.total_file_size_mb = round((mv_sum(values(file.size))) / 1048576.0, 2), + Esql.total_file_size_mb = round((mv_sum(values(Esql.file_size_bytes))) / 1048576.0, 2), Esql.o365_audit_Site_values = values(o365.audit.Site), Esql.o365_audit_SiteUrl_values = values(o365.audit.SiteUrl), Esql.user_domain_values = values(user.domain), diff --git a/docs/detections/prebuilt-rules/rule-details/m365-teams-rogue-help-desk-chat-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-teams-rogue-help-desk-chat-created.asciidoc index a329c0fad7..af8f71113c 100644 --- a/docs/detections/prebuilt-rules/rule-details/m365-teams-rogue-help-desk-chat-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/m365-teams-rogue-help-desk-chat-created.asciidoc @@ -34,7 +34,7 @@ Identifies a one-on-one Microsoft Teams chat created by a user from a foreign te * Tactic: Initial Access * Resources: Investigation Guide -*Version*: 1 +*Version*: 2 *Rule authors*: @@ -113,7 +113,10 @@ data_stream.dataset:o365.audit and event.action:"ChatCreated" and event.provider *helpdesk* or *help.desk* or *help-desk* or *help_desk* or *ithelp* or *it.help* or *itsupport* or *it.support* or *it-support* ) or - user.name:(*helpdesk* or *help-desk* or *ithelp* or *itsupport*) + user.name:(*helpdesk* or *help-desk* or *ithelp* or *itsupport* or support or itassistant or ithelp or it or it_* or itadmin or it-*) or + + (o365.audit.Members: *.onmicrosoft.com and + o365.audit.Members: (*helpdesk* or *help* or *support* or *protection* or *monitoring* or *security* or *department* or *mandatory* or *network* or *systems*)) ) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-alerts-involving-a-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-alerts-involving-a-user.asciidoc index a644bd25b4..a9355ce05f 100644 --- a/docs/detections/prebuilt-rules/rule-details/multiple-alerts-involving-a-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/multiple-alerts-involving-a-user.asciidoc @@ -25,7 +25,7 @@ This rule uses alert data to determine when multiple different alerts involving * Rule Type: Higher-Order Rule * Resources: Investigation Guide -*Version*: 9 +*Version*: 10 *Rule authors*: @@ -107,7 +107,7 @@ from .alerts-security.* Esql.process_command_line_values = VALUES(process.command_line), Esql.host_id_values = VALUES(host.id), Esql.source_ip_values = VALUES(source.ip), - Esql.destination_ip_values = VALUES(destination.ip) by user.id + Esql.destination_ip_values = VALUES(destination.ip) by user.id, user.name | where Esql.kibana_alert_rule_name_distinct_count >= 4 AND Esql.kibana_alert_rule_rule_id_distinct_count >= 2 and // Exclude known system accounts with matches in more than one host @@ -116,6 +116,6 @@ from .alerts-security.* (Esql.host_id_distinct_count >= 2 or Esql.host_id_distinct_count == 0) ) -| keep user.id, Esql.* +| keep user.id, user.name, Esql.* ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/network-activity-to-a-suspicious-top-level-domain.asciidoc b/docs/detections/prebuilt-rules/rule-details/network-activity-to-a-suspicious-top-level-domain.asciidoc index 14e129c067..f531aa7a7c 100644 --- a/docs/detections/prebuilt-rules/rule-details/network-activity-to-a-suspicious-top-level-domain.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/network-activity-to-a-suspicious-top-level-domain.asciidoc @@ -41,7 +41,7 @@ Identifies DNS queries to commonly abused Top Level Domains by common LOLBINs or * Data Source: Crowdstrike * Data Source: Sysmon -*Version*: 4 +*Version*: 5 *Rule authors*: @@ -161,7 +161,9 @@ dns.question.name regex """.*\.(top|buzz|xyz|rest|ml|cf|gq|ga|onion|monster|cyou not process.executable : ( "?:\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\*.exe", - "\\Device\\HarddiskVolume*\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\*.exe" + "\\Device\\HarddiskVolume*\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\*.exe", + "?:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Platform\\Versions\\*\\*.exe", + "\\Device\\HarddiskVolume*\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Platform\\Versions\\*\\*.exe" ) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/newly-observed-ipsec-nat-traversal-peer.asciidoc b/docs/detections/prebuilt-rules/rule-details/newly-observed-ipsec-nat-traversal-peer.asciidoc index 48907d7b62..66a519b4ac 100644 --- a/docs/detections/prebuilt-rules/rule-details/newly-observed-ipsec-nat-traversal-peer.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/newly-observed-ipsec-nat-traversal-peer.asciidoc @@ -30,7 +30,7 @@ This rule identifies outbound IPSEC NAT Traversal (NAT-T) traffic to an external * Data Source: Zeek * Resources: Investigation Guide -*Version*: 113 +*Version*: 114 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/newly-seen-commonly-abused-network-scanner.asciidoc b/docs/detections/prebuilt-rules/rule-details/newly-seen-commonly-abused-network-scanner.asciidoc new file mode 100644 index 0000000000..fa241bbf21 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/newly-seen-commonly-abused-network-scanner.asciidoc @@ -0,0 +1,164 @@ +[[newly-seen-commonly-abused-network-scanner]] +=== Newly Seen Commonly Abused Network Scanner + +Identifies newly observed execution of SoftPerfect Network Scanner or Advanced IP/Port Scanner on a Windows host. Adversaries commonly use these legitimate scanners during post-compromise discovery to map live hosts, open ports, and reachable systems, then select targets for lateral movement. + +*Rule type*: new_terms + +*Rule indices*: + +* 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-* + +*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.cisa.gov/news-events/cybersecurity-advisories/aa23-319a +* https://thedfirreport.com/2025/06/30/hide-your-rdp-password-spray-leads-to-ransomhub-deployment/ +* https://thedfirreport.com/2020/11/23/pysa-mespinoza-ransomware/ +* https://www.microsoft.com/en-us/security/blog/2023/07/06/the-five-day-job-a-blackbyte-ransomware-intrusion-case-study/ +* https://www.cyfirma.com/news/weekly-intelligence-report-26-jan-2024/ +* https://github.com/Securityinbits/defender-hunt-queries/blob/main/discovery-tools.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Platform: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Rule Type: New Terms +* 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 + +*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 Newly Seen Commonly Abused Network Scanner* + + +This rule detects the first observed execution of commonly abused network-scanning tools on a Windows host, which can signal post-compromise discovery activity. After gaining a foothold, an attacker may run a portable scanner across the local subnet to identify live systems and exposed SMB or RDP services, then prioritize targets for lateral movement. + + +*Possible investigation steps* + + +- Validate the executable’s path, digital signature, hash reputation, download origin, command line, parent process, user account, and prevalence across the environment to distinguish authorized software from a renamed or portable copy. +- Correlate the execution with network telemetry to identify scanned address ranges, destination ports, connection volume, and whether sensitive systems or lateral-movement services such as SMB, RDP, WinRM, or SSH were targeted. +- Review nearby endpoint and identity activity for initial-access or post-compromise indicators, including suspicious downloads, archive extraction, PowerShell execution, credential access, remote logons, service creation, and scheduled tasks. +- Confirm with the host owner and IT teams whether the scanner and scope were approved, considering the user’s role, device purpose, execution time, and any related change or vulnerability-management activity. +- If unauthorized, isolate the host, preserve the binary and relevant telemetry, block confirmed malicious indicators, reset potentially exposed credentials, and investigate contacted systems for follow-on access. + + +*False positive analysis* + + +- An authorized administrator may run the scanner for network inventory or connectivity troubleshooting; verify the user’s role, executable path and signature, scanned range, and any associated change record. +- An approved security assessment or vulnerability-management activity may execute the scanner on a newly provisioned or infrequently used Windows host; confirm the timing, source host, target scope, and authorization with the responsible team. + + +*Response and remediation* + + +- Isolate the affected Windows host and restrict its access to scanned subnets and services such as SMB, RDP, WinRM, and SSH while preserving the scanner executable, command history, and relevant forensic evidence. +- Remove unauthorized scanner binaries and attacker persistence, including suspicious scheduled tasks, services, startup entries, PowerShell scripts, remote-management tools, and newly created accounts. +- Reset credentials used on the compromised host, revoke active sessions and tokens, and investigate contacted systems for remote logons, service creation, administrative shares, or other lateral-movement activity. +- Escalate immediately to incident response if scanning reached sensitive systems, privileged credentials may be exposed, or follow-on access appears on another host, and expand containment to all affected accounts and endpoints. +- Reimage or restore compromised systems from a verified known-good baseline, patch exploited weaknesses, and validate endpoint protection, logging, and business functionality before reconnecting them. +- Block malicious file hashes and download sources, apply application control to unapproved portable scanners, restrict unnecessary east-west connectivity, and alert on future scanner execution or high-volume port probing. + + + +==== 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/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- 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] +---------------------------------- +event.category:process and host.os.type:windows and event.type:start and +( + process.name.caseless:( + netscan*.exe or advanced_ip_scanner*.exe or + advanced_ip_scanner_console.exe or advanced_port_scanner.exe + ) or + process.pe.original_file_name : ( + "advanced_ip_scanner.exe" or + "advanced_port_scanner.exe" or + "advanced_ip_scanner_console.exe" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-update-orchestrator-service-hijack.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-update-orchestrator-service-hijack.asciidoc index 05f738a5b1..4962dfcbcb 100644 --- a/docs/detections/prebuilt-rules/rule-details/persistence-via-update-orchestrator-service-hijack.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-update-orchestrator-service-hijack.asciidoc @@ -11,7 +11,6 @@ Identifies potential hijacking of the Microsoft Update Orchestrator Service to e * logs-endpoint.events.process-* * logs-m365_defender.event-* * logs-sentinel_one_cloud_funnel.* -* logs-system.security* * logs-windows.forwarded* * logs-windows.sysmon_operational-* * winlogbeat-* @@ -42,10 +41,9 @@ Identifies potential hijacking of the Microsoft Update Orchestrator Service to e * Data Source: Elastic Defend * Data Source: Microsoft Defender XDR * Data Source: Sysmon -* Data Source: Windows Security Event Logs * Data Source: SentinelOne -*Version*: 319 +*Version*: 320 *Rule authors*: @@ -147,7 +145,6 @@ This rule also supports the following third-party data sources. For setup instru - https://ela.st/m365-defender[Microsoft Defender XDR] - https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] - https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] -- https://ela.st/audit-process-creation[Windows Process Creation Logs] ==== Rule query @@ -158,19 +155,16 @@ This rule also supports the following third-party data sources. For setup instru process where host.os.type == "windows" and event.type == "start" and process.parent.executable : "C:\\Windows\\System32\\svchost.exe" and process.parent.args : "UsoSvc" and - not process.executable : - ("?:\\ProgramData\\Microsoft\\Windows\\UUS\\Packages\\*\\amd64\\MoUsoCoreWorker.exe", + not process.executable : ( "?:\\Windows\\System32\\UsoClient.exe", "?:\\Windows\\System32\\MusNotification.exe", "?:\\Windows\\System32\\MusNotificationUx.exe", "?:\\Windows\\System32\\MusNotifyIcon.exe", "?:\\Windows\\System32\\WerFault.exe", "?:\\Windows\\System32\\WerMgr.exe", - "?:\\Windows\\UUS\\amd64\\MoUsoCoreWorker.exe", - "?:\\Windows\\System32\\MoUsoCoreWorker.exe", "?:\\Windows\\UUS\\amd64\\UsoCoreWorker.exe", - "?:\\Windows\\System32\\UsoCoreWorker.exe", - "?:\\Program Files\\Common Files\\microsoft shared\\ClickToRun\\OfficeC2RClient.exe") and + "?:\\Windows\\System32\\UsoCoreWorker.exe" + ) and not process.name : ("MoUsoCoreWorker.exe", "OfficeC2RClient.exe") ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-through-curl.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-through-curl.asciidoc index d498343be1..ea6a3c18d3 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-through-curl.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-through-curl.asciidoc @@ -48,7 +48,7 @@ Detects the use of curl to upload files to an internet server. Threat actors oft * Data Source: Auditd Manager * Data Source: Windows Security Event Logs -*Version*: 9 +*Version*: 10 *Rule authors*: @@ -168,32 +168,32 @@ not ( ) or process.args == "--unix-socket" or process.parent.name like "clevis*" or - process.parent.executable in ("/usr/bin/clevis-decrypt-tang", "/bin/clevis-decrypt-tang") or + ?process.parent.executable in ("/usr/bin/clevis-decrypt-tang", "/bin/clevis-decrypt-tang") or ( - process.parent.command_line like "*oracle/retina/vvaa-*" and + ?process.parent.command_line like "*oracle/retina/vvaa-*" and process.working_directory == "/home/oracle" ) or ( process.working_directory == "/home/oracle" and process.args == "--trace" and - process.parent.executable like "/home/oracle/retina/vvaa-*-oracle/app/*.sh" + ?process.parent.executable like "/home/oracle/retina/vvaa-*-oracle/app/*.sh" ) or ( process.working_directory == "/home/service/common/system.check" and - process.parent.command_line == "/bin/bash ./check.sh" + ?process.parent.command_line == "/bin/bash ./check.sh" ) or ( - process.parent.executable == "C:\\Windows\\SysWOW64\\cmd.exe" and - process.parent.args like "?:\\*\\temp-app\\caller_batch_*.bat" + ?process.parent.executable == "C:\\Windows\\SysWOW64\\cmd.exe" and + ?process.parent.args like "?:\\*\\temp-app\\caller_batch_*.bat" ) or ( - process.parent.executable == "/opt/rudder/share/commands/agent-run" and - process.parent.command_line == "/bin/sh /opt/rudder/share/commands/agent-run -uRN" and + ?process.parent.executable == "/opt/rudder/share/commands/agent-run" and + ?process.parent.command_line == "/bin/sh /opt/rudder/share/commands/agent-run -uRN" and process.args like "/var/rudder/reports/ready/*" ) or ( - process.parent.executable like "/var/lib/docker/overlay2/*/merged/usr/bin/bash" and - process.parent.command_line like "bash /home/*/old/scripts/crawler.sh start" + ?process.parent.executable like "/var/lib/docker/overlay2/*/merged/usr/bin/bash" and + ?process.parent.command_line like "bash /home/*/old/scripts/crawler.sh start" ) ) diff --git a/docs/detections/prebuilt-rules/rule-details/potential-entra-id-prt-extraction-via-browsercore.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-entra-id-prt-extraction-via-browsercore.asciidoc new file mode 100644 index 0000000000..95bc140656 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/potential-entra-id-prt-extraction-via-browsercore.asciidoc @@ -0,0 +1,171 @@ +[[potential-entra-id-prt-extraction-via-browsercore]] +=== Potential Entra ID PRT Extraction via BrowserCore + +Identifies anomalous execution of BrowserCore.exe, the Windows component used by Chromium-based browsers for native messaging with the Web Account Manager (WAM). Adversaries abuse BrowserCore to extract Entra ID Primary Refresh Tokens (PRTs) without interactive browser context, enabling session hijacking. Legitimate BrowserCore launches carry a chrome-extension:// argument from the browser native-messaging host. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.armadin.com/blog-posts/prtremote-extract-prt-cookies-remotely-with-interactivetoken-scheduled-task +* https://github.com/dmcxblue/ANIMO/blob/master/helpers/scripts/GrabTokenAzureAD/PrtExtractor.cs +* https://attack.mitre.org/techniques/T1528/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Platform: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Rule Type: ESQL +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Entra ID PRT Extraction via BrowserCore* + + +BrowserCore.exe is the Chromium native-messaging helper that brokers Web Account Manager (WAM) / Entra ID token +operations for Edge and Chrome. Tools such as PRTRemote and PrtExtractor invoke it outside the browser's +native-messaging context to obtain Primary Refresh Tokens (PRTs). + + +*Possible investigation steps* + + +- Is BrowserCore running from a non-canonical path or with a mismatched original filename? + - Focus: `process.executable`, `process.name`, `process.pe.original_file_name`, `process.hash.sha256`, and signer fields. + - Implication: escalate when the PE original name is BrowserCore.exe but the path is outside + `C:\Windows\BrowserCore\`, or when the binary is recently dropped/renamed. + +- Does the command line lack the browser native-messaging extension URI? + - Focus: `process.command_line`, `process.parent.name`, `process.parent.executable`, `process.parent.command_line`. + - Hint: legitimate launches include `chrome-extension://`. Abuse often omits that URI and may be launched by Task + Scheduler, scripts, or remote tools. + - Implication: escalate when `chrome-extension://` is absent and the parent is `svchost.exe` (task), `powershell.exe`, + `wscript.exe`, or another unexpected launcher. + +- Was there related token theft or Entra ID activity around the same time? + - Focus: related alerts for `user.id` / `host.id` covering credential access, unusual logons, or cloud session abuse. + - Implication: broaden scope when PRT extraction coincides with suspicious Azure/Entra sign-ins or cookie theft. + + +*False positive analysis* + + +- Legitimate browser SSO and account linking launch BrowserCore with a `chrome-extension://` argument and should not + match pivot 2. Rare custom helpers that invoke BrowserCore without that URI may need exceptions scoped to + `process.executable`, `process.parent.executable`, `user.id`, and `host.id`. + + +*Response and remediation* + + +- If confirmed malicious, isolate the host, terminate the anomalous BrowserCore tree, and assume the user's Entra ID + PRT/session may be compromised: revoke refresh tokens / sign the user out of all sessions and rotate credentials. +- Hunt for the same `process.command_line` pattern, scheduled tasks, or scripts that invoke BrowserCore across the estate. +- Remove persistence (scheduled tasks, scripts) that launched BrowserCore outside the browser native-messaging flow. + + +==== 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/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- 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-sentinel_one_cloud_funnel.*, logs-m365_defender.event-* metadata _id, _version, _index +| where KQL(""" event.category : "process" and event.type : "start" and host.os.type : "windows" """) and + to_lower(process.name) == "browsercore.exe" and process.parent.name is not null and process.command_line is not null and + not to_lower(process.command_line) like "*chrome-extension://*" +| keep + @timestamp, + _id, + _version, + _index, + data_stream.namespace, + host.id, + host.name, + user.name, + user.id, + process.entity_id, + process.name, + process.executable, + process.command_line, + process.pe.original_file_name, + process.parent.name, + process.parent.executable, + process.parent.command_line + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* 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/potential-etherhiding-c2-via-blockchain-connection.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-etherhiding-c2-via-blockchain-connection.asciidoc index 4e19dccea0..54b9c0e9c6 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-etherhiding-c2-via-blockchain-connection.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-etherhiding-c2-via-blockchain-connection.asciidoc @@ -34,7 +34,7 @@ Detects when a scripting interpreter makes an outbound network connection to an * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 2 +*Version*: 3 *Rule authors*: @@ -100,9 +100,13 @@ Etherhiding is an advanced command and control technique where threat actors sto ---------------------------------- sequence by process.entity_id with maxspan=15s [network where host.os.type == "macos" and event.type == "start" and - (process.name in ("bash", "sh", "zsh", "osascript", "node", "Cursor") or + (process.name in ("bash", "sh", "zsh", "osascript", "node", "Cursor", "Cursor Helper (Plugin)", "Windsurf", "Windsurf Helper (Plugin)") or process.name like ("python*", "ruby*", "perl*", "tclsh*")) and - destination.domain like ("eth-mainnet*", "ethereum*", "eth.*.com")] + destination.domain like ("eth-mainnet*", "ethereum*", "eth.*.com", + "*.drpc.org", "polygon-rpc.com", "polygon-mainnet*", "*.polygon.technology", + "bsc-dataseed*", "*.bnbchain.org", "arb1.arbitrum.io", "mainnet.base.org", + "rpc.ankr.com", "*.infura.io", "*.alchemy.com", "*.quiknode.pro", + "*.publicnode.com", "*.chainstack.com")] [file where host.os.type == "macos" and event.action == "modification" and file.extension in ("js", "py", "sh")] ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/potential-etherhiding-c2-via-curl-json-rpc-request.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-etherhiding-c2-via-curl-json-rpc-request.asciidoc new file mode 100644 index 0000000000..ddf4ed69bf --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/potential-etherhiding-c2-via-curl-json-rpc-request.asciidoc @@ -0,0 +1,147 @@ +[[potential-etherhiding-c2-via-curl-json-rpc-request]] +=== Potential EtherHiding C2 via Curl JSON-RPC Request + +Detects when curl or nscurl is spawned by a shell or osascript to make a JSON-RPC request to a blockchain endpoint for command and control purposes. Adversaries may leverage blockchain smart contracts as a covert C2 channel to retrieve commands or payload staging information, as observed in ClickFix campaigns. + +*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://notes.netbytesec.com/2026/08/anatomy-of-macos-clickfix-crimekit-that.html +* https://cloud.google.com/blog/topics/threat-intelligence/dprk-adopts-etherhiding +* https://cloud.google.com/blog/topics/threat-intelligence/unc5142-etherhiding-distribute-malware + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential EtherHiding C2 via Curl JSON-RPC Request* + + +EtherHiding is a command and control technique in which threat actors store malicious configuration, commands, +or payload URLs inside smart contract data on public blockchains. Because the blockchain is immutable and the +RPC endpoints are legitimate public infrastructure, this provides a takedown-resistant C2 channel. On macOS, +ClickFix-delivered loaders have been observed reading contract data by spawning curl from a shell or osascript +with a raw JSON-RPC eth_call request body. + + +*Possible investigation steps* + + +- Review process.command_line to identify the destination RPC endpoint, the contract address in the eth_call + parameters, and the method selector. +- Examine the parent process chain (process.parent.command_line, effective parent) to determine how the shell + or osascript was launched — interactive terminal, LaunchAgent, or another persistence mechanism. +- Search the same host for follow-on network connections shortly after this event; EtherHiding reads are + typically followed by a connection to the decoded C2 host. +- Check for recent LaunchAgent or LaunchDaemon plist creation on the host, which commonly accompanies this + activity as persistence. +- Search the contract address against threat intelligence sources to identify the associated campaign. +- Pivot fleet-wide on the destination RPC domain and any decoded C2 domains to identify additional hosts. + + +*False positive analysis* + + +- Web3 developers may test contract calls with curl against RPC endpoints. Verify whether the user has a + legitimate blockchain development role and whether the parent context (terminal session vs. persistence + item) matches interactive development work. +- CI or build scripts that query chain state via curl could match. Confirm with the owning team and consider + excluding specific parent scripts or hosts. + + +*Response and remediation* + + +- Isolate the affected host to interrupt the C2 channel. +- Terminate the parent shell or osascript process tree. +- Identify and remove any associated persistence (LaunchAgents/LaunchDaemons) and decoded payloads. +- Block decoded C2 domains identified from the contract data; note that blocking public RPC aggregators may + impact legitimate use and should be a risk-based decision. +- Rotate credentials accessible from the host and review for evidence of data theft. +- Escalate for full incident response if the activity chains from a ClickFix or social engineering delivery. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + process.name in ("curl", "nscurl") and + process.parent.name in ("osascript", "bash", "sh", "zsh") and + process.command_line like~ ("*eth_call*", "*\"jsonrpc\"*") + +---------------------------------- + +*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/ +* Sub-technique: +** Name: Dead Drop Resolver +** ID: T1102.001 +** Reference URL: https://attack.mitre.org/techniques/T1102/001/ +* Sub-technique: +** Name: Bidirectional Communication +** ID: T1102.002 +** Reference URL: https://attack.mitre.org/techniques/T1102/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: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/rule-details/potential-fileless-execution-via-o-tmpfile.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-fileless-execution-via-o-tmpfile.asciidoc new file mode 100644 index 0000000000..7391dfab81 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/potential-fileless-execution-via-o-tmpfile.asciidoc @@ -0,0 +1,162 @@ +[[potential-fileless-execution-via-o-tmpfile]] +=== Potential Fileless Execution via O_TMPFILE + +This rule identifies potential fileless ELF execution where a process is launched from an anonymous temporary executable path that appears as "/#" in "process.executable". This pattern may be associated with "O_TMPFILE" and "execveat" with "AT_EMPTY_PATH", which can allow execution without a normal filesystem pathname. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/MatheuZSecurity/Dntry +* https://matheuzsecurity.github.io/hacking/fileless-loader-bypassing-elastic-memfd/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Platform: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Rule Type: Event Correlation (EQL) +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* 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 Potential Fileless Execution via O_TMPFILE* + + +This rule detects Linux processes launched from anonymous temporary files created with O_TMPFILE, a pattern associated with execveat and AT_EMPTY_PATH execution that leaves no normal filesystem pathname. An attacker can write a malicious ELF payload into an unnamed file descriptor and execute it directly, reducing disk artifacts and making the payload harder to discover through routine file inspection. + + +*Possible investigation steps* + + +- Preserve volatile evidence from the live process by collecting its `/proc//exe`, file descriptors, memory maps, command line, environment, namespaces, and a hash or copy of the anonymous executable where policy permits. +- Reconstruct the full process ancestry and execution context, focusing on the initiating user, parent binary, container or service identity, privilege changes, and whether the chain originated from a shell, web service, or remote session. +- Correlate audit telemetry for the preceding `openat` or `openat2` call using `O_TMPFILE`, subsequent writes and permission changes, and the final `execveat` call using `AT_EMPTY_PATH`. +- Review nearby network, authentication, and endpoint activity for payload delivery, command-and-control connections, credential access, persistence creation, lateral movement, or additional spawned processes. +- Determine prevalence across hosts and compare hashes, ancestry, and execution context with approved software, escalating isolated or unsigned occurrences and containing affected systems when malicious behavior is confirmed. + + +*False positive analysis* + + +- Legitimate system or application software may use O_TMPFILE for secure temporary execution, so verify the process ancestry, executable hash, package ownership, and consistency with approved activity. +- Authorized software installation, update, or testing workflows may execute an anonymous ELF binary, so confirm the timing against approved changes and validate the initiating user, service, and expected recurrence across comparable hosts. + + +*Response and remediation* + + +- Isolate the affected Linux host or container from the network while preserving `/proc//exe`, open file descriptors, memory, and relevant audit logs for forensic analysis. +- Terminate the malicious process tree, revoke exposed credentials and active sessions, and block identified executable hashes, command-and-control destinations, and payload sources across the environment. +- Remove attacker persistence from systemd units, cron jobs, shell profiles, SSH `authorized_keys`, startup scripts, modified containers, and unauthorized accounts or packages. +- Escalate immediately to incident response if privileged execution, credential theft, command-and-control traffic, persistence, or activity on additional hosts is identified. +- Reimage compromised systems from known-good media, restore validated data, rotate affected secrets, patch the initial access vector, and verify that no anonymous executable or related attacker activity remains. +- Harden Linux endpoints by restricting unnecessary O_TMPFILE and `execveat` behavior through application allowlisting, SELinux or AppArmor policies, container controls, and enhanced auditing of anonymous-file execution. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.executable regex """.*/\#[0-9]+.*""" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ diff --git a/docs/detections/prebuilt-rules/rule-details/potential-linux-hack-tool-launched.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-linux-hack-tool-launched.asciidoc index 7e3a227da3..7e8f6fcc39 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-linux-hack-tool-launched.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-linux-hack-tool-launched.asciidoc @@ -39,7 +39,7 @@ Monitors for the execution of different processes that might be used by attacker * Data Source: SentinelOne * Resources: Investigation Guide -*Version*: 109 +*Version*: 110 *Rule authors*: @@ -68,7 +68,7 @@ Linux environments often utilize various tools for system administration and sec *Possible investigation steps* -- Review the process name that triggered the alert to determine if it matches any known hacking tools listed in the query, such as "crackmapexec" or "sqlmap". +- Review the process name and command-line arguments that triggered the alert to determine if they identify any known hacking tools listed in the query, such as "crackmapexec" or "sqlmap". - Check the user account associated with the process execution to assess if it is a legitimate user or potentially compromised. - Investigate the source and destination IP addresses involved in the process execution to identify any unusual or unauthorized network activity. - Examine the command line arguments used during the process execution to understand the intent and scope of the activity. @@ -142,22 +142,38 @@ 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 in~ ( - // exploitation frameworks - "crackmapexec", "msfconsole", "msfvenom", "sliver-client", "sliver-server", "havoc", - // network scanners (nmap left out to reduce noise) - "zenmap", "nuclei", "netdiscover", "legion", - // web enumeration - "gobuster", "dirbuster", "dirb", "wfuzz", "ffuf", "whatweb", "eyewitness", - // web vulnerability scanning - "wpscan", "joomscan", "droopescan", "nikto", - // exploitation tools - "sqlmap", "commix", "yersinia", - // cracking and brute forcing - "john", "hashcat", "hydra", "ncrack", "cewl", "fcrackzip", "rainbowcrack", - // host and network - "linenum.sh", "linpeas.sh", "pspy32", "pspy32s", "pspy64", "pspy64s", "binwalk", "evil-winrm", - "linux-exploit-suggester-2.pl", "linux-exploit-suggester.sh", "panix.sh" +( + process.name in~ ( + // exploitation frameworks + "crackmapexec", "msfconsole", "msfvenom", "sliver-client", "sliver-server", "havoc", + // network scanners (nmap left out to reduce noise) + "zenmap", "nuclei", "netdiscover", "legion", + // web enumeration + "gobuster", "dirbuster", "dirb", "wfuzz", "ffuf", "whatweb", "eyewitness", + // web vulnerability scanning + "wpscan", "joomscan", "droopescan", "nikto", + // exploitation tools + "sqlmap", "commix", "yersinia", + // cracking and brute forcing + "john", "hashcat", "hydra", "ncrack", "cewl", "fcrackzip", "rainbowcrack", + // host and network + "linenum.sh", "linpeas.sh", "pspy32", "pspy32s", "pspy64", "pspy64s", "binwalk", "evil-winrm", + "linux-exploit-suggester-2.pl", "linux-exploit-suggester.sh", "panix.sh" + ) or + ( + process.name : "python*" and + process.args : ("*sqlmap.py", "*crackmapexec", "*commix.py") + ) or + ( + process.name : "ruby*" and process.args : "*wpscan" + ) or + ( + process.name in~ ("bash", "dash", "sh", "zsh", "ksh", "fish", "busybox") and + process.args : ("*linenum.sh*", "*linpeas.sh*", "*linux-exploit-suggester.sh*", "*panix.sh*") + ) or + ( + process.name : "perl*" and process.args : "*linux-exploit-suggester-2.pl" + ) ) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/potential-network-scan-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-network-scan-detected.asciidoc index 2ad7fe2ca5..0a477ae046 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-network-scan-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-network-scan-detected.asciidoc @@ -28,7 +28,7 @@ This rule identifies a potential port scan from an internal IP address. A port s * Data Source: PAN-OS * Resources: Investigation Guide -*Version*: 15 +*Version*: 16 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-ssh-brute-force-detected-via-macos-security-events.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-ssh-brute-force-detected-via-macos-security-events.asciidoc new file mode 100644 index 0000000000..d9cbd47207 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/potential-ssh-brute-force-detected-via-macos-security-events.asciidoc @@ -0,0 +1,176 @@ +[[potential-ssh-brute-force-detected-via-macos-security-events]] +=== Potential SSH Brute Force Detected via macOS Security Events + +Identifies a high number of failed inbound SSH authentication attempts on a macOS host within a short time window, using sshd authentication messages collected by the macOS Security Events integration. Adversaries may perform password brute force or password spraying against exposed SSH services to obtain unauthorized access. + +*Rule type*: esql + +*Rule indices*: None + +*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://themittenmac.com/detecting-ssh-activity-via-process-monitoring/ + +*Tags*: + +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: macOS Security Events +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential SSH Brute Force Detected via macOS Security Events* + + +On macOS, the `sshd-session` process logs every failed authentication attempt to the unified log (`Failed password for`, `Failed keyboard-interactive/pam for`, +`PAM: authentication error for`), and connections that probe a non-existent username end with `Connection closed by invalid user`. +This rule counts these failure messages per host and alerts when the number reaches the threshold within the rule window. +Successful authentications are not counted. The rule extracts the targeted usernames and source IP addresses from the message text and reports them in the alert as `Esql.user_name_values` +and `Esql.source_ip_values`, with distinct counts in `Esql.user_name_count` and `Esql.source_ip_count`. + + +*Possible investigation steps* + + +- Review `Esql.event_count`, `Esql.user_name_values`, and `Esql.source_ip_values` in the alert to identify how many +attempts occurred and which accounts and sources were involved. +- Use `Esql.user_name_count` and `Esql.source_ip_count` to characterize the activity: many usernames from one source +indicates password spraying, one username from one source indicates password guessing, and one username from many +sources indicates a distributed attack. Check whether the targeted usernames exist on the host. +- Check whether any `Accepted` message from `sshd-session` follows the failures in `logs-macos.authentication-*`, which +would indicate the attack succeeded. +- Determine whether the source IP addresses are internal or external and whether they are associated with known +infrastructure, scanners, or previous alerts. +- Determine whether Remote Login is expected to be enabled on this host (for example, build servers or developer +workstations). +- Correlate with other alerts or events from the same host during the same period. + + +*Related rules* + + +- Potential Successful SSH Brute Force Attack via macOS Security Events - f5898b1e-3071-4597-b066-43d298c7b415 + + +*False positive analysis* + + +- Automation or configuration management tooling with stale or rotated credentials can generate bursts of failures, +typically from a single known source IP address against a single service account. +- Security scanners or credential-validation health checks that test SSH authentication against known hosts. +- Internet-facing SSH services may receive high volumes of scanning or credential-stuffing traffic from unrelated +sources; consider network-level rate limiting or exclusions for known source addresses. +- Users repeatedly mistyping a password rarely reach the threshold within the window due to PAM's per-attempt delay, +but multiple parallel sessions from the same user can approach it. + + +*Response and remediation* + + +- Block or rate-limit the source IP addresses reported in `Esql.source_ip_values` at the network perimeter or on the +host. +- Verify no successful authentication followed the failures; if one did, treat the host as potentially compromised and +follow the response steps of the successful brute force rule. +- Reset credentials for the accounts reported in `Esql.user_name_values` if there is any indication they may be weak or +exposed. +- Review the host's SSH configuration: prefer key-based authentication, restrict access with `AllowUsers`/`AllowGroups`, +and disable Remote Login where it is not required. +- Escalate to the security operations team if additional hosts show similar patterns. + + +==== Setup + + + +*Setup* + + +This rule requires data from the macOS Security Events integration. +Integration setup instructions: https://www.elastic.co/docs/reference/security/prebuilt-rules/integration/macos/macos_security_events[macOS Security Events] +SSH authentication logging setup instructions: https://www.elastic.co/docs/reference/security/prebuilt-rules/integration/macos/macos_security_events_ssh_authentication[macOS Security Events: SSH Authentication] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-macos.authentication-* +| WHERE data_stream.dataset == "macos.authentication" and ( + macos.event.message.description LIKE "Failed password for*" or + macos.event.message.description LIKE "Failed keyboard-interactive/pam for*" or + macos.event.message.description LIKE "error: PAM: authentication error for*" or + macos.event.message.description LIKE "Connection closed by invalid user*" + ) +| GROK macos.event.message.description "for (invalid user )?%{NOTSPACE:Esql.user_name_attempt} from %{IP:Esql.source_ip_attempt}" +| GROK macos.event.message.description "closed by invalid user %{NOTSPACE:Esql.user_name_probe} %{IP:Esql.source_ip_probe}" +| EVAL Esql.user_name = COALESCE(Esql.user_name_attempt, Esql.user_name_probe), + Esql.source_ip = COALESCE(Esql.source_ip_attempt, Esql.source_ip_probe) +| STATS + Esql.event_count = COUNT(*), + Esql.user_name_values = VALUES(Esql.user_name), + Esql.user_name_count = COUNT_DISTINCT(Esql.user_name), + Esql.source_ip_values = VALUES(Esql.source_ip), + Esql.source_ip_count = COUNT_DISTINCT(Esql.source_ip) + BY host.id, host.name +| WHERE Esql.event_count >= 20 +| KEEP host.id, host.name, Esql.event_count, Esql.user_name_values, Esql.user_name_count, Esql.source_ip_values, Esql.source_ip_count + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* 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/ diff --git a/docs/detections/prebuilt-rules/rule-details/potential-successful-ssh-brute-force-attack-via-macos-security-events.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-successful-ssh-brute-force-attack-via-macos-security-events.asciidoc new file mode 100644 index 0000000000..7ab80e5169 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/potential-successful-ssh-brute-force-attack-via-macos-security-events.asciidoc @@ -0,0 +1,177 @@ +[[potential-successful-ssh-brute-force-attack-via-macos-security-events]] +=== Potential Successful SSH Brute Force Attack via macOS Security Events + +Identifies a burst of failed inbound SSH authentication attempts on a macOS host followed shortly by a successful SSH authentication on the same host, using sshd authentication messages collected by the macOS Security Events integration. A successful login immediately after repeated failures indicates that a password brute force or password spraying attack against an exposed SSH service has likely succeeded. + +*Rule type*: eql + +*Rule indices*: + +* logs-macos.authentication-* + +*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://themittenmac.com/detecting-ssh-activity-via-process-monitoring/ + +*Tags*: + +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Initial Access +* Data Source: macOS Security Events +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Successful SSH Brute Force Attack via macOS Security Events* + + +SSH (Secure Shell) is a protocol used to securely access remote systems. On macOS, the `sshd-session` process logs each +failed authentication attempt (`Failed password for`, `Failed keyboard-interactive/pam for`, +`PAM: authentication error for`) and each successful one (`Accepted for from port `) to the +unified log. This rule alerts when ten or more failure messages on a host are followed within 15 seconds by an +`Accepted` message on the same host, indicating that a brute force or password spraying attack has likely succeeded. +The sequence is correlated per host; the source IP address and username are present in the message text and must be +read from the sequence events. + + +*Possible investigation steps* + + +- Review the `Accepted` event in the sequence and read its `macos.event.message.description.` field to identify the compromised username, the +source IP address and port, and the authentication method used. +- Compare the source IP address and usernames in the failure messages with the `Accepted` message to confirm the +success came from the same source and to determine whether one account or many were targeted. +- Determine whether the source IP address is internal or external and whether it is associated with known +infrastructure, scanners, or previous alerts. +- Verify whether the compromised account has administrative privileges or is a member of the `admin` group. +- Review process activity on the host after the successful login for discovery, persistence, or credential access +behavior, using Elastic Defend data if available. +- Review other alerts and events associated with the affected host and account during the past 48 hours. +- Determine whether Remote Login is expected to be enabled on this host and whether the account is expected to log in +over SSH. + + +*Related rules* + + +- Potential SSH Brute Force Detected via macOS Security Events - 3751cc17-6e7e-4356-86d5-c8f44aab9a28 + + +*False positive analysis* + + +- Automation or configuration management tooling that retries with stale credentials before succeeding with a valid one +can produce a burst of failures followed by a success. Verify the source and exclude known automation if expected. +- Because correlation is per host, an unrelated successful login within 15 seconds of a failure burst from another source +will match. Compare source IP addresses in the failure and `Accepted` messages to rule this out. +- A user with an expired or recently rotated password who retries repeatedly before succeeding. The 15-second window and +PAM's per-attempt delay make this unlikely from a single interactive session. +- Security scanners or credential-validation health checks that test SSH authentication against known hosts. + + +*Response and remediation* + + +- Treat the alert as a potential compromise: a successful login after repeated failures means the attacker likely holds +valid credentials for the host. +- Terminate active SSH sessions for the compromised account and isolate the host from the network if unauthorized +access is confirmed. +- Reset the password of the compromised account and any other accounts sharing the same credential; review the account +for unexpected privilege changes, SSH authorized keys, or persistence mechanisms such as launch agents or login items. +- Review commands executed in the session and on the host for follow-on activity, including data access, lateral +movement, or additional accounts created. +- Block or rate-limit the source IP address at the network perimeter or on the host, and review why the SSH service was +reachable from that source. +- Review and harden the host's SSH configuration: prefer key-based authentication, restrict access with +`AllowUsers`/`AllowGroups`, and disable Remote Login where it is not required. +- Search for similar sequences across other macOS hosts to determine whether the activity is part of a broader campaign. +- Escalate to the incident response team and update logging and detection coverage based on the findings. + + +==== Setup + + + +*Setup* + + +This rule requires data from the macOS Security Events integration. +Integration setup instructions: https://www.elastic.co/docs/reference/security/prebuilt-rules/integration/macos/macos_security_events[macOS Security Events] +SSH authentication logging setup instructions: https://www.elastic.co/docs/reference/security/prebuilt-rules/integration/macos/macos_security_events_ssh_authentication[macOS Security Events: SSH Authentication] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=15s + [authentication where event.dataset == "macos.authentication" and host.os.type == "macos" and + macos.event.message.description : ("Failed password for*", + "Failed keyboard-interactive/pam for*", + "error: PAM: authentication error for*")] with runs=10 + [authentication where event.dataset == "macos.authentication" and host.os.type == "macos" and + macos.event.message.description : "Accepted *"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* 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: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ diff --git a/docs/detections/prebuilt-rules/rule-details/potential-syn-based-port-scan-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-syn-based-port-scan-detected.asciidoc index b405b7c954..96aac9f24b 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-syn-based-port-scan-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-syn-based-port-scan-detected.asciidoc @@ -33,7 +33,7 @@ This rule identifies a potential SYN-Based port scan. A SYN port scan is a techn * Data Source: PAN-OS * Resources: Investigation Guide -*Version*: 14 +*Version*: 15 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/protected-storage-service-access-via-smb.asciidoc b/docs/detections/prebuilt-rules/rule-details/protected-storage-service-access-via-smb.asciidoc index a8706a4eb4..bfba34aaf2 100644 --- a/docs/detections/prebuilt-rules/rule-details/protected-storage-service-access-via-smb.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/protected-storage-service-access-via-smb.asciidoc @@ -3,7 +3,7 @@ Identifies remote access to the Windows Protected Storage Service through the IPC$ share. Attackers may abuse this named pipe to interact with the Protected Storage Service and extract sensitive credentials, certificates, or DPAPI backup keys. -*Rule type*: query +*Rule type*: new_terms *Rule indices*: @@ -38,7 +38,7 @@ Identifies remote access to the Windows Protected Storage Service through the IP * Data Source: Active Directory * Data Source: Windows Security Event Logs -*Version*: 1 +*Version*: 2 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/proxy-execution-via-console-window-host.asciidoc b/docs/detections/prebuilt-rules/rule-details/proxy-execution-via-console-window-host.asciidoc index 5aebc79022..2ba86cc1d4 100644 --- a/docs/detections/prebuilt-rules/rule-details/proxy-execution-via-console-window-host.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/proxy-execution-via-console-window-host.asciidoc @@ -46,7 +46,7 @@ Identifies abuse of the Console Window Host (conhost.exe) to execute commands vi * Data Source: Crowdstrike * Resources: Investigation Guide -*Version*: 4 +*Version*: 5 *Rule authors*: @@ -154,14 +154,14 @@ process where host.os.type == "windows" and event.type == "start" and ) and not ( /* Winget-AutoUpdate via ServiceUI */ - process.parent.executable : "?:\\Program Files\\winget-autoupdate*\\serviceui.exe" or + ?process.parent.executable : "?:\\Program Files\\winget-autoupdate*\\serviceui.exe" or /* Winget-AutoUpdate notification via Task Scheduler */ ( - process.parent.executable : "?:\\Windows\\System32\\svchost.exe" and process.parent.args : "-s" and - process.parent.args : "Schedule" and process.command_line : "*WAU-Notify.ps1*" + ?process.parent.executable : "?:\\Windows\\System32\\svchost.exe" and ?process.parent.args : "-s" and + ?process.parent.args : "Schedule" and process.command_line : "*WAU-Notify.ps1*" ) or /* Windows OpenSSH console host — SSH-specific detection handled by 8cd49fbc-a35a-4418-8688-133cc3a1e548 */ - process.parent.executable : ( + ?process.parent.executable : ( "?:\\Windows\\System32\\OpenSSH\\sshd.exe", "?:\\Windows\\System32\\OpenSSH\\sshd-session.exe", "?:\\Program Files\\OpenSSH*\\sshd.exe", diff --git a/docs/detections/prebuilt-rules/rule-details/remote-management-access-launch-after-msi-install.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-management-access-launch-after-msi-install.asciidoc index c464a75b79..036a6d44a2 100644 --- a/docs/detections/prebuilt-rules/rule-details/remote-management-access-launch-after-msi-install.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/remote-management-access-launch-after-msi-install.asciidoc @@ -45,7 +45,7 @@ Detects an MSI installer execution followed by the execution of commonly abused * Data Source: Windows Security Event Logs * Data Source: Elastic Endgame -*Version*: 4 +*Version*: 5 *Rule authors*: @@ -121,7 +121,7 @@ This rule also supports the following third-party data sources. For setup instru ---------------------------------- sequence by host.id with maxspan=1m [process where host.os.type == "windows" and event.type == "start" and process.name : "msiexec.exe" and - process.args : ("/i*", "-i*") and process.parent.name : ("explorer.exe", "sihost.exe")] + process.args : ("/i*", "-i*") and process.parent.name : ("explorer.exe", "sihost.exe", "powershell.exe", "cmd.exe")] [process where host.os.type == "windows" and event.type == "start" and ( (process.name : "ScreenConnect.ClientService.exe" and process.command_line : "*?e=Access&y=Guest&h*&k=*") or diff --git a/docs/detections/prebuilt-rules/rule-details/rpc-remote-procedure-call-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/rule-details/rpc-remote-procedure-call-to-the-internet.asciidoc index 2333eba485..adebcde3c7 100644 --- a/docs/detections/prebuilt-rules/rule-details/rpc-remote-procedure-call-to-the-internet.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/rpc-remote-procedure-call-to-the-internet.asciidoc @@ -42,7 +42,7 @@ This rule detects network events that may indicate the use of RPC traffic to the * Data Source: Zeek * Resources: Investigation Guide -*Version*: 112 +*Version*: 113 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/suricata-and-elastic-defend-network-correlation.asciidoc b/docs/detections/prebuilt-rules/rule-details/suricata-and-elastic-defend-network-correlation.asciidoc index 2e9525412f..867983ee3e 100644 --- a/docs/detections/prebuilt-rules/rule-details/suricata-and-elastic-defend-network-correlation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suricata-and-elastic-defend-network-correlation.asciidoc @@ -40,7 +40,7 @@ This detection correlates Suricata alerts with Elastic Defend network events to * Data Source: Suricata * Resources: Investigation Guide -*Version*: 4 +*Version*: 5 *Rule authors*: @@ -97,7 +97,6 @@ This detection correlates Suricata alerts with Elastic Defend network events to sequence by source.port, source.ip, destination.ip with maxspan=5s [network where data_stream.dataset == "suricata.eve" and event.kind == "alert" and event.severity != 3 and source.ip != null and destination.ip != null and - not source.domain : ("*nessusscan*", "SCCMPS*") and not rule.name in ("ET INFO SMB2 NT Create AndX Request For a Powershell .ps1 File", "ET SCAN MS Terminal Server Traffic on Non-standard Port")] [network where event.module == "endpoint" and event.action in ("disconnect_received", "connection_attempted") and not process.executable in ("System", "C:\\Program Files (x86)\\Admin Arsenal\\PDQ Inventory\\PDQInventoryService.exe") and diff --git a/docs/detections/prebuilt-rules/rule-details/system-v-init-script-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/system-v-init-script-created.asciidoc index 02cf81c701..89c1a3e38d 100644 --- a/docs/detections/prebuilt-rules/rule-details/system-v-init-script-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/system-v-init-script-created.asciidoc @@ -39,7 +39,7 @@ Files that are placed in the "/etc/init.d/" directory in Unix can be used to sta * Data Source: Elastic Defend * Data Source: SentinelOne -*Version*: 119 +*Version*: 120 *Rule authors*: @@ -76,7 +76,7 @@ This rule looks for the creation of new files within the `/etc/init.d/` director - !{osquery{"label":"Osquery - Retrieve File Information","query":"SELECT * FROM file WHERE path = {{file.path}}"}} - Investigate whether any other files in the `/etc/init.d/` or `/run/systemd/generator.late/` directories have been altered. - !{osquery{"label":"Osquery - Retrieve File Listing Information","query":"SELECT * FROM file WHERE path LIKE '/etc/init.d/%'"}} - - !{osquery{"label":"Osquery - Retrieve Additional File Listing Information","query":"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE path LIKE '/etc/init.d/%'\n"}} + - !{osquery{"label":"Osquery - Retrieve Additional File Listing Information","query":"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE path LIKE '/etc/init.d/%' OR path LIKE '/etc/init/%' OR path IN ('/etc/init', '/etc/inittab', '/etc/inittab2')\n\n"}} - Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} - Investigate syslog through the `sudo cat /var/log/syslog | grep 'LSB'` command to find traces of the LSB header of the script (if present). If syslog is being ingested into Elasticsearch, the same can be accomplished through Kibana. @@ -169,7 +169,8 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/ [source, js] ---------------------------------- file where host.os.type == "linux" and event.action in ("creation", "file_create_event", "rename", "file_rename_event") -and file.path like "/etc/init.d/*" and not ( +and file.path like ("/etc/init.d/*", "/etc/init/*", "/etc/init", "/etc/inittab*") and +not ( process.executable in ( "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-network-connection-to-suspicious-web-service.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-network-connection-to-suspicious-web-service.asciidoc index 33722a95a2..d025f13230 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-network-connection-to-suspicious-web-service.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-network-connection-to-suspicious-web-service.asciidoc @@ -32,7 +32,7 @@ This rule monitors for the unusual occurrence of outbound network connections to * Data Source: Elastic Defend * Resources: Investigation Guide -*Version*: 6 +*Version*: 7 *Rule authors*: @@ -198,7 +198,7 @@ destination.domain : ( *.blob.storage.azure.net ) and not (destination.domain : (*.sharepoint.com or *.azurewebsites.net or "onedrive.live.com" or *.b-cdn.net or api.onedrive.com or "drive.google.com" or *.blogspot.com or *.blob.core.windows.net or *.blob.storage.azure.net) and process.code_signature.subject_name:(*Microsoft* or "Software Signing" or "Apple Mac OS Application Signing" or *VMware*) and process.code_signature.trusted:true) and -not (process.code_signature.subject_name:(*Mozilla* or *Google* or *Brave* or *Opera* or "Software Signing" or *Zscaler* or *Browser*) and process.code_signature.trusted:true) and +not (process.code_signature.subject_name:(*Mozilla* or *Google* or *Brave* or *Opera* or "Software Signing" or "macOS Software Signing" or *Zscaler* or *Browser*) and process.code_signature.trusted:true) and not (destination.domain :("discord.com" or cdn.discordapp.com or "content.dropboxapi.com" or "dl.dropboxusercontent.com") and process.code_signature.subject_name :(*Discord* or *Dropbox*) and process.code_signature.trusted:true) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/web-server-cloud-metadata-ssrf-request.asciidoc b/docs/detections/prebuilt-rules/rule-details/web-server-cloud-metadata-ssrf-request.asciidoc index 8726e506f0..63068a0205 100644 --- a/docs/detections/prebuilt-rules/rule-details/web-server-cloud-metadata-ssrf-request.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/web-server-cloud-metadata-ssrf-request.asciidoc @@ -45,7 +45,7 @@ Detects HTTP requests to web servers whose URL or query string references cloud * Data Source: Zeek * Resources: Investigation Guide -*Version*: 1 +*Version*: 2 *Rule authors*: @@ -131,6 +131,10 @@ web where ( "*meta-data/iam/security-credentials*", "*meta-data%2Fiam%2Fsecurity-credentials*", "*latest/meta-data*", "*latest/api/token*" ) +) and source.as.number != 396982 +and not ( + user_agent.original : ("*ChatGPT-User*", "*GPTBot*", "*ClaudeBot*", "*anthropic-ai*", "*OAI-SearchBot*", "*perplexity.ai*", "*claude-searchbot*", "*anthropic.com*", "*google.com/bot.html*", "*TelegramBot*", "*openai.com/searchbot*", "*LinkedInBot*", "*x.ai/grokbot*", "*Discordbot*", "*Amazonbot*", "*amazonbot*", "*Applebot*", "*Slackbot*", "*Twitterbot*", "*Bytespider*") + and http.response.status_code in (401, 403, 404, 429) ) ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/whoami-process-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/whoami-process-activity.asciidoc index d8246b3200..951c705c0b 100644 --- a/docs/detections/prebuilt-rules/rule-details/whoami-process-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/whoami-process-activity.asciidoc @@ -40,7 +40,7 @@ Identifies suspicious use of whoami.exe which displays user, group, and privileg * Data Source: Sysmon * Data Source: Windows Security Event Logs -*Version*: 219 +*Version*: 220 *Rule authors*: @@ -141,14 +141,14 @@ process where host.os.type == "windows" and event.type == "start" and process.na ) and not ( process.parent.name : "cmd.exe" and - process.parent.args : ( + ?process.parent.args : ( "chcp 437>nul 2>&1 & C:\\WINDOWS\\System32\\whoami.exe /groups", "chcp 437>nul 2>&1 & %systemroot%\\system32\\whoami /user", "C:\\WINDOWS\\System32\\whoami.exe /groups", "*WINDOWS\\system32\\config\\systemprofile*" ) ) and - not (process.parent.executable : "C:\\Windows\\system32\\inetsrv\\appcmd.exe" and process.parent.args : "LIST") and + not (process.parent.executable : "C:\\Windows\\system32\\inetsrv\\appcmd.exe" and ?process.parent.args : "LIST") and not process.parent.executable : ( "C:\\Program Files\\Microsoft Monitoring Agent\\Agent\\MonitoringHost.exe", "C:\\Program Files\\Cohesity\\cohesity_windows_agent_service.exe" diff --git a/docs/index.asciidoc b/docs/index.asciidoc index d40b0a4ff4..a4ce95c042 100644 --- a/docs/index.asciidoc +++ b/docs/index.asciidoc @@ -147,3 +147,5 @@ include::detections/prebuilt-rules/downloadable-packages/8-19-30/prebuilt-rules- include::detections/prebuilt-rules/downloadable-packages/8-19-31/prebuilt-rules-8-19-31-appendix.asciidoc[] include::detections/prebuilt-rules/downloadable-packages/8-19-32/prebuilt-rules-8-19-32-appendix.asciidoc[] + +include::detections/prebuilt-rules/downloadable-packages/8-19-33/prebuilt-rules-8-19-33-appendix.asciidoc[]