From 79aa096ba393e9eb786195e954ca5143a7f8d818 Mon Sep 17 00:00:00 2001 From: tradebot-elastic <178941316+tradebot-elastic@users.noreply.github.com> Date: Tue, 4 Aug 2026 13:52:50 +0000 Subject: [PATCH 1/2] Update latest docs --- ...-different-att-ck-tactics-by-host.asciidoc | 143 +++++++ ...iner-override-by-unusual-identity.asciidoc | 112 +++++ ...ingle-model-inference-api-probing.asciidoc | 148 +++++++ ...stem-or-execution-tool-invocation.asciidoc | 138 ++++++ ...owing-all-traffic-by-new-identity.asciidoc | 119 ++++++ ...olicy-deleted-by-unusual-identity.asciidoc | 122 ++++++ ...ated-access-key-subsequently-used.asciidoc | 222 ++++++++++ ...low-public-access-by-new-identity.asciidoc | 113 +++++ ...-role-passed-by-unusual-principal.asciidoc | 148 +++++++ ...gning-request-created-or-approved.asciidoc | 156 +++++++ ...r-kube-dns-configuration-modified.asciidoc | 144 +++++++ ...-ephemeral-container-added-to-pod.asciidoc | 140 ++++++ ...ure-aks-kubernetes-events-deleted.asciidoc | 138 ++++++ ...potential-api-enumeration-by-user.asciidoc | 142 ++++++ ...r-list-with-suspicious-user-agent.asciidoc | 153 +++++++ ...-service-account-or-node-identity.asciidoc | 144 +++++++ ...cassandra-javascript-udf-creation.asciidoc | 123 ++++++ ...-component-object-model-hijacking.asciidoc | 255 +++++++++++ ...n-to-commonly-abused-web-services.asciidoc | 404 ++++++++++++++++++ ...alerts-on-similar-user-identities.asciidoc | 163 +++++++ ...-execution-via-background-utility.asciidoc | 173 ++++++++ ...nd-rules-creation-or-modification.asciidoc | 165 +++++++ ...-19-29-entra-id-high-risk-sign-in.asciidoc | 127 ++++++ ...-user-sign-in-with-unusual-client.asciidoc | 231 ++++++++++ ...nal-ip-address-discovery-via-curl.asciidoc | 118 +++++ ...-mongodb-command-from-a-client-ip.asciidoc | 131 ++++++ ...-first-time-seen-memcached-writer.asciidoc | 134 ++++++ ...seen-nfs-auth-sys-root-uid-access.asciidoc | 119 ++++++ ...e-endpoint-permission-enumeration.asciidoc | 137 ++++++ ...9-29-gke-multi-resource-discovery.asciidoc | 201 +++++++++ ...om-node-or-denied-service-account.asciidoc | 130 ++++++ ...ret-access-via-unusual-user-agent.asciidoc | 117 +++++ ...followed-by-workload-modification.asciidoc | 200 +++++++++ ...-secret-access-via-new-user-agent.asciidoc | 115 +++++ ...-29-local-scheduled-task-creation.asciidoc | 173 ++++++++ ...entity-login-from-atypical-region.asciidoc | 142 ++++++ ...web-removal-by-an-unusual-process.asciidoc | 151 +++++++ ...ilt-rule-8-19-29-mofcomp-activity.asciidoc | 165 +++++++ ...ures-followed-by-successful-login.asciidoc | 196 +++++++++ ...l-user-defined-function-injection.asciidoc | 120 ++++++ ...affic-to-rare-destination-country.asciidoc | 214 ++++++++++ ...stence-via-scheduled-job-creation.asciidoc | 159 +++++++ ...ion-in-wordpress-plugin-directory.asciidoc | 171 ++++++++ ...ql-copy-program-command-execution.asciidoc | 121 ++++++ ...puter-account-ntlm-relay-activity.asciidoc | 151 +++++++ ...tial-credential-access-via-dcsync.asciidoc | 158 +++++++ ...tial-access-via-windows-utilities.asciidoc | 216 ++++++++++ ...al-data-exfiltration-through-curl.asciidoc | 219 ++++++++++ ...r-freeze-via-werfaultsecure-abuse.asciidoc | 155 +++++++ ...teral-tool-transfer-via-smb-share.asciidoc | 150 +++++++ ...ntial-ssh-reverse-port-forwarding.asciidoc | 187 ++++++++ ...otential-tunneling-via-tailscaled.asciidoc | 132 ++++++ ...-8-19-29-spike-in-firewall-denies.asciidoc | 205 +++++++++ ...e-in-network-traffic-to-a-country.asciidoc | 196 +++++++++ ...-8-19-29-spike-in-network-traffic.asciidoc | 185 ++++++++ ...ing-activity-with-high-confidence.asciidoc | 151 +++++++ ...el-detected-c2-beaconing-activity.asciidoc | 156 +++++++ ...sful-amqp-multi-queue-purge-burst.asciidoc | 134 ++++++ ...cious-curl-from-macos-application.asciidoc | 143 +++++++ ...n-via-windows-subsystem-for-linux.asciidoc | 233 ++++++++++ ...-suspicious-execution-with-nodejs.asciidoc | 194 +++++++++ ...process-communication-via-outlook.asciidoc | 158 +++++++ ...rvice-was-installed-in-the-system.asciidoc | 202 +++++++++ ...ous-uid-change-to-root-via-python.asciidoc | 125 ++++++ ...ious-windows-powershell-arguments.asciidoc | 282 ++++++++++++ ...public-ip-discovery-via-dns-query.asciidoc | 235 ++++++++++ ...pc-method-from-an-external-client.asciidoc | 147 +++++++ ...base64-encoding-decoding-activity.asciidoc | 248 +++++++++++ ...sual-file-creation-via-web-server.asciidoc | 171 ++++++++ .../prebuilt-rules-8-19-29-appendix.asciidoc | 77 ++++ .../prebuilt-rules-8-19-29-summary.asciidoc | 154 +++++++ ...ebuilt-rules-downloadable-updates.asciidoc | 5 + .../prebuilt-rules-reference.asciidoc | 144 +++++-- .../prebuilt-rules/rule-desc-index.asciidoc | 38 +- ...-different-att-ck-tactics-by-host.asciidoc | 43 +- ...iner-override-by-unusual-identity.asciidoc | 112 +++++ ...ingle-model-inference-api-probing.asciidoc | 125 ++---- ...stem-or-execution-tool-invocation.asciidoc | 138 ++++++ ...owing-all-traffic-by-new-identity.asciidoc | 119 ++++++ ...olicy-deleted-by-unusual-identity.asciidoc | 122 ++++++ ...ated-access-key-subsequently-used.asciidoc | 222 ++++++++++ ...low-public-access-by-new-identity.asciidoc | 113 +++++ ...-role-passed-by-unusual-principal.asciidoc | 148 +++++++ ...gning-request-created-or-approved.asciidoc | 156 +++++++ ...r-kube-dns-configuration-modified.asciidoc | 144 +++++++ ...-ephemeral-container-added-to-pod.asciidoc | 140 ++++++ ...ure-aks-kubernetes-events-deleted.asciidoc | 138 ++++++ ...potential-api-enumeration-by-user.asciidoc | 142 ++++++ ...r-list-with-suspicious-user-agent.asciidoc | 153 +++++++ ...oken-created-via-tokenrequest-api.asciidoc | 140 ++++++ ...-service-account-or-node-identity.asciidoc | 144 +++++++ ...cassandra-javascript-udf-creation.asciidoc | 123 ++++++ .../component-object-model-hijacking.asciidoc | 30 +- ...n-to-commonly-abused-web-services.asciidoc | 21 +- ...alerts-on-similar-user-identities.asciidoc | 3 +- ...-execution-via-background-utility.asciidoc | 173 ++++++++ ...nd-rules-creation-or-modification.asciidoc | 5 +- .../entra-id-high-risk-sign-in.asciidoc | 9 +- ...-user-sign-in-with-unusual-client.asciidoc | 61 ++- ...nal-ip-address-discovery-via-curl.asciidoc | 5 +- ...-mongodb-command-from-a-client-ip.asciidoc | 131 ++++++ .../first-time-seen-memcached-writer.asciidoc | 134 ++++++ ...seen-nfs-auth-sys-root-uid-access.asciidoc | 119 ++++++ ...e-endpoint-permission-enumeration.asciidoc | 137 ++++++ .../gke-multi-resource-discovery.asciidoc | 201 +++++++++ ...om-node-or-denied-service-account.asciidoc | 130 ++++++ ...ret-access-via-unusual-user-agent.asciidoc | 117 +++++ ...followed-by-workload-modification.asciidoc | 200 +++++++++ ...-secret-access-via-new-user-agent.asciidoc | 115 +++++ .../local-scheduled-task-creation.asciidoc | 23 +- ...entity-login-from-atypical-region.asciidoc | 32 +- ...web-removal-by-an-unusual-process.asciidoc | 151 +++++++ .../rule-details/mofcomp-activity.asciidoc | 24 +- ...ures-followed-by-successful-login.asciidoc | 196 +++++++++ ...l-user-defined-function-injection.asciidoc | 120 ++++++ ...affic-to-rare-destination-country.asciidoc | 4 +- ...stence-via-scheduled-job-creation.asciidoc | 16 +- ...ion-in-wordpress-plugin-directory.asciidoc | 48 ++- ...ql-copy-program-command-execution.asciidoc | 121 ++++++ ...puter-account-ntlm-relay-activity.asciidoc | 7 +- ...tial-credential-access-via-dcsync.asciidoc | 5 +- ...tial-access-via-windows-utilities.asciidoc | 7 +- ...al-data-exfiltration-through-curl.asciidoc | 11 +- ...r-freeze-via-werfaultsecure-abuse.asciidoc | 155 +++++++ ...teral-tool-transfer-via-smb-share.asciidoc | 8 +- ...ntial-ssh-reverse-port-forwarding.asciidoc | 8 +- ...otential-tunneling-via-tailscaled.asciidoc | 132 ++++++ .../spike-in-firewall-denies.asciidoc | 4 +- ...e-in-network-traffic-to-a-country.asciidoc | 4 +- .../spike-in-network-traffic.asciidoc | 4 +- ...ing-activity-with-high-confidence.asciidoc | 8 +- ...el-detected-c2-beaconing-activity.asciidoc | 8 +- ...sful-amqp-multi-queue-purge-burst.asciidoc | 134 ++++++ ...cious-curl-from-macos-application.asciidoc | 4 +- ...n-via-windows-subsystem-for-linux.asciidoc | 59 ++- .../suspicious-execution-with-nodejs.asciidoc | 17 +- ...process-communication-via-outlook.asciidoc | 7 +- ...rvice-was-installed-in-the-system.asciidoc | 145 ++++--- ...ous-uid-change-to-root-via-python.asciidoc | 125 ++++++ ...ious-windows-powershell-arguments.asciidoc | 12 +- ...public-ip-discovery-via-dns-query.asciidoc | 4 +- ...pc-method-from-an-external-client.asciidoc | 147 +++++++ ...base64-encoding-decoding-activity.asciidoc | 4 +- ...sual-file-creation-via-web-server.asciidoc | 171 ++++++++ ...taller-with-suspicious-properties.asciidoc | 4 +- docs/index.asciidoc | 2 + 146 files changed, 17542 insertions(+), 290 deletions(-) create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-alerts-in-different-att-ck-tactics-by-host.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-batch-job-submitted-with-container-override-by-unusual-identity.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-bedrock-high-risk-filesystem-or-execution-tool-invocation.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-ec2-nacl-entry-created-or-replaced-allowing-all-traffic-by-new-identity.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-iam-permission-boundary-or-guardrail-policy-deleted-by-unusual-identity.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-iam-user-self-created-access-key-subsequently-used.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-s3-bucket-acl-modified-to-allow-public-access-by-new-identity.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-sagemaker-execution-role-passed-by-unusual-principal.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-certificate-signing-request-created-or-approved.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-coredns-or-kube-dns-configuration-modified.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-ephemeral-container-added-to-pod.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-kubernetes-events-deleted.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-potential-api-enumeration-by-user.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-secret-get-or-list-with-suspicious-user-agent.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-suspicious-self-subject-review-by-service-account-or-node-identity.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-cassandra-javascript-udf-creation.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-component-object-model-hijacking.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-connection-to-commonly-abused-web-services.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-correlated-alerts-on-similar-user-identities.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-direct-process-execution-via-background-utility.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-emond-rules-creation-or-modification.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-entra-id-high-risk-sign-in.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-entra-id-user-sign-in-with-unusual-client.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-external-ip-address-discovery-via-curl.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-first-time-destructive-mongodb-command-from-a-client-ip.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-first-time-seen-memcached-writer.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-first-time-seen-nfs-auth-sys-root-uid-access.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-endpoint-permission-enumeration.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-multi-resource-discovery.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-secret-access-from-node-or-denied-service-account.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-secret-access-via-unusual-user-agent.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-unusual-service-account-secret-access-via-new-user-agent.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-local-scheduled-task-creation.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-m365-identity-login-from-atypical-region.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-mark-of-the-web-removal-by-an-unusual-process.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-mofcomp-activity.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-multiple-sonicwall-login-failures-followed-by-successful-login.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-mysql-user-defined-function-injection.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-network-traffic-to-rare-destination-country.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-persistence-via-scheduled-job-creation.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-php-file-creation-in-wordpress-plugin-directory.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-postgresql-copy-program-command-execution.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-computer-account-ntlm-relay-activity.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-credential-access-via-dcsync.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-credential-access-via-windows-utilities.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-data-exfiltration-through-curl.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-edr-freeze-via-werfaultsecure-abuse.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-lateral-tool-transfer-via-smb-share.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-ssh-reverse-port-forwarding.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-tunneling-via-tailscaled.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-spike-in-firewall-denies.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-spike-in-network-traffic-to-a-country.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-spike-in-network-traffic.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-statistical-model-detected-c2-beaconing-activity-with-high-confidence.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-statistical-model-detected-c2-beaconing-activity.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-successful-amqp-multi-queue-purge-burst.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-curl-from-macos-application.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-execution-via-windows-subsystem-for-linux.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-execution-with-nodejs.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-inter-process-communication-via-outlook.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-service-was-installed-in-the-system.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-uid-change-to-root-via-python.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-windows-powershell-arguments.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-system-public-ip-discovery-via-dns-query.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-thrift-rpc-method-from-an-external-client.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-unusual-base64-encoding-decoding-activity.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-unusual-file-creation-via-web-server.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rules-8-19-29-appendix.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rules-8-19-29-summary.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-batch-job-submitted-with-container-override-by-unusual-identity.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-bedrock-high-risk-filesystem-or-execution-tool-invocation.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-ec2-nacl-entry-created-or-replaced-allowing-all-traffic-by-new-identity.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-iam-permission-boundary-or-guardrail-policy-deleted-by-unusual-identity.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-iam-user-self-created-access-key-subsequently-used.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-acl-modified-to-allow-public-access-by-new-identity.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-sagemaker-execution-role-passed-by-unusual-principal.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/azure-aks-certificate-signing-request-created-or-approved.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/azure-aks-coredns-or-kube-dns-configuration-modified.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/azure-aks-ephemeral-container-added-to-pod.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/azure-aks-kubernetes-events-deleted.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/azure-aks-potential-api-enumeration-by-user.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/azure-aks-secret-get-or-list-with-suspicious-user-agent.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/azure-aks-service-account-token-created-via-tokenrequest-api.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/azure-aks-suspicious-self-subject-review-by-service-account-or-node-identity.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/cassandra-javascript-udf-creation.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/direct-process-execution-via-background-utility.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/first-time-destructive-mongodb-command-from-a-client-ip.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/first-time-seen-memcached-writer.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/first-time-seen-nfs-auth-sys-root-uid-access.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/gke-endpoint-permission-enumeration.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/gke-multi-resource-discovery.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/gke-secret-access-from-node-or-denied-service-account.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/gke-secret-access-via-unusual-user-agent.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/gke-unusual-service-account-secret-access-via-new-user-agent.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/mark-of-the-web-removal-by-an-unusual-process.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/multiple-sonicwall-login-failures-followed-by-successful-login.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/mysql-user-defined-function-injection.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/postgresql-copy-program-command-execution.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-edr-freeze-via-werfaultsecure-abuse.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-tunneling-via-tailscaled.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/successful-amqp-multi-queue-purge-burst.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/suspicious-uid-change-to-root-via-python.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/thrift-rpc-method-from-an-external-client.asciidoc create mode 100644 docs/detections/prebuilt-rules/rule-details/unusual-file-creation-via-web-server.asciidoc diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-alerts-in-different-att-ck-tactics-by-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-alerts-in-different-att-ck-tactics-by-host.asciidoc new file mode 100644 index 0000000000..3c11ef7c55 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-alerts-in-different-att-ck-tactics-by-host.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-29-alerts-in-different-att-ck-tactics-by-host]] +=== Alerts in Different ATT&CK Tactics by Host + +This rule correlates medium-or-higher severity alerts involving the same host from at least two distinct detection rules mapped to three or more ATT&CK tactics. Analysts can use this to prioritize triage and response, as this combination may indicate host compromise. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-8h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* 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 Alerts in Different ATT&CK Tactics by Host* + + +The rule identifies hosts with alerts across multiple ATT&CK tactics, which may indicate compromise. It helps analysts focus on high-risk hosts by correlating diverse alerts. The resulting alert is grouped, so the `Esql.*_values` fields summarize contributing alerts without preserving event order or relationships between values. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* metadata _id + +// filter for medium-or-higher severity alerts, excluding threat_match, machine_learning, and deprecated rules. +| where kibana.alert.risk_score > 21 and + kibana.alert.rule.name IS NOT NULL and kibana.alert.rule.rule_id IS NOT NULL and + host.id is not null and event.dataset is not null and + kibana.alert.rule.type not in ("threat_match", "machine_learning") and + // Exclude a deprecated rule whose alert name does not carry the standard prefix + kibana.alert.rule.name != "Potential PrintNightmare File Modification" and + not kibana.alert.rule.name like "Deprecated - *" and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) + +// extract unique counts and values by host.id +| stats Esql.alerts_count = COUNT(*), + Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.kibana_alert_rule_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.rule_id), + Esql.event_module_values = VALUES(event.module), + Esql.host_name_values = VALUES(host.name), + Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name), + Esql.kibana_alert_rule_id_values = VALUES(kibana.alert.rule.rule_id), + Esql.threat_tactic_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.threat.tactic.id), + Esql.threat_tactic_name_values = VALUES(kibana.alert.rule.threat.tactic.name), + Esql.process_executable_values = VALUES(process.executable), + Esql.process_parent_executable_values = VALUES(process.parent.executable), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id + +// filter for risky hosts with multiple distinct rules across multiple tactics +// Distinct rule IDs prevent one rule mapped to multiple tactics from satisfying the correlation. +| where Esql.kibana_alert_rule_name_distinct_count >= 2 and + Esql.kibana_alert_rule_id_distinct_count >= 2 and + Esql.threat_tactic_id_distinct_count >= 3 + +// Populate the native host name for alert triage without changing the host.id correlation key. +| eval host.name = MV_FIRST(Esql.host_name_values) + +// fields populated in the resulting alert +| keep host.id, + host.name, + Esql.alerts_count, + Esql.kibana_alert_rule_name_distinct_count, + Esql.kibana_alert_rule_id_distinct_count, + Esql.process_entity_id_distinct_count, + Esql.event_module_values, + Esql.host_name_values, + Esql.kibana_alert_rule_name_values, + Esql.kibana_alert_rule_id_values, + Esql.threat_tactic_name_values, + Esql.process_executable_values, + Esql.process_parent_executable_values, + Esql.process_command_line_values + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-batch-job-submitted-with-container-override-by-unusual-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-batch-job-submitted-with-container-override-by-unusual-identity.asciidoc new file mode 100644 index 0000000000..863b324b17 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-batch-job-submitted-with-container-override-by-unusual-identity.asciidoc @@ -0,0 +1,112 @@ +[[prebuilt-rule-8-19-29-aws-batch-job-submitted-with-container-override-by-unusual-identity]] +=== AWS Batch Job Submitted with Container Override by Unusual Identity + +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. + +*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/batch/latest/APIReference/API_SubmitJob.html +* https://docs.aws.amazon.com/batch/latest/APIReference/API_ContainerOverrides.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Batch +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Batch Job Submitted with Container Override by Unusual Identity* + + +This rule fires when an identity submits a Batch job with a container command override and has not been observed doing so in the prior 7 days. Container overrides at submission time bypass job definition review — an adversary can inject a malicious command into an approved job definition without modifying it, making the change invisible to IaC drift detection or configuration compliance tools. + + +*Possible investigation steps* + + +- Identify the submitting principal (`aws.cloudtrail.user_identity.arn`) and determine whether they are expected to use AWS Batch with runtime overrides. +- Review `aws.cloudtrail.request_parameters` to extract the overridden command in `containerOverrides.command` - this is the trigger. Also inspect any environment variables or resource requirements present. Look for shell commands, curl/wget calls, base64-encoded payloads, or references to external endpoints in the command override. +- Identify the job queue and job definition used to understand the compute environment and IAM role the job will execute under. +- Search for `DescribeJobs` events after the submission to track execution status and output. +- Correlate with S3 `GetObject` or `PutObject` events from the Batch execution role during the job's execution window to identify data access or exfiltration. + + +*False positive analysis* + + +- ETL and data processing pipelines that parameterize job commands at submission time. +- CI/CD systems that submit test jobs with dynamic parameters. + + +*Response and remediation* + + +- If unauthorized, cancel the job immediately using `TerminateJob`. +- Review the Batch compute environment's IAM execution role for the scope of data access the job had. +- Restrict `batch:SubmitJob` with `Condition` keys on `batch:Image` and job queue ARNs to prevent arbitrary container override submissions. + + +==== Setup + + +The AWS CloudTrail integration must be enabled and configured to collect Batch management events (`batch.amazonaws.com`). + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "batch.amazonaws.com" + and event.action: "SubmitJob" + and event.outcome: "success" + and aws.cloudtrail.request_parameters: (*containerOverrides* and *command*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc new file mode 100644 index 0000000000..70f17e36ad --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-29-aws-bedrock-high-frequency-single-model-inference-api-probing]] +=== AWS Bedrock High-Frequency Single-Model Inference API Probing + +Identifies an AWS principal performing a high volume of Amazon Bedrock inference API calls against a single model within a short window. Membership inference attacks require hundreds to thousands of statistically similar queries whose prompts and responses are intentionally content-benign, making guardrail- and content-based rules ineffective. This rule detects the high-frequency single-model probing pattern that precedes membership inference and related exfiltration via the inference API. It is a behavioral / volumetric precursor: it does not observe model confidence scores and a fixed call-count threshold only catches the loud variant, so paced, low-and-slow, or credential-distributed probing will evade it. Definitive membership inference detection requires ML anomaly analysis over per-entity inference-rate and response-distribution baselines. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0024 +* https://atlas.mitre.org/techniques/AML.T0024.000 +* https://docs.aws.amazon.com/bedrock/latest/userguide/logging-using-cloudtrail.html +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Tactic: Exfiltration +* Mitre Atlas: T0024 +* Mitre Atlas: T0024.000 +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock High-Frequency Single-Model Inference API Probing* + + +Membership inference compares many samples against a model to infer whether specific records were present in training data. Because prompts and responses often appear benign, the actionable signal is frequently statistical: unusually high inference rates concentrated on one model from a single principal. AWS CloudTrail records the core Bedrock runtime operations (`InvokeModel`, `InvokeModelWithResponseStream`, `Converse`, `ConverseStream`) as management events, which are logged by default, so this probing phase is observable at the API layer even when Bedrock model invocation logging is disabled. CloudTrail does not capture the prompt body, so this rule is purely volumetric. + +This rule is tuned to the loud case. Treat it as corroborating signal alongside other Bedrock alerts, not as conclusive membership inference detection. + + +*Possible investigation steps* + + +- Identify the principal in `aws.cloudtrail.user_identity.arn` and the targeted model in the extracted `Esql.model_id`. +- Determine whether the call volume exceeds the principal's historical baseline for the same model. +- Review companion Bedrock invocation logs, if enabled, for short prompts, repeated inputs, or low-variance responses that may indicate membership testing. +- Inspect `Esql.source_ip_values`, `Esql.user_agent_original_values`, and recent IAM activity for signs of compromised credentials or unexpected automation. +- Correlate with bulk output-extraction or guardrail alerts that may indicate a broader inference abuse campaign. + + +*Response and remediation* + + +- Apply Bedrock service quotas and IAM least privilege for inference APIs while investigating. +- Enable model invocation logging for content-level review if not already configured. +- If abuse is confirmed, rotate access keys or disable the compromised principal. + + +==== Setup + + + +*Setup* + + +This rule requires AWS CloudTrail management events for Amazon Bedrock and ingestion via the AWS +integration (`aws.cloudtrail` data stream). The core Bedrock runtime operations are logged as management +events by default; no Bedrock model invocation logging is required. + + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* +| WHERE event.provider == "bedrock.amazonaws.com" + AND event.action IN ( + "InvokeModel", + "Converse", + "ConverseStream", + "InvokeModelWithResponseStream" + ) + AND event.outcome == "success" + AND aws.cloudtrail.user_identity.arn IS NOT NULL + AND aws.cloudtrail.request_parameters IS NOT NULL +| GROK aws.cloudtrail.request_parameters """modelId=(?[^,}\]]+)""" +| WHERE Esql.model_id IS NOT NULL +| STATS + Esql.inference_call_count = COUNT(*), + Esql.timestamp_min = MIN(@timestamp), + Esql.timestamp_max = MAX(@timestamp), + Esql.event_ingested_min = MIN(event.ingested), + Esql.event_ingested_max = MAX(event.ingested), + 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.source_geo_country_iso_code_values = + VALUES(source.geo.country_iso_code), + Esql.source_geo_city_name_values = + VALUES(source.geo.city_name), + Esql.user_name_values = VALUES(user.name), + Esql.user_agent_original_values = VALUES(user_agent.original), + Esql.aws_cloudtrail_user_identity_type_values = + VALUES(aws.cloudtrail.user_identity.type), + Esql.aws_cloudtrail_user_identity_access_key_id_values = + VALUES(aws.cloudtrail.user_identity.access_key_id), + Esql.session_issuer_arn_values = + VALUES(aws.cloudtrail.user_identity.session_context.session_issuer.arn), + Esql.cloud_region_values = VALUES(cloud.region), + Esql.data_stream_namespace_values = VALUES(data_stream.namespace) + BY aws.cloudtrail.user_identity.arn, + cloud.account.id, + Esql.model_id +| WHERE Esql.inference_call_count >= 500 +| KEEP + aws.cloudtrail.user_identity.arn, + cloud.account.id, + Esql.* +| sort Esql.inference_call_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-bedrock-high-risk-filesystem-or-execution-tool-invocation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-bedrock-high-risk-filesystem-or-execution-tool-invocation.asciidoc new file mode 100644 index 0000000000..7553114efe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-bedrock-high-risk-filesystem-or-execution-tool-invocation.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-29-aws-bedrock-high-risk-filesystem-or-execution-tool-invocation]] +=== AWS Bedrock High Risk Filesystem or Execution Tool Invocation + +Detects when a Bedrock model is prompted to invoke high-risk tools associated with shell execution, filesystem operations, or process spawning. Adversaries may use compromised AI agent pipelines or manipulated prompts to instruct the model to execute arbitrary system commands, read or write sensitive files, or spawn subprocesses — extending the blast radius of a credential compromise or prompt injection attack. + +*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*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/agents-action-groups.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html +* https://owasp.org/www-project-top-10-for-large-language-model-applications/ + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS Bedrock +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock High Risk Filesystem or Execution Tool Invocation* + + +This rule detects Bedrock model invocations where the prompt contains patterns associated with shell execution, filesystem access, or process spawning. These patterns may indicate a prompt injection attack, a compromised AI agent pipeline, or an insider attempting to use a Bedrock-backed application to execute unauthorized system operations. + + +*Possible investigation steps* + + +- Review `gen_ai.prompt` to identify the specific tool invocation pattern that triggered the rule and determine whether it represents a legitimate tool call or a malicious instruction. +- Identify the user (`user.id`) and determine whether they are expected to interact with tools that perform filesystem or shell operations. +- Review the model ID (`gen_ai.request.model.id`) and the application context to understand whether shell or filesystem tools are part of the intended agent architecture. +- Correlate with other Bedrock invocation events from the same user in the preceding hour to assess whether this is an isolated event or part of a pattern. +- If the application uses Bedrock Agents, review the agent's configured action groups and Lambda functions to determine whether the tool invocation could have resulted in actual execution. +- Check for downstream evidence of execution: CloudTrail Lambda invocation events, SSM RunCommand, or EC2 activity correlated with the same time window. + + +*False positive analysis* + + +- AI coding assistants and developer tools built on Bedrock may legitimately reference shell commands or file operations in their prompt templates. +- Security tooling that uses Bedrock to analyze shell scripts or code may produce prompts containing these patterns. + + +*Response and remediation* + + +- If a prompt injection is confirmed, identify the injection source and remediate the input validation gap in the application layer. +- Review and restrict the tools available to the Bedrock Agent to the minimum required for its function. +- Apply Bedrock Guardrails to block or flag prompts containing high-risk tool invocation patterns. +- If credentials were compromised, rotate them immediately and audit all Bedrock and downstream API activity. + + +==== Setup + + +The AWS Bedrock integration must be enabled with model invocation logging configured to capture prompt +and completion content. Ensure `logs-aws_bedrock.invocation-*` is ingested into Elasticsearch. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* metadata _id, _version, _index + +| eval Esql.lowercase_prompt = TO_LOWER(gen_ai.prompt) + +| where + Esql.lowercase_prompt like "*/bin/sh*" or + Esql.lowercase_prompt like "*/bin/bash*" or + Esql.lowercase_prompt like "*sh -c*" or + Esql.lowercase_prompt like "*cmd.exe*" or + Esql.lowercase_prompt like "*powershell*" or + Esql.lowercase_prompt like "*exec(*" or + Esql.lowercase_prompt like "*os.system*" or + Esql.lowercase_prompt like "*subprocess*" or + Esql.lowercase_prompt like "*python -c*" or + Esql.lowercase_prompt like "*python3 -c*" or + Esql.lowercase_prompt like "*curl *" or + Esql.lowercase_prompt like "*wget *" or + Esql.lowercase_prompt like "*/dev/tcp/*" or + Esql.lowercase_prompt like "*nc -e*" or + Esql.lowercase_prompt like "*ncat *" or + Esql.lowercase_prompt like "*socat *" or + Esql.lowercase_prompt like "*openssl s_client*" or + Esql.lowercase_prompt like "*perl -e*" or + Esql.lowercase_prompt like "*ruby -e*" or + Esql.lowercase_prompt like "*php -r*" or + Esql.lowercase_prompt like "*node -e*" or + Esql.lowercase_prompt like "*base64 -d*" or + Esql.lowercase_prompt like "*bash -i*" + +| keep _id, _version, _index, @timestamp, user.id, cloud.account.id, gen_ai.request.model.id, gen_ai.prompt, gen_ai.completion + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-ec2-nacl-entry-created-or-replaced-allowing-all-traffic-by-new-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-ec2-nacl-entry-created-or-replaced-allowing-all-traffic-by-new-identity.asciidoc new file mode 100644 index 0000000000..982f40a002 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-ec2-nacl-entry-created-or-replaced-allowing-all-traffic-by-new-identity.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-29-aws-ec2-nacl-entry-created-or-replaced-allowing-all-traffic-by-new-identity]] +=== AWS EC2 NACL Entry Created or Replaced Allowing All Traffic by New Identity + +Detects a principal account creating or replacing - or attempts to create or replace - an AWS Network Access Control List (NACL) entry using protocol -1 (all traffic). Both successful and failed outcomes are included. A NACL entry with protocol -1 passes all traffic regardless of port, which would disable network-layer controls for the affected subnets. Monitoring for new identities performing this change helps surface freshly compromised credentials or unauthorized principals removing a defense-in-depth layer to facilitate lateral movement or data exfiltration. This signal only flags if this behavior was not observed historically in a specific time window. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkAclEntry.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ReplaceNetworkAclEntry.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 NACL Entry Created or Replaced Allowing All Traffic by New Identity* + + +This rule fires when a NACL entry specifying all ports (0–65535) and all protocols is created or replaced. While NACLs are stateless and secondary to security groups, a permissive NACL entry can neutralize a defense-in-depth layer and may indicate an adversary attempting to ensure unrestricted connectivity for their tools or exfiltration channels. + + +*Possible investigation steps* + + +- Identify the creating principal (`aws.cloudtrail.user_identity.arn`) and determine whether they are authorized to modify network ACLs. +- Review `aws.cloudtrail.request_parameters` to identify the NACL ID, rule number, egress/ingress direction, and CIDR block (`0.0.0.0/0` for any-source rules are highest severity). +- Determine which subnets are associated with the modified NACL and assess the sensitivity of workloads in those subnets. +- Check for accompanying security group modifications that also expand access. +- Review VPC flow logs for unusual traffic to or from the affected subnets following the NACL change. +- Review `event.outcome` — `success` means the permissive entry was applied and the subnet's network-layer controls are weakened now; `failure` means the change was blocked, which from a new identity often indicates credential probing or permission reconnaissance. + + +*False positive analysis* + + +- Architectures that use NACLs as a stateless passthrough while relying on security groups for granular control may legitimately create permissive NACL entries. +- Development environments sometimes use open NACLs for convenience. + + +*Response and remediation* + + +- If unauthorized, immediately delete the permissive NACL entry and replace it with an appropriately restrictive rule. +- Review VPC flow logs for evidence of network activity that exploited the open rule. + + +==== Setup + + +The AWS CloudTrail integration must be enabled and configured to collect EC2 management events. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action: ("CreateNetworkAclEntry" or "ReplaceNetworkAclEntry") + and not aws.cloudtrail.user_identity.type: "AWSService" + and event.outcome: ("success" or "failure") + and aws.cloudtrail.flattened.request_parameters.aclProtocol: "-1" + and aws.cloudtrail.flattened.request_parameters.ruleAction: "allow" + and not user_agent.original: (*Terraform* or *terraform* or "cloudformation.amazonaws.com" or *pulumi* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-iam-permission-boundary-or-guardrail-policy-deleted-by-unusual-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-iam-permission-boundary-or-guardrail-policy-deleted-by-unusual-identity.asciidoc new file mode 100644 index 0000000000..36c7f7bea8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-iam-permission-boundary-or-guardrail-policy-deleted-by-unusual-identity.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-29-aws-iam-permission-boundary-or-guardrail-policy-deleted-by-unusual-identity]] +=== AWS IAM Permission Boundary or Guardrail Policy Deleted by Unusual Identity + +Detects the first time an AWS identity successfully deletes an IAM managed policy whose ARN contains guardrail-related keywords (for example Boundary, Deny, Restrict, Guard, SCP, Guardrail). Adversaries who have obtained elevated IAM privileges may delete policies to remove restrictive permissions boundaries, eliminate deny-based guardrails, or clean up after a privilege escalation operation. Infrastructure-as-code tools (Terraform, CloudFormation, Pulumi, and Ansible) are excluded because policy lifecycle management is a routine part of automated deployments. A policy deletion by an identity not seen performing this activity during the prior seven days may indicate newly compromised credentials being used to modify the account's permission structure. + +*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/IAM/latest/APIReference/API_DeletePolicy.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Defense Evasion +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Permission Boundary or Guardrail Policy Deleted by Unusual Identity* + + +This rule fires the first time an identity deletes a customer-managed IAM policy in the prior 7 days. Policy deletion is a privilege-escalation or defense-evasion primitive: removing a deny-based policy or permissions boundary silently expands the effective access of every principal that policy applied to. + + +*Possible investigation steps* + + +- Identify the deleting principal (`aws.cloudtrail.user_identity.arn`) and determine whether they have a history of IAM policy management in audit logs beyond the 7-day window. +- Review `aws.cloudtrail.request_parameters` to identify the policy ARN that was deleted. Policies with names containing "Boundary", "Deny", or "Restrict" in the ARN are highest priority. +- Check whether any principal previously had this policy attached as a permissions boundary — if so, those principals may now operate without that constraint. +- Review the same identity's CloudTrail activity for other IAM privilege escalation indicators in the same session: `CreatePolicyVersion`, `SetDefaultPolicyVersion`, `AttachRolePolicy`, `UpdateAssumeRolePolicy`. +- Determine whether this identity was recently assumed via `AssumeRole` from an unusual source IP. + + +*False positive analysis* + + +- First-time IaC deployments (Terraform apply, CDK deploy) that manage IAM resources will appear as new identities performing policy deletions. +- New service accounts introduced to handle IAM lifecycle management. + + +*Response and remediation* + + +- If unauthorized, determine whether the deleted policy was a permissions boundary and re-apply it immediately to all affected principals. +- Revoke or disable the credentials used to perform the deletion pending investigation. +- Review all principals that had the policy attached and audit their current effective permissions. + + +==== Setup + + +The AWS CloudTrail integration must be enabled and configured to collect IAM management events. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "DeletePolicy" + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + and aws.cloudtrail.request_parameters: (*Boundary* or *boundary* or *Deny* or *deny* or *Restrict* or *restrict* or *Guard* or *guard* or *SCP* or *Guardrail* or *guardrail*) + and not user_agent.original: (*Terraform* or *terraform* or "cloudformation.amazonaws.com" or *pulumi* or *Pulumi* or *ansible* or *Ansible*) + +---------------------------------- + +*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/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-iam-user-self-created-access-key-subsequently-used.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-iam-user-self-created-access-key-subsequently-used.asciidoc new file mode 100644 index 0000000000..263be80032 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-iam-user-self-created-access-key-subsequently-used.asciidoc @@ -0,0 +1,222 @@ +[[prebuilt-rule-8-19-29-aws-iam-user-self-created-access-key-subsequently-used]] +=== AWS IAM User Self-Created Access Key Subsequently Used + +Detects an AWS IAM user using an existing credential to create a new access key for itself and subsequently using the new key within one hour. This behavior can indicate an adversary converting compromised credentials into an additional long-term credential for persistence. Unlike a standalone self-service key creation alert, requiring subsequent use of the new key reduces noise from unused or abandoned credential-rotation operations. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-35m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/#iamcreateaccesskey +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html +* https://github.com/RhinoSecurityLabs/pacu/tree/master/pacu/modules/iam__backdoor_users_keys + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM User Self-Created Access Key Subsequently Used* + + +This rule detects an IAM user using an existing access key (Token A) to create a new access key for itself (Token B), followed by an AWS API request authenticated with Token B within one hour. The creation event proves that Token A was used to request the additional credential, while the subsequent CloudTrail event confirms that Token B became active. + +This sequence can indicate persistence after an IAM user's credentials are compromised. An adversary can use the compromised key to create another long-term credential, then continue accessing the account through the new key even after the original credential is identified and disabled. + + +*Possible investigation steps* + + +- Identify the IAM user and AWS account using `aws.cloudtrail.user_identity.arn` and `cloud.account.id`. +- Review Token A in `Esql_priv.aws_cloudtrail_user_identity_access_key_id_creator_values`. Determine whether it is an expected credential for the IAM user and whether it was previously observed from unusual infrastructure. +- Confirm that the key in `Esql_priv.aws_cloudtrail_response_elements_access_key_access_key_id_values` matches the subsequently used key in `Esql_priv.aws_cloudtrail_user_identity_access_key_id_created_key_use_values`. +- Compare `Esql.source_ip_self_access_key_creation_values` with `Esql.source_ip_created_access_key_use_values`. A rapid change in source IP, ASN, geography, or hosting provider increases suspicion. +- Compare `Esql.user_agent_original_self_access_key_creation_values` with `Esql.user_agent_original_created_access_key_use_values` to identify changes between the creation and use clients. +- Review `Esql.event_action_created_access_key_use_values` to determine what Token B accessed or modified after creation. +- Examine nearby CloudTrail activity for IAM reconnaissance, MFA changes, login-profile changes, policy modifications, or attempts to create additional credentials. +- Confirm whether the activity corresponds to an approved credential-rotation workflow and whether the user is permitted to create its own long-term access keys. + + +*False positive analysis* + + +- Approved credential-rotation automation may create and immediately test or use a replacement access key. +- Developer onboarding or recovery workflows may create a key and validate it with an initial AWS API request. +- Validate the principal, source addresses, user agents, timing, and change records before excluding the activity. Prefer narrowly scoped exceptions for verified automation rather than excluding the IAM user broadly. + + +*Response and remediation* + + +- If unauthorized, deactivate or delete Token B immediately. +- Rotate or disable Token A and investigate how it was exposed or compromised. +- Review every CloudTrail event authenticated with Token B and determine whether it accessed data, changed IAM permissions, created resources, or established additional persistence. +- Review the IAM user's policies and remove unnecessary `iam:CreateAccessKey` permissions. +- Prefer temporary credentials and IAM Identity Center for human access instead of long-term IAM user access keys. +- Preserve the relevant CloudTrail events, access key IDs, source addresses, and user-agent values for incident response. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* +| WHERE data_stream.dataset == "aws.cloudtrail" + AND ( + ( + event.provider == "iam.amazonaws.com" + AND event.action == "CreateAccessKey" + AND event.outcome == "success" + AND aws.cloudtrail.user_identity.type == "IAMUser" + ) + OR ( + aws.cloudtrail.user_identity.type == "IAMUser" + AND aws.cloudtrail.user_identity.access_key_id LIKE "AKIA*" + AND NOT ( + event.provider == "iam.amazonaws.com" + AND event.action == "CreateAccessKey" + ) + ) + ) +| GROK aws.cloudtrail.response_elements """.*accessKeyId=(?AKIA[A-Z0-9]{16}).*""" +| EVAL + Esql.aws_cloudtrail_self_access_key_creation_flag = CASE( + event.provider == "iam.amazonaws.com" + AND event.action == "CreateAccessKey" + AND event.outcome == "success" + AND aws.cloudtrail.user_identity.type == "IAMUser" + AND ( + user.target.name IS NULL + OR user.name == user.target.name + ) + AND Esql_priv.aws_cloudtrail_response_elements_access_key_access_key_id IS NOT NULL, + 1, + 0 + ), + Esql.aws_cloudtrail_created_access_key_use_flag = CASE( + aws.cloudtrail.user_identity.type == "IAMUser" + AND aws.cloudtrail.user_identity.access_key_id LIKE "AKIA*" + AND NOT ( + event.provider == "iam.amazonaws.com" + AND event.action == "CreateAccessKey" + ), + 1, + 0 + ) +| EVAL + Esql_priv.aws_cloudtrail_user_identity_access_key_id_creator = CASE( + Esql.aws_cloudtrail_self_access_key_creation_flag == 1, + aws.cloudtrail.user_identity.access_key_id, + null + ), + Esql_priv.aws_cloudtrail_access_key_id_correlation = CASE( + Esql.aws_cloudtrail_self_access_key_creation_flag == 1, + Esql_priv.aws_cloudtrail_response_elements_access_key_access_key_id, + aws.cloudtrail.user_identity.access_key_id + ) +| WHERE Esql_priv.aws_cloudtrail_access_key_id_correlation IS NOT NULL + AND aws.cloudtrail.user_identity.arn IS NOT NULL +| STATS + Esql.aws_cloudtrail_self_access_key_creation_count = + COUNT(*) WHERE Esql.aws_cloudtrail_self_access_key_creation_flag == 1, + Esql.aws_cloudtrail_created_access_key_use_count = + COUNT(*) WHERE Esql.aws_cloudtrail_created_access_key_use_flag == 1, + Esql_priv.aws_cloudtrail_user_identity_access_key_id_creator_values = + VALUES(Esql_priv.aws_cloudtrail_user_identity_access_key_id_creator) + WHERE Esql.aws_cloudtrail_self_access_key_creation_flag == 1, + Esql_priv.aws_cloudtrail_response_elements_access_key_access_key_id_values = + VALUES(Esql_priv.aws_cloudtrail_response_elements_access_key_access_key_id) + WHERE Esql.aws_cloudtrail_self_access_key_creation_flag == 1, + Esql_priv.aws_cloudtrail_user_identity_access_key_id_created_key_use_values = + VALUES(aws.cloudtrail.user_identity.access_key_id) + WHERE Esql.aws_cloudtrail_created_access_key_use_flag == 1, + Esql.timestamp_self_access_key_creation_min = + MIN(@timestamp) + WHERE Esql.aws_cloudtrail_self_access_key_creation_flag == 1, + Esql.timestamp_created_access_key_use_min = + MIN(@timestamp) + WHERE Esql.aws_cloudtrail_created_access_key_use_flag == 1, + Esql.source_ip_self_access_key_creation_values = + VALUES(source.ip) + WHERE Esql.aws_cloudtrail_self_access_key_creation_flag == 1, + Esql.source_ip_created_access_key_use_values = + VALUES(source.ip) + WHERE Esql.aws_cloudtrail_created_access_key_use_flag == 1, + Esql.user_agent_original_self_access_key_creation_values = + VALUES(user_agent.original) + WHERE Esql.aws_cloudtrail_self_access_key_creation_flag == 1, + Esql.user_agent_original_created_access_key_use_values = + VALUES(user_agent.original) + WHERE Esql.aws_cloudtrail_created_access_key_use_flag == 1, + Esql.event_action_created_access_key_use_values = + VALUES(event.action) + WHERE Esql.aws_cloudtrail_created_access_key_use_flag == 1 + BY cloud.account.id, + aws.cloudtrail.user_identity.arn, + Esql_priv.aws_cloudtrail_access_key_id_correlation +| WHERE Esql.aws_cloudtrail_self_access_key_creation_count > 0 + AND Esql.aws_cloudtrail_created_access_key_use_count > 0 + AND Esql.timestamp_created_access_key_use_min > + Esql.timestamp_self_access_key_creation_min + AND DATE_DIFF( + "seconds", + Esql.timestamp_self_access_key_creation_min, + Esql.timestamp_created_access_key_use_min + ) <= 3600 +| KEEP + cloud.account.id, + aws.cloudtrail.user_identity.arn, + Esql.*, + Esql_priv.* + +---------------------------------- + +*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-29/prebuilt-rule-8-19-29-aws-s3-bucket-acl-modified-to-allow-public-access-by-new-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-s3-bucket-acl-modified-to-allow-public-access-by-new-identity.asciidoc new file mode 100644 index 0000000000..1feeea81e3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-s3-bucket-acl-modified-to-allow-public-access-by-new-identity.asciidoc @@ -0,0 +1,113 @@ +[[prebuilt-rule-8-19-29-aws-s3-bucket-acl-modified-to-allow-public-access-by-new-identity]] +=== AWS S3 Bucket ACL Modified to Allow Public Access by New Identity + +Detects a principal modifying an S3 bucket ACL to grant public read or write access that has not been observed doing so within the history window, using canned ACLs such as public-read or public-read-write. ACL-based public access is a distinct API path (PutBucketAcl) that can bypass some Block Public Access controls. Monitoring for new identities performing this change helps surface freshly compromised credentials being used to stage data for exfiltration or inadvertently expose sensitive content. + +*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/AmazonS3/latest/API/API_PutBucketAcl.html +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-overview.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: Amazon S3 +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket ACL Modified to Allow Public Access by New Identity* + + +This rule fires when a `PutBucketAcl` call sets a canned ACL that grants public or broad access. Unlike bucket policies, bucket ACLs are a legacy mechanism that bypasses some newer Block Public Access controls and can inadvertently or deliberately expose bucket contents to unauthenticated internet users. + + +*Possible investigation steps* + + +- Identify the modifying principal (`aws.cloudtrail.user_identity.arn`) and determine whether they are authorized to modify S3 bucket ACLs. +- Review `aws.cloudtrail.request_parameters` to confirm the specific canned ACL applied (`public-read`, `public-read-write`). +- Check whether AWS S3 Block Public Access is enabled at the account or bucket level — if so, it may still be preventing effective public exposure even though this ACL change succeeded. +- Enumerate the bucket contents to assess the sensitivity of any exposed data. +- Check for recent `GetObject` or `ListObjects` calls from unauthenticated sources against the same bucket. + + +*False positive analysis* + + +- Static website hosting buckets are commonly configured with `public-read` ACLs. + + +*Response and remediation* + + +- If unauthorized, immediately reset the bucket ACL to `private` using `PutBucketAcl`. +- Enable S3 Block Public Access at the account level to prevent future ACL-based public exposure across all buckets. +- Review the bucket's object-level access log for any unauthorized reads that occurred after the ACL change. + + +==== Setup + + +The AWS CloudTrail integration must be enabled and configured to collect S3 management events (`s3.amazonaws.com`). + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "s3.amazonaws.com" + and event.action: "PutBucketAcl" + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + and aws.cloudtrail.flattened.request_parameters.x-amz-acl: ("public-read" or "public-read-write") + and not user_agent.original: (*Terraform* or *terraform* or "cloudformation.amazonaws.com" or *pulumi* or *Pulumi*) + +---------------------------------- + +*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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-sagemaker-execution-role-passed-by-unusual-principal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-sagemaker-execution-role-passed-by-unusual-principal.asciidoc new file mode 100644 index 0000000000..bc056da978 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-aws-sagemaker-execution-role-passed-by-unusual-principal.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-29-aws-sagemaker-execution-role-passed-by-unusual-principal]] +=== AWS SageMaker Execution Role Passed by Unusual Principal + +Identifies the first time an IAM principal passes a given execution role (`roleArn`) to an Amazon SageMaker resource, via `CreateNotebookInstance`, `CreateTrainingJob`, `CreateProcessingJob`, `CreateAutoMLJob`, or `CreatePipeline`. These actions require `iam:PassRole` and attach an IAM role that the created resource then runs as. An adversary holding both SageMaker create permissions and a broad `iam:PassRole` grant can pass a more privileged role to a resource they control and execute code as that role, escalating privileges. The rule keys on the combination of the calling principal and the passed `roleArn`, so it surfaces a principal using an execution role it has not used before in the last 7 days; a role whose account differs from the caller's, or that is more privileged than the caller, is especially suspicious. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-7d ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-roles.html +* https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateNotebookInstance.html +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.execution.sagemaker-update-lifecycle-config/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SageMaker +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SageMaker Execution Role Passed by Unusual Principal* + + +SageMaker resource-creation actions accept a `roleArn` execution role and require the caller to hold `iam:PassRole` +for it. The created resource (notebook, training job, processing job, AutoML job, or pipeline) then runs as that +role. This is a known cloud privilege-escalation path: a principal with SageMaker create rights and a broad +`PassRole` permission can attach a more privileged role to a resource it controls and run code as that role. This +rule keys on the principal and the passed `roleArn` together, so it flags the first time a principal uses a given +execution role within the last 7 days, which should then be reviewed for over-privilege or a cross-account owner. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn`, and review `Esql.source_ip_values` and + `Esql.user_agent_original_values` for an unexpected origin. +- Inspect `Esql.aws_cloudtrail_request_parameters_role_arn` and review that role's policies; determine whether it is + more privileged than the caller. +- Determine whether the principal normally creates SageMaker resources and whether this aligns with an approved + pipeline or project. +- Correlate with follow-on activity by the passed role, such as actions outside SageMaker, presigned URL generation, + or lifecycle configuration changes that would provide interactive execution as the role. + + +*False positive analysis* + + +- Legitimate MLOps creates SageMaker resources with execution roles; new pipelines and users appear as new + principals on first use. Confirm the role and activity are approved and exclude known automation roles on + `aws.cloudtrail.user_identity.arn` after validation. + + +*Response and remediation* + + +- If unauthorized, stop and delete the created resource, and review any actions taken by the passed role. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `iam:PassRole` and + SageMaker create permissions so principals can only pass narrowly scoped, approved execution roles. + + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* +| WHERE data_stream.dataset == "aws.cloudtrail" + AND event.provider == "sagemaker.amazonaws.com" + AND event.action IN ( + "CreateNotebookInstance", + "CreateTrainingJob", + "CreateProcessingJob", + "CreateAutoMLJob", + "CreatePipeline" + ) + AND event.outcome == "success" + AND aws.cloudtrail.user_identity.type != "AWSService" +| GROK aws.cloudtrail.request_parameters """.*roleArn=(?arn:aws[a-z-]*:iam::[0-9]{12}:role/[^,}]+).*""" +| WHERE Esql.aws_cloudtrail_request_parameters_role_arn IS NOT NULL +| EVAL Esql.principal_arn = COALESCE( + aws.cloudtrail.user_identity.session_context.session_issuer.arn, + aws.cloudtrail.user_identity.arn + ) +| STATS + Esql.timestamp_min = MIN(@timestamp), + Esql.timestamp_max = MAX(@timestamp), + Esql.ingested_min = MIN(COALESCE(event.ingested, @timestamp)), + Esql.event_count = COUNT(*), + Esql.event_action_values = VALUES(event.action), + Esql.source_ip_values = VALUES(source.ip), + Esql.user_agent_original_values = VALUES(user_agent.original), + Esql.user_identity_arn_values = VALUES(aws.cloudtrail.user_identity.arn), + Esql.cloud_account_id_values = VALUES(cloud.account.id), + Esql.cloud_region_values = VALUES(cloud.region) + BY Esql.principal_arn, + Esql.aws_cloudtrail_request_parameters_role_arn +| WHERE Esql.ingested_min >= NOW() - 10 minutes +| KEEP Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* 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-29/prebuilt-rule-8-19-29-azure-aks-certificate-signing-request-created-or-approved.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-certificate-signing-request-created-or-approved.asciidoc new file mode 100644 index 0000000000..efb54b859e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-certificate-signing-request-created-or-approved.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-29-azure-aks-certificate-signing-request-created-or-approved]] +=== Azure AKS Certificate Signing Request Created or Approved + +Detects an identity creating a client-authentication CertificateSigningRequest (signer kubernetes.io/kube-apiserver-client) or approving a CSR on AKS (Azure Kubernetes Service), excluding node bootstrap and platform controllers. Adversaries submit and self-approve a CSR against the kube-apiserver-client signer to mint a long-lived client certificate for an arbitrary subject (for example a Common Name in system:masters), giving durable authenticated access that survives token revocation. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token forging a certificate is not excluded. + +*Rule type*: query + +*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://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/ +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://github.com/inguardians/peirates +* https://raesene.github.io/blog/2022/12/21/Kubernetes-persistence-with-Tocan-and-Teisteanas/ +* https://cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services +* https://www.aquasec.com/blog/kubernetes-rbac-privilige-escalation/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Certificate Signing Request Created or Approved* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. A CSR created against the +`kubernetes.io/kube-apiserver-client` signer lets the requester choose the certificate's subject (Common Name and +organization/groups); once approved it mints a client certificate for an arbitrary identity that yields access not tied +to a token. The default `CertificateSubjectRestriction` admission controller blocks requests for the `system:masters` +group, so attackers commonly request a Common Name matching an existing privileged user (or another privileged group) +instead, making the requested subject the key thing to decode. Node and kubelet certificates use the +`kube-apiserver-client-kubelet` and `kubelet-serving` signers (whose subject is constrained to the node) and are out of +scope; cert-manager and application CSRs use their own signers. + + +*Possible investigation steps* + + +- Identify the requesting identity in `azure.platformlogs.properties.log.user.username` (and its groups in + `azure.platformlogs.properties.log.user.groups`) and whether it should submit or approve CSRs. A workload service + account (`system:serviceaccount::`) or `masterclient` (the local cluster-admin cert) is the higher-concern + case. +- Confirm the signer in `azure.platformlogs.properties.log.requestObject.spec.signerName` and decode the base64 CSR in + `azure.platformlogs.properties.log.requestObject.spec.request` to read the requested Common Name and organization + (groups); a subject in `system:masters` or another privileged group is the escalation. +- Determine whether the same or a related identity approved the CSR (`verb:update`/`patch` on the `approval` + subresource), which indicates self-approval, and inspect `azure.platformlogs.properties.log.userAgent`. +- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs` and pivot on it for follow-on privileged API + activity using the newly issued certificate. + + +*False positive analysis* + + +- Node bootstrap (`kube-apiserver-client-kubelet` signer), kubelet-serving CSRs, and cert-manager/application CSRs + (custom signers) are out of scope by design; the kube-controller-manager `certificate-controller` and the AKS + `aksService` approver are excluded by identity. +- Manual CSR approval by an administrator, or an operator that legitimately mints client certificates, may surface; + baseline those identities and exclude the specific validated account rather than re-broadening to all `system:*`, + which would blind the rule to compromised workload service accounts. + + +*Response and remediation* + + +- If unauthorized, deny or delete the CSR, revoke the issued certificate, and rotate the cluster CA if a privileged + certificate was minted. +- Review the RBAC that allowed CSR creation and approval, and audit actions taken with the certificate. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs` +data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft +recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). CSR create and +approval are mutating operations recorded in both categories with the same `auditID`, so clusters that enable both +categories may generate two alerts per event. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:("kube-audit" or "kube-audit-admin") and + azure.platformlogs.properties.log.stage:"ResponseComplete" and + azure.platformlogs.properties.log.objectRef.resource:"certificatesigningrequests" and + azure.platformlogs.properties.log.responseStatus.code: "200" and + azure.platformlogs.properties.log.requestObject.status.conditions.type: "Approved" and + ( + ( + azure.platformlogs.properties.log.verb:"create" and + azure.platformlogs.properties.log.requestObject.spec.signerName:"kubernetes.io/kube-apiserver-client" + ) or ( + azure.platformlogs.properties.log.verb:("update" or "patch") and + azure.platformlogs.properties.log.objectRef.subresource:"approval" + ) + ) and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or system\:bootstrap\:* or "aksService" or "hcpService" or + "readinessChecker" or system\:serviceaccount\:kube-system\:* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Authentication Certificates +** ID: T1649 +** Reference URL: https://attack.mitre.org/techniques/T1649/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-coredns-or-kube-dns-configuration-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-coredns-or-kube-dns-configuration-modified.asciidoc new file mode 100644 index 0000000000..443696ae1f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-coredns-or-kube-dns-configuration-modified.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-29-azure-aks-coredns-or-kube-dns-configuration-modified]] +=== Azure AKS CoreDNS or Kube-DNS Configuration Modified + +Detects an identity creating or modifying the CoreDNS or kube-dns ConfigMap in the kube-system namespace on AKS (Azure Kubernetes Service), excluding known AKS control-plane and platform identities. Rewriting cluster DNS (by editing coredns/kube-dns or creating and editing coredns-custom) enables cluster-wide adversary-in-the-middle by redirecting internal service resolution to attacker-controlled IPs, allowing credential capture and traffic interception. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token is not excluded. + +*Rule type*: query + +*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://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/ +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/techniques/CoreDNS%20poisoning/ +* https://learn.microsoft.com/en-us/azure/aks/coredns-custom +* https://www.aquasec.com/blog/dns-spoofing-kubernetes-clusters/ +* https://hub.armosec.io/docs/c-0037 + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS CoreDNS or Kube-DNS Configuration Modified* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. CoreDNS resolves in-cluster +service names; an attacker who edits `coredns`/`kube-dns` or creates/edits the user-managed `coredns-custom` ConfigMap +can inject forward or rewrite rules that redirect service resolution to attacker-controlled endpoints, enabling +cluster-wide interception of credentials and traffic. `coredns-custom` is the supported customization surface, so +legitimate DNS tuning also lands here; the acting identity is excluded when it is an AKS platform reconciler +(`aksService`), leaving non-platform changes as the signal. + + +*Possible investigation steps* + + +- Review the submitted ConfigMap body in `azure.platformlogs.properties.log.requestObject.data` for added forward, + rewrite, or hosts entries pointing at unexpected IPs or domains. This content, not the act of editing, is what + distinguishes malicious DNS redirection from routine customization. +- Identify the acting identity in `azure.platformlogs.properties.log.user.username` (and its groups in + `azure.platformlogs.properties.log.user.groups`) and confirm it should manage the CoreDNS configuration; a workload + service account (`system:serviceaccount::`) editing cluster DNS is the higher-concern case. +- Confirm the operation and object via `azure.platformlogs.properties.log.verb` (a `create` of `coredns-custom` where it + did not previously exist is notable) and `azure.platformlogs.properties.log.objectRef.name` (`coredns`, + `coredns-custom`, or `kube-dns`), and inspect `azure.platformlogs.properties.log.userAgent`. +- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs` and pivot on it for related RBAC changes, secret + reads, or exec sessions. + + +*False positive analysis* + + +- `coredns-custom` is the AKS-supported way to add custom forward/stub rules, so approved automation, GitOps, or + administrators editing it are expected. The AKS reconciler (`aksService`) that continuously (re)creates + `coredns-custom` is excluded by identity. Validate the change content and window, then exclude the specific verified + service account rather than re-broadening to all `system:*`. + + +*Response and remediation* + + +- If unauthorized, restore the CoreDNS ConfigMap from a known-good source, revoke the acting identity's tokens, and + review the RBAC that permitted the change. +- Hunt for credential capture or redirected traffic during the window the malicious configuration was active. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs` +data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft +recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). ConfigMap writes are +mutating operations recorded in both categories with the same `auditID`, so clusters that enable both categories may +generate two alerts per change. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:("kube-audit" or "kube-audit-admin") and + azure.platformlogs.properties.log.stage:"ResponseComplete" and + azure.platformlogs.properties.log.objectRef.resource:"configmaps" and + azure.platformlogs.properties.log.objectRef.namespace:"kube-system" and + azure.platformlogs.properties.log.objectRef.name:("coredns" or "kube-dns" or "coredns-custom") and + azure.platformlogs.properties.log.verb:("create" or "update" or "patch" or "delete") and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or + system\:serviceaccount\:kube-system\:* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-ephemeral-container-added-to-pod.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-ephemeral-container-added-to-pod.asciidoc new file mode 100644 index 0000000000..4ffeb94f8d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-ephemeral-container-added-to-pod.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-29-azure-aks-ephemeral-container-added-to-pod]] +=== Azure AKS Ephemeral Container Added to Pod + +Detects an identity injecting an ephemeral (debug) container into a running AKS (Azure Kubernetes Service) pod via the pods/ephemeralcontainers subresource, excluding known AKS control-plane and platform identities. Ephemeral containers share the target pod's namespaces and give stealthy interactive access to its processes and mounted secrets without creating a new pod. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token used to attach a debug container is not excluded. + +*Rule type*: query + +*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://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://unit42.paloaltonetworks.com/hildegard-malware-teamtnt/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Ephemeral Container Added to Pod* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. An ephemeral container is +attached to a running pod (via `kubectl debug`) and shares that pod's process and network namespaces. Adversaries use it +as a stealthier alternative to `exec` to read mounted secrets and interact with the workload. + + +*Possible investigation steps* + + +- Identify the acting identity in `azure.platformlogs.properties.log.user.username` (and its groups in + `azure.platformlogs.properties.log.user.groups`) and whether it should debug pods. A username of `masterclient` with + the `system:masters` group is the AKS local cluster-admin certificate (`az aks get-credentials --admin`); on clusters + with local accounts disabled it should not appear at all, so its presence is itself notable. Entra-integrated admins + appear as their UPN/objectId instead. +- Inspect the injected container in the `azure.platformlogs.properties.log.requestObject.spec.ephemeralContainers.*` + fields: the `image`, `command`, and `targetContainerName` show what was run and against which container, and + `securityContext.capabilities.add` (e.g. `SYS_PTRACE`, `SYS_ADMIN`) or a privileged context indicates offensive + debugging. +- Review `azure.platformlogs.properties.log.userAgent` to distinguish an interactive `kubectl debug` from automation or + custom tooling, and `azure.platformlogs.properties.log.responseStatus.code` to tell a successful injection (200) from + a denied attempt (403) by an identity lacking RBAC. +- Identify the target pod in `azure.platformlogs.properties.log.objectRef.name` / + `azure.platformlogs.properties.log.objectRef.namespace`. +- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs` and pivot on it for related exec sessions, secret + reads, or RBAC changes. + + +*False positive analysis* + + +- Operators and support tooling use ephemeral containers for legitimate troubleshooting; baseline expected users and + exclude verified break-glass or platform identities. + + +*Response and remediation* + + +- If unauthorized, remove the ephemeral container (delete or replace the pod), revoke the acting identity's tokens, and + review the RBAC that permitted the injection. +- Inspect the target pod for accessed secrets or tampering and rotate any exposed credentials. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs` +data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft +recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). Mutating +ephemeral-container writes are recorded in both categories with the same `auditID`, so clusters that enable both +categories may generate two alerts per injection. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:("kube-audit" or "kube-audit-admin") and + azure.platformlogs.properties.log.stage:"ResponseComplete" and + azure.platformlogs.properties.log.objectRef.resource:"pods" and + azure.platformlogs.properties.log.objectRef.subresource:"ephemeralcontainers" and + azure.platformlogs.properties.log.verb:("update" or "patch") and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or + system\:serviceaccount\:kube-system\:* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-kubernetes-events-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-kubernetes-events-deleted.asciidoc new file mode 100644 index 0000000000..1d83dbb321 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-kubernetes-events-deleted.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-29-azure-aks-kubernetes-events-deleted]] +=== Azure AKS Kubernetes Events Deleted + +Detects an identity deleting Kubernetes events on AKS (Azure Kubernetes Service), excluding known AKS control-plane and platform identities. Adversaries delete events (individually or in bulk via deletecollection) to remove evidence of pod creation, exec, or scheduling activity and impair incident response after operating in the cluster. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token wiping events is not excluded. + +*Rule type*: query + +*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://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/event-v1/ +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://learn.microsoft.com/en-us/azure/aks/monitor-aks +* https://kubenomicon.com/Defense_evasion/Delete_events.html + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Kubernetes Events Deleted* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. Kubernetes events record pod +scheduling, image pulls, and other cluster activity. Deleting them (individually with `delete`, or in bulk with +`deletecollection`) outside of known AKS control-plane and platform identities is a defense-evasion step to erase +evidence of prior actions. + + +*Possible investigation steps* + + +- Identify the acting identity in `azure.platformlogs.properties.log.user.username` (and its groups in + `azure.platformlogs.properties.log.user.groups`) and whether it should delete events. A username of `masterclient` + (`system:masters`) is the AKS local cluster-admin certificate; workload service accounts + (`system:serviceaccount::`) deleting events are the higher-concern case. +- Determine the scale from `azure.platformlogs.properties.log.verb`: `deletecollection` is a bulk wipe (e.g. + `kubectl delete events --all`), while `delete` removes a single event. Review the target scope in + `azure.platformlogs.properties.log.objectRef.namespace` / `azure.platformlogs.properties.log.objectRef.name`. +- Inspect `azure.platformlogs.properties.log.userAgent` to distinguish interactive tooling (`kubectl`) from automation + or custom clients, and pivot on `azure.platformlogs.properties.log.sourceIPs` for the activity the deletion may be + concealing (pod creation, exec, RBAC changes). +- Reconstruct the timeline from surviving kube-audit records, which persist independently of the deleted Kubernetes + events. + + +*False positive analysis* + + +- Event cleanup jobs or platform tooling may bulk-delete events; baseline the responsible identities and exclude + verified automation. If a platform control-plane identity (for example an event TTL/garbage-collection component) + surfaces, add that specific identity to the exclusion rather than re-broadening to all `system:*`, which would blind + the rule to compromised workload service accounts. + + +*Response and remediation* + + +- If unauthorized, revoke the acting identity's tokens and review the RBAC that permitted event deletion. +- Use kube-audit history to reconstruct the concealed activity and scope the incident. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs` +data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft +recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). Event deletions are +mutating operations recorded in both categories with the same `auditID`, so clusters that enable both categories may +generate two alerts per deletion. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:("kube-audit" or "kube-audit-admin") and + azure.platformlogs.properties.log.stage:"ResponseComplete" and + azure.platformlogs.properties.log.objectRef.resource:"events" and + azure.platformlogs.properties.log.verb:("delete" or "deletecollection") and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or + system\:serviceaccount\:kube-system\:* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-potential-api-enumeration-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-potential-api-enumeration-by-user.asciidoc new file mode 100644 index 0000000000..6948da5d1a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-potential-api-enumeration-by-user.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-29-azure-aks-potential-api-enumeration-by-user]] +=== Azure AKS Potential API Enumeration by User + +Detects a single Kubernetes identity in AKS (Azure Kubernetes Service) that is denied (HTTP 403 Forbidden) across multiple distinct API resource types within a short window. Broad authorization failures spanning many resources are a strong signal of API enumeration (reconnaissance with a stolen service account token), as an actor probes what its credentials can reach before privilege escalation. Detection is based on the breadth of denied resources rather than the raw failure count, so single-resource controller retry loops do not trigger it. + +*Rule type*: threshold + +*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/aks/monitor-aks +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://github.com/inguardians/peirates + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Potential API Enumeration by User* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. This rule groups forbidden +(HTTP 403) Kubernetes API calls by `azure.platformlogs.properties.log.user.username` and alerts when one identity is +denied across several distinct `objectRef.resource` types within the interval. Breadth of denied resources (rather than +raw failure volume) is the signal: an identity probing many resource types it cannot reach is characteristic of API +enumeration with a stolen service account token, whereas a controller stuck retrying one forbidden resource stays on a +single resource and does not trigger. + + +*Possible investigation steps* + + +- Enumerate the distinct `azure.platformlogs.properties.log.objectRef.resource` and + `azure.platformlogs.properties.log.verb` values denied for the identity, and read the human-readable denial in + `azure.platformlogs.properties.log.responseStatus.message` (for example "secrets is forbidden: User ... cannot list + resource"), to see what the actor was mapping out. +- Identify the acting identity in `azure.platformlogs.properties.log.user.username` and its groups in + `azure.platformlogs.properties.log.user.groups`. Service account tokens (`system:serviceaccount::`) probing + broadly are the primary concern; confirm whether that identity should be issuing these calls at all. +- Inspect `azure.platformlogs.properties.log.userAgent` to distinguish interactive tooling (`kubectl`) or a known + controller from custom recon tooling (for example `kubectl-recon`, `curl`, or other enumeration clients). +- Validate the source in `azure.platformlogs.properties.log.sourceIPs`. In-cluster agents use loopback + (`127.0.0.1`/`::1`) or pod-network addresses (e.g. `10.244.0.0/16`); an external caller wielding a service account + token is more suspicious. +- Hunt for later successful calls (`responseStatus.code:2xx`) from the same identity or source that indicate the actor + found a permitted action or escalated, and correlate with recent Entra ID sign-ins or role assignments. + + +*False positive analysis* + + +- A workload or observability agent with partial RBAC can be denied across several resource types and resemble + enumeration. Baseline such identities, raise the cardinality threshold, or exclude the specific validated service + account after review. +- Single-resource retry loops (one resource denied repeatedly, such as a controller watching a resource it lacks + permission for) do not trigger this rule, since detection is based on the count of distinct resources denied. + + +*Response and remediation* + + +- If unauthorized, revoke the identity's tokens and kubeconfig and review the RBAC bindings assigned to it. +- Determine whether any request from the identity succeeded and scope the impact accordingly. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs` +data stream is required for this rule. The `kube-audit` log category is required specifically: authorization denials +during enumeration are predominantly get/list/watch (read) operations, which the `kube-audit-admin` category excludes. +A cluster that ships only `kube-audit-admin` is effectively blind to this rule, since only write-verb denials remain +visible. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:"kube-audit" and + azure.platformlogs.properties.log.stage:"ResponseComplete" and + azure.platformlogs.properties.log.responseStatus.code:"403" and + azure.platformlogs.properties.log.responseStatus.reason:"Forbidden" and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or + system\:serviceaccount\:kube-system\:* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-secret-get-or-list-with-suspicious-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-secret-get-or-list-with-suspicious-user-agent.asciidoc new file mode 100644 index 0000000000..2fca6ea607 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-secret-get-or-list-with-suspicious-user-agent.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-29-azure-aks-secret-get-or-list-with-suspicious-user-agent]] +=== Azure AKS Secret get or list with Suspicious User Agent + +Detects successful AKS (Azure Kubernetes Service) secret get or list operations where the user agent matches scripting runtimes (python, ruby, perl), command-line HTTP clients (curl, wget, HTTPie), or generic HTTP libraries (Go-http-client, okhttp, Apache-HttpClient, Guzzle, axios, undici) rather than typical kubectl or named controller traffic. Reading Kubernetes secrets with a generic client is a common credential-access step after a token or kubeconfig is stolen, and offensive tooling (for example peirates and kdigger) frequently reaches the API with a default Go HTTP client. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.platformlogs-* + +*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://kubernetes.io/docs/concepts/configuration/secret/ +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://unit42.paloaltonetworks.com/hildegard-malware-teamtnt/ +* https://unit42.paloaltonetworks.com/modern-kubernetes-threats/ +* https://www.sysdig.com/blog/teamtnt-kubelet-credentials +* https://github.com/kubernetes/kubernetes/issues/108726 + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Secret get or list with Suspicious User Agent* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. This rule fires when a +successful `get` or `list` against Kubernetes `secrets` is issued with a user agent that matches scripting runtimes +(python, ruby, perl), command-line HTTP clients (curl, wget, HTTPie), or generic HTTP libraries (Go-http-client, okhttp, +Apache-HttpClient, Guzzle, axios, undici) rather than typical `kubectl` or named controller traffic. The user agent is +trivially spoofable (the telemetry shows offensive tooling masquerading as `kubectl`), so this is a corroborating +indicator, not proof. + + +*Possible investigation steps* + + +- Identify the acting identity in `azure.platformlogs.properties.log.user.username` and its group memberships in + `azure.platformlogs.properties.log.user.groups`. Control-plane and node identities (`system:apiserver`, `aksService`, + `system:node:*`, `system:serviceaccount:kube-system:*`) are expected; a human or service-principal identity reading + secrets with a scripted client is not. +- Confirm the request was authorized by checking + `azure.platformlogs.properties.log.annotations.authorization.k8s.io/decision` (`allow` vs `forbid`) and the + `azure.platformlogs.properties.log.responseStatus.code`. +- Review the targeted secret via `azure.platformlogs.properties.log.objectRef.namespace` and + `azure.platformlogs.properties.log.objectRef.name`, and the exact API path in + `azure.platformlogs.properties.log.requestURI`. +- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs`. In-cluster control-plane traffic uses loopback + (`::1`) or node subnet addresses; a public or pod-network source for a secret read is more suspicious. Pivot on the + source for other API bursts, exec sessions, or RBAC changes. +- Correlate with recent Entra ID sign-ins or role assignments for the identity to determine whether the token was + recently issued or scoped unusually. + + +*False positive analysis* + + +- Approved scripts, CI jobs, or penetration tests may use generic HTTP clients. Validate identity scope before treating + as compromise. +- Internal automation using generic libraries can be excluded by stable service account after review. +- The kubelet and controllers built on client-go can default to a `Go-http-client/2.0` user agent when no custom agent + is set (see kubernetes/kubernetes#108726), so an operator or platform component reading secrets may match `Go-http*`. + Exclude the specific benign identity (for example `system:serviceaccount:kube-system:*` or a validated operator + service account) rather than removing the `Go-http*` pattern, which also catches default-user-agent offensive tooling. + + +*Response and remediation* + + +- If unauthorized, revoke the identity's tokens and kubeconfig, rotate the exposed secrets, and review RBAC that permits + secret reads. +- Hunt for downstream use of the retrieved secrets, such as new sign-ins, workload deployments, or outbound connections. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs` +data stream is required for this rule. The `kube-audit` log category is required specifically: secret get/list are +read operations, which the `kube-audit-admin` category excludes, so a cluster shipping only `kube-audit-admin` is blind +to this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:"kube-audit" and + azure.platformlogs.properties.log.responseStatus.code:("200" or "201") and + azure.platformlogs.properties.log.verb:("get" or "list") and + azure.platformlogs.properties.log.objectRef.resource:"secrets" and + azure.platformlogs.properties.log.userAgent:( + curl* or python* or Python* or wget* or Wget* or Go-http* or perl* or libwww-perl* or + java* or Java* or node* or php* or Guzzle* or Bun* or axios* or undici* or okhttp* or + Apache-HttpClient* or HTTPie* or Ruby* or PostmanRuntime* or RestSharp* or *distrib#kali* or *kali-amd64* or *kali-arm64* + ) + +---------------------------------- + +*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: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-suspicious-self-subject-review-by-service-account-or-node-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-suspicious-self-subject-review-by-service-account-or-node-identity.asciidoc new file mode 100644 index 0000000000..ddd9a1b3d7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-azure-aks-suspicious-self-subject-review-by-service-account-or-node-identity.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-29-azure-aks-suspicious-self-subject-review-by-service-account-or-node-identity]] +=== Azure AKS Suspicious Self-Subject Review by Service Account or Node Identity + +Detects AKS (Azure Kubernetes Service) service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC before privilege escalation. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.platformlogs-* + +*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://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://github.com/inguardians/peirates + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Suspicious Self-Subject Review by Service Account or Node Identity* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. A `selfsubjectaccessreviews` +or `selfsubjectrulesreviews` create lets the caller enumerate its own effective permissions. Service account and node +identities issuing these reviews outside of known controllers can indicate a stolen token mapping out what it can reach. + + +*Possible investigation steps* + + +- Confirm the acting identity in `azure.platformlogs.properties.log.user.username` and its groups in + `azure.platformlogs.properties.log.user.groups`, and whether that service account or node routinely performs + self-subject reviews. Check `azure.platformlogs.properties.log.impersonatedUser.username`: when populated, the review + was issued via impersonation (e.g. `kubectl auth can-i --as=`) and the real actor is the + impersonating user, not the service account in `user.username`. +- Review `azure.platformlogs.properties.log.objectRef.resource` (selfsubjectaccessreviews or selfsubjectrulesreviews) + and the `azure.platformlogs.properties.log.requestObject` to see what access was checked, plus the API path in + `azure.platformlogs.properties.log.requestURI`. Inspect `azure.platformlogs.properties.log.userAgent` to distinguish + interactive tooling (`kubectl`) from custom recon tooling or in-cluster SDKs. +- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs`. Control-plane and in-cluster agents use loopback + (`127.0.0.1`/`::1`) or pod-network addresses (e.g. `10.244.0.0/16`); an external caller wielding a service account + token is more suspicious. Pivot on the source for related API activity, denied requests, exec sessions, or RBAC + changes from the same identity. + + +*False positive analysis* + + +- Known observability or workflow controllers may issue self-subject reviews; extend exclusions for validated + identities. Azure Arc's agent service accounts (`system:serviceaccount:azure-arc:*`) legitimately submit these reviews + and are already excluded; add other validated platform controllers as they are baselined. +- Admin impersonation workflows can trigger this via an impersonated service account; validate the impersonating user in + `azure.platformlogs.properties.log.impersonatedUser.username`. + + +*Response and remediation* + + +- If unauthorized, revoke the service account token and review the RBAC bindings granted to it. +- Correlate with any successful privileged actions the identity performed after the review. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs` +data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft +recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). Self-subject review +creates are recorded in both categories with the same `auditID`, so clusters that enable both categories may generate +two alerts per review. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:Microsoft.ContainerService/managedClusters/diagnosticLogs/Read and + azure.platformlogs.category:(kube-audit or kube-audit-admin) and + azure.platformlogs.properties.log.stage:ResponseComplete and + azure.platformlogs.properties.log.verb:create and + azure.platformlogs.properties.log.objectRef.resource:(selfsubjectaccessreviews or selfsubjectrulesreviews) and + azure.platformlogs.properties.log.user.username:((system\:node\:* or system\:serviceaccount\:*) and + not system\:serviceaccount\:azure-arc\:*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-cassandra-javascript-udf-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-cassandra-javascript-udf-creation.asciidoc new file mode 100644 index 0000000000..6ebbc0bb88 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-cassandra-javascript-udf-creation.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-29-cassandra-javascript-udf-creation]] +=== Cassandra JavaScript UDF Creation + +Identifies Cassandra Query Language statements that create a JavaScript user-defined function. On vulnerable and dangerously configured Cassandra servers, adversaries can abuse scripted UDF creation to escape the JavaScript sandbox and execute operating-system commands, including through CVE-2021-44521. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.cassandra-* + +*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://jfrog.com/blog/cve-2021-44521-exploiting-apache-cassandra-user-defined-functions-for-remote-code-execution/ +* https://nvd.nist.gov/vuln/detail/CVE-2021-44521 +* https://attack.mitre.org/techniques/T1059/007/ + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Execution +* Data Source: Network Packet Capture +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Cassandra JavaScript UDF Creation* + + +CVE-2021-44521 allows a JavaScript UDF to escape the Nashorn sandbox when Cassandra is vulnerable and scripted UDFs are enabled with unsafe thread settings. Even on patched systems, JavaScript UDF creation is a sensitive control-plane operation that should be rare and restricted to approved administrators. + + +*Possible investigation steps* + + +- Review `client.ip`, `server.ip`, `network.community_id`, and `network_traffic.cassandra.request.query`. +- Extract the function name, keyspace, declared language, and function body. +- Look for Java interoperability, reflection, process execution, class loading, file access, or network-access strings in the UDF body. +- Confirm the Cassandra version and the values of `enable_user_defined_functions`, `enable_scripted_user_defined_functions`, and `enable_user_defined_functions_threads`. +- Correlate with Cassandra audit logs and endpoint telemetry for child processes, file creation, or outbound connections from the Cassandra service. + + +*False positive analysis* + + +- Approved application deployments may create JavaScript UDFs, though this should be uncommon. +- Scope exceptions to known deployment clients and reviewed function definitions rather than excluding UDF creation globally. + + +*Response and remediation* + + +- Terminate unauthorized sessions and isolate the Cassandra node if code execution is suspected. +- Disable scripted UDFs where they are not required and upgrade Cassandra to a version that fixes CVE-2021-44521. +- Remove unauthorized functions, rotate affected credentials, and review role permissions and cluster-wide activity. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Network Packet Capture integration with the Cassandra protocol analyzer enabled and +cleartext visibility into native CQL traffic. Prepared statements expose query text during `PREPARE`, while later +`EXECUTE` frames may not repeat it. TLS-encrypted traffic is opaque. Use Cassandra audit logs and endpoint telemetry to +confirm the database identity and execution outcome. + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "network_traffic.cassandra" and + network_traffic.cassandra.request.query like~ "*create*function*" and + network_traffic.cassandra.request.query like~ "*language*javascript*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-component-object-model-hijacking.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-component-object-model-hijacking.asciidoc new file mode 100644 index 0000000000..f997b87f8a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-component-object-model-hijacking.asciidoc @@ -0,0 +1,255 @@ +[[prebuilt-rule-8-19-29-component-object-model-hijacking]] +=== Component Object Model Hijacking + +Identifies Component Object Model (COM) hijacking via registry modification. Adversaries may establish persistence by executing malicious content triggered by hijacked references to COM objects. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* + +*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://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 121 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Component Object Model Hijacking* + + +Adversaries can insert malicious code that can be executed in place of legitimate software through hijacking the COM references and relationships as a means of persistence. + + +*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. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Retrieve the file referenced in the registry and determine if it is 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. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled task creation. + - Use the PowerShell Get-FileHash cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- Some Microsoft executables will reference the LocalServer32 registry key value for the location of external COM objects. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- 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] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + /* not necessary but good for filtering privileged installations */ + user.domain != "NT AUTHORITY" and process.executable != null and + ( + ( + registry.path : "HK*\\InprocServer32\\" and + registry.data.strings: ("scrobj.dll", "?:\\*\\scrobj.dll") and + not registry.path : "*\\{06290BD*-48AA-11D2-8432-006008C3FBFC}\\*" + ) or + + ( + registry.path : "HKLM\\*\\InProcServer32\\*" and + registry.data.strings : ("*\\Users\\*", "*\\ProgramData\\*") + ) or + + /* in general COM Registry changes on Users Hive is less noisy and worth alerting */ + ( + registry.path : ( + "HKEY_USERS\\*\\InprocServer32\\", + "HKEY_USERS\\*\\LocalServer32\\", + "HKEY_USERS\\*\\DelegateExecute", + "HKEY_USERS\\*\\TreatAs\\", + "HKEY_USERS\\*\\ScriptletURL*", + "HKEY_USERS\\*\\TypeLib*\\Win*" + ) and + not registry.data.strings : ( + /* COM related to Windows Spotlight feature */ + "{4813071a-41ad-44a2-9835-886d2f63ca30}", + + /* AppX/MSIX DelegateExecute handlers: execute, protocol, file */ + "{A56A841F-E974-45C1-8001-7E3F8A085917}", + "{4ED3A719-CEA8-4BD9-910D-E252F997AFC2}", + "{BFEC0C93-0B7D-4F2C-B09C-AFFFC4BDAE78}" + ) + ) + ) and + + not ( + process.code_signature.trusted == true and + process.code_signature.subject_name in ( + "Island Technology Inc.", "Google LLC", "Grammarly, Inc.", "Dropbox, Inc", "REFINITIV US LLC", "HP Inc.", "Adobe Inc.", + "Citrix Systems, Inc.", "Veeam Software Group GmbH", "Zhuhai Kingsoft Office Software Co., Ltd.", "Oracle America, Inc.", + "Brave Software, Inc.", "DeepL SE", "Opera Norway AS", "Thomas Braun", "Slack Technologies, LLC", "Spotify AB", + "Vivaldi Technologies AS" + ) + ) and + + /* excludes trusted applications registering their own COM components */ + not ( + process.code_signature.trusted == true and + ( + ( + process.name : "OneDrive.Sync.Service.exe" and + process.code_signature.subject_name == "Microsoft Corporation" and + registry.data.strings : ( + "*\\Microsoft\\OneDrive\\*\\OneDrive.Sync.Service.exe*", + "*\\Microsoft\\OneDrive\\*\\OneDrive.Sync.Service.dll*" + ) + ) or + ( + process.executable : "?:\\Users\\*\\AppData\\Local\\Kingsoft\\WPS Office\\*\\office6\\ksomisc.exe" and + process.code_signature.subject_name == "WPS SOFTWARE PTE. LTD." and + registry.data.strings : "*\\Kingsoft\\WPS Office\\*" + ) or + ( + process.name : "claude.exe" and + process.code_signature.subject_name == "Anthropic, PBC" and + registry.data.strings : ( + "*\\Users\\*\\AppData\\Local\\AnthropicClaude\\app-*\\claude.exe*", + "*\\ProgramData\\*\\AnthropicClaude\\app-*\\claude.exe*" + ) + ) + ) + ) and + + /* excludes Microsoft signed noisy processes */ + not + ( + process.name : ( + "OneDrive.exe", "OneDriveSetup.exe", "FileSyncConfig.exe", "Teams.exe", "MicrosoftEdgeUpdate.exe", "msrdcw.exe", + "MicrosoftEdgeUpdateComRegisterShell64.exe", "setup.exe", "PowerToys.PowerLauncher.exe" + ) and + process.code_signature.trusted == true and process.code_signature.subject_name in ("Microsoft Windows", "Microsoft Corporation") + ) and + + not process.executable : ( + "?:\\$WINDOWS.~BT\\Sources\\SetupHost.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Program Files\\*.exe", + "?:\\ProgramData\\4Team\\4Team-Updater\\4Team-Updater-Helper.exe", + "?:\\ProgramData\\Lenovo\\Udc\\Hosts\\x64\\MessagingPlugin.exe", + "?:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\*\\MsMpEng.exe", + "?:\\Users\\*\\AppData\\Local\\Wondershare\\Wondershare NativePush\\WsToastNotification.exe", + "?:\\Windows\\System32\\DriverStore\\FileRepository\\*.exe", + "?:\\Windows\\System32\\FMToastNotification.exe", + "?:\\Windows\\System32\\msiexec.exe", + "?:\\Windows\\System32\\svchost.exe", + "?:\\Windows\\SysWOW64\\regsvr32.exe", + "?:\\Windows\\System32\\regsvr32.exe", + "\\Device\\Mup\\*\\Kufer\\KuferSQL\\BasysSQL.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Component Object Model Hijacking +** ID: T1546.015 +** Reference URL: https://attack.mitre.org/techniques/T1546/015/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Component Object Model Hijacking +** ID: T1546.015 +** Reference URL: https://attack.mitre.org/techniques/T1546/015/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-connection-to-commonly-abused-web-services.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-connection-to-commonly-abused-web-services.asciidoc new file mode 100644 index 0000000000..d181e8d3c0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-connection-to-commonly-abused-web-services.asciidoc @@ -0,0 +1,404 @@ +[[prebuilt-rule-8-19-29-connection-to-commonly-abused-web-services]] +=== Connection to Commonly Abused Web Services + +Adversaries may implement command and control (C2) communications that use common web services to hide their activity. This attack technique is typically targeted at an organization and uses web services common to the victim network, which allows the adversary to blend into legitimate traffic activity. These popular services are typically targeted since they have most likely been used before compromise, which helps malicious traffic blend in. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/operation-bleeding-bear +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry +* https://specterops.io/blog/2026/01/30/weaponizing-whitelists-an-azure-blob-storage-mythic-c2-profile/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: SentinelOne + +*Version*: 132 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Connection to Commonly Abused Web Services* + + +Adversaries may use an existing, legitimate external Web service as a means for relaying data to/from a compromised system. Popular websites and social media acting as a mechanism for C2 may give a significant amount of cover due to the likelihood that hosts within a network are already communicating with them prior to a compromise. + +This rule looks for processes outside known legitimate program locations communicating with a list of services that can be abused for exfiltration or command and control. + +> **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. +- 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"}} +- Verify whether the digital signature exists in the executable. +- Identify the operation type (upload, download, tunneling, etc.). +- 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`. + - !{investigate{"label":"Investigate the Subject Process Network Events","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","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. + + +*False positive analysis* + + +- This rule has a high chance to produce false positives because it detects communication with legitimate services. Noisy false positives can be added as exceptions. + + +*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/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type == "windows" and + dns.question.name != null and process.name != null and + not (?user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") or user.domain == "NT AUTHORITY") and + /* Add new WebSvc domains here */ + dns.question.name : + ( + "raw.githubusercontent.*", + "pastebin.*", + "paste4btc.com", + "paste.ee", + "ghostbin.com", + "drive.google.com", + "?.docs.live.net", + "api.dropboxapi.*", + "content.dropboxapi.*", + "dl.dropboxusercontent.*", + "api.onedrive.com", + "*.onedrive.org", + "onedrive.live.com", + "filebin.net", + "*.ngrok.io", + "ngrok.com", + "*.portmap.*", + "*serveo.net", + "*localtunnel.me", + "*pagekite.me", + "*localxpose.io", + "*notabug.org", + "rawcdn.githack.*", + "paste.nrecom.net", + "zerobin.net", + "controlc.com", + "requestbin.net", + "slack.com", + "api.slack.com", + "slack-redir.net", + "slack-files.com", + "cdn.discordapp.com", + "discordapp.com", + "discord.com", + "apis.azureedge.net", + "cdn.sql.gg", + "?.top4top.io", + "top4top.io", + "www.uplooder.net", + "*.cdnmegafiles.com", + "transfer.sh", + "gofile.io", + "updates.peer2profit.com", + "api.telegram.org", + "t.me", + "meacz.gq", + "rwrd.org", + "*.publicvm.com", + "*.blogspot.com", + "api.mylnikov.org", + "file.io", + "stackoverflow.com", + "*files.1drv.com", + "api.anonfile.com", + "*hosting-profi.de", + "ipbase.com", + "ipfs.io", + "*up.freeo*.space", + "api.mylnikov.org", + "script.google.com", + "script.googleusercontent.com", + "api.notion.com", + "graph.microsoft.com", + "*.sharepoint.com", + "mbasic.facebook.com", + "login.live.com", + "api.gofile.io", + "api.anonfiles.com", + "api.notion.com", + "api.trello.com", + "gist.githubusercontent.com", + "files.pythonhosted.org", + "g.live.com", + "*.zulipchat.com", + "webhook.site", + "run.mocky.io", + "mockbin.org", + "*googleapis.com", + "global.rel.tunnels.api.visualstudio.com", + "*.devtunnels.ms", + "api.github.com", + "*.blob.core.windows.net", + "*.blob.storage.azure.net", + "files.catbox.moe", + "*.supabase.co", + "*.elastic-cloud.com", + "*.cloud.es.io", + "*icp0.io") and + + /* Insert noisy false positives here */ + not ( + ( + process.executable : ( + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\*\\MsMpEng.exe", + "?:\\Users\\*\\AppData\\Local\\BraveSoftware\\*\\Application\\brave.exe", + "?:\\Users\\*\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe", + "?:\\Users\\*\\AppData\\Local\\Microsoft\\OneDrive\\OneDrive.exe", + "?:\\Users\\*\\AppData\\Local\\Programs\\Opera*\\opera.exe", + "?:\\Users\\*\\AppData\\Local\\Programs\\Fiddler\\Fiddler.exe", + "?:\\Users\\*\\AppData\\Local\\PowerToys\\PowerToys.exe", + "?:\\Users\\*\\AppData\\Local\\Vivaldi\\Application\\vivaldi.exe", + "?:\\Users\\*\\AppData\\Local\\Zen Browser\\zen.exe", + "?:\\Users\\*\\Wavesor Software\\WaveBrowser\\wavebrowser.exe", + "?:\\Windows\\System32\\MicrosoftEdgeCP.exe", + "?:\\Windows\\system32\\mobsync.exe", + "?:\\Windows\\SysWOW64\\mobsync.exe", + "?:\\Windows\\system32\\svchost.exe", + "?:\\Windows\\System32\\smartscreen.exe", + "?:\\Windows\\System32\\wsl.exe", + "?:\\Windows\\System32\\WWAHost.exe" + ) + ) or + + /* Discord App */ + (process.name : "Discord.exe" and (process.code_signature.subject_name : "Discord Inc." and + process.code_signature.trusted == true) and dns.question.name : ("discord.com", "cdn.discordapp.com", "discordapp.com") + ) or + + /* MS Sharepoint / OneDrive */ + (process.name : ("Microsoft.SharePoint.exe", "OneDrive.Sync.Service.exe") and dns.question.name : "onedrive.live.com" and + (process.code_signature.subject_name : "Microsoft Corporation" and process.code_signature.trusted == true) + ) or + + /* Obsidian - Plugins are stored on raw.githubusercontent.com */ + (process.name : "Obsidian.exe" and (process.code_signature.subject_name : "Dynalist Inc" and + process.code_signature.trusted == true) and dns.question.name : "raw.githubusercontent.com" + ) or + + /* WebExperienceHostApp */ + (process.name : "WebExperienceHostApp.exe" and (process.code_signature.subject_name : "Microsoft Windows" and + process.code_signature.trusted == true) and dns.question.name : ("onedrive.live.com", "skyapi.onedrive.live.com") + ) or + + /* IntelliJ IDEA connecting to raw.githubusercontent.com */ + (process.code_signature.subject_name : "JetBrains s.r.o." and + process.code_signature.trusted == true and dns.question.name : ("api.github.com", "raw.githubusercontent.com") + ) or + + (process.code_signature.subject_name : "Microsoft *" and process.code_signature.trusted == true and + dns.question.name : ("*.sharepoint.com", "graph.microsoft.com", "g.live.com", "login.live.com", + "*.blob.core.windows.net", "*.blob.storage.azure.net", "*.googleapis.com") + ) or + + (process.code_signature.subject_name : ("Python Software Foundation", "Anaconda, Inc.") and + process.code_signature.trusted == true and dns.question.name : "files.pythonhosted.org" + ) or + + /* Zoom */ + (process.name : "Zoom.exe" and ( + process.code_signature.subject_name : ("Zoom Video Communications, Inc.", "Zoom Communications, Inc.") and + process.code_signature.trusted == true) and dns.question.name : ("*.googleapis.com", "graph.microsoft.com", "*.blob.core.windows.net") + ) or + + /* VSCode */ + (process.name : "Code.exe" and (process.code_signature.subject_name : "Microsoft Corporation" and + process.code_signature.trusted == true) and dns.question.name : ("api.github.com", "raw.githubusercontent.com", + "*.googleapis.com", "files.pythonhosted.org") + ) or + + /* Terraform */ + (process.name : "terraform-provider*.exe" and (process.code_signature.subject_name : "HashiCorp, Inc." and + process.code_signature.trusted == true) and dns.question.name : "graph.microsoft.com" + ) or + + /* Telegram */ + (process.name : "Telegram.exe" and (process.code_signature.subject_name : "Telegram FZ-LLC" and + process.code_signature.trusted == true) and dns.question.name : "*.googleapis.com" + ) or + + ( + process.code_signature.trusted == true and + process.code_signature.subject_name : ( + "Johannes Schindelin", + "Redis Inc.", + "Slack Technologies, LLC", + "Cisco Systems, Inc.", + "Dropbox, Inc", + "Amazon.com Services LLC", + "Island Technology Inc.", + "GitHub, Inc.", + "Red Hat, Inc", + "Mozilla Corporation", + "Spotify AB", + "DeepL SE", + "Google LLC", + "Anthropic, PBC", + "OpenAI OpCo, LLC", + "Anysphere, Inc.", + "PERPLEXITY AI, INC." + ) + ) + ) + +---------------------------------- + +*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: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Sub-technique: +** Name: External Proxy +** ID: T1090.002 +** Reference URL: https://attack.mitre.org/techniques/T1090/002/ +* 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/ +* Technique: +** Name: Dynamic Resolution +** ID: T1568 +** Reference URL: https://attack.mitre.org/techniques/T1568/ +* Sub-technique: +** Name: Domain Generation Algorithms +** ID: T1568.002 +** Reference URL: https://attack.mitre.org/techniques/T1568/002/ +* 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 Code Repository +** ID: T1567.001 +** Reference URL: https://attack.mitre.org/techniques/T1567/001/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-correlated-alerts-on-similar-user-identities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-correlated-alerts-on-similar-user-identities.asciidoc new file mode 100644 index 0000000000..c00dbaba98 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-correlated-alerts-on-similar-user-identities.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-29-correlated-alerts-on-similar-user-identities]] +=== Correlated Alerts on Similar User Identities + +This rule correlates alerts from multiple integrations and event categories that involve different user.name values which may represent the same real-world identity. It uses an LLM-based similarity analysis to evaluate whether multiple user identifiers (e.g. naming variations, formats, aliases, or domain differences) likely belong to the same person. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/query-languages/esql/esql-commands#esql-completion +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: Identity +* Domain: LLM +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Resources: LLM +* Rule Type: Higher-Order Rule + +*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, analysts should validate findings against their environment and identity architecture. + + +*Investigating Correlated Alerts on Similar User Identities* + + +This rule identifies alerts from multiple integrations and event categories involving different `user.name` values that may represent the same real-world identity. +An LLM is used to assess string similarity and naming patterns to determine whether multiple user identifiers likely belong to the same person, which may indicate account compromise, credential abuse, or identity misuse across systems. + + +*Possible investigation steps* + + +- Review the correlated `user.name` values and validate whether they represent naming variations, aliases, or identity mappings. +- Examine the LLM output fields (`verdict`, `confidence`, `summary`) as decision support, not ground truth. +- Analyze the diversity of alert sources, event categories, and detection rules involved. +- Reconstruct the alert timeline to identify potential stages such as initial access, lateral movement, privilege escalation, or persistence. +- Correlate with authentication logs, IAM/SSO telemetry, EDR data, and network logs to identify shared sessions, IPs, devices, or hosts. +- Validate identities against directory services, identity providers, and federation mappings. + + +*False positive analysis* + + +- Identity format variations across systems (e.g., `first.last`, `flast`, `user@domain`). +- Federated identity mappings between on-prem, cloud, and SaaS platforms. +- Service, automation, and CI/CD accounts with similar naming conventions. +- Separate admin and standard user accounts for the same individual. +- Shared credentials or naming templates in development and test environments. + + +*Response and remediation* + + +- Temporarily disable or suspend correlated accounts if compromise is suspected. +- Revoke active sessions, tokens, and credentials. +- Investigate access scope, privileges, and lateral movement paths. +- Perform endpoint and identity forensics to identify persistence mechanisms. +- Remediate IAM misconfigurations and federation issues. +- Enhance monitoring for identity correlation, credential misuse, and cross-platform abuse.. + +==== Setup + + + +*Setup* + + + +*LLM Configuration* + + +This rule uses the ES|QL COMPLETION command with Elastic's managed General Purpose LLM v2 (`.gp-llm-v2-completion`), +which is available out-of-the-box in Elastic Cloud deployments with an appropriate subscription. + +To use a different LLM provider (Azure OpenAI, Amazon Bedrock, OpenAI, or Google Vertex), configure a connector +following the https://www.elastic.co/docs/explore-analyze/ai-features/llm-guides/llm-connectors[LLM connector documentation] +and update the `inference_id` parameter in the query to reference your configured connector. + + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* + +// truncate timestamp to 5-minute window +| eval Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp) + +// high severity alerts excluding system standard user.ids +| where kibana.alert.rule.name is not null and user.name is not null and kibana.alert.risk_score >= 73 and kibana.alert.workflow_status == "open" and + not kibana.alert.rule.type in ("threat_match", "machine_learning") and + not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0") + +// group alerts by short time window and extract values of interest for alert triage +| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module), + Esql.user_name_distinct_count = COUNT_DISTINCT(user.name), + Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.event_category_distinct_count = COUNT_DISTINCT(event.category), + Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score), + Esql.event_module_values = VALUES(event.module), + Esql.rule_name_values = VALUES(kibana.alert.rule.name), + Esql.message_values = VALUES(message), + Esql.event_category_values = VALUES(event.category), + Esql.event_action_values = VALUES(event.action), + Esql.source_ip_values = VALUES(source.ip), + Esql.destination_ip_values = VALUES(destination.ip), + Esql.host_id_values = VALUES(host.id), + Esql.agent_id_values = VALUES(agent.id), + Esql.rule_severity_values = VALUES(kibana.alert.risk_score), + Esql.user_name_values = VALUES(user.name) by Esql.time_window_date_trunc + +// filter for alerts from different integrations with unique categories +| where Esql.event_module_distinct_count >= 2 and Esql.user_name_distinct_count >= 2 and Esql.event_category_distinct_count >= 2 + +// build context for LLM analysis +| eval users_list = MV_CONCAT(Esql.user_name_values, ",") + +// LLM analysis +| eval instructions = "Analyze the provided user names and return a boolean value true if at least 2 of them are similar and they may belong to the same human identify or false if not, do not compare user names that may look like service accounts. If the list of users has more than 2 users and only 2 of them are similar consider this as true. Structure the output as follows: verdict= confidence= summary= without any other response statements on a single line." +| eval prompt = CONCAT("User identities extracted from different alerts: ", users_list, instructions) +| COMPLETION triage_result = prompt WITH { "inference_id": ".gp-llm-v2-completion"} + +// parse LLM response +| DISSECT triage_result """verdict=%{Esql.verdict} confidence=%{Esql.confidence} summary=%{Esql.summary}""" + +// filter for similar user values +| where TO_LOWER(Esql.verdict) == "true" +| keep Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-direct-process-execution-via-background-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-direct-process-execution-via-background-utility.asciidoc new file mode 100644 index 0000000000..7347b0b006 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-direct-process-execution-via-background-utility.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-29-direct-process-execution-via-background-utility]] +=== Direct Process Execution via Background Utility + +This is a New Terms rule that identifies the first occurrence of setsid or nohup being used to directly execute a process on a host. Attackers may leverage these tools to execute commands in a new session and/or to ignore signals. + +*Rule type*: new_terms + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/disrupting-gridtide-global-espionage-campaign?hl=en + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: SentinelOne +* Data Source: Auditd Manager +* 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 Direct Process Execution via Background Utility* + + +This rule flags the first time a Linux host uses setsid, nohup, or disown to launch another process directly, which often means someone is detaching execution from the current terminal or login session. Attackers commonly use nohup to start a backdoor, reverse shell, or cryptominer after SSH access so the process keeps running after they disconnect and ignores normal hangup signals. + + +*Possible investigation steps* + + +- Review the child process launched by the utility, including its full command line, executable path, working directory, and any redirected output files, to quickly separate routine administration from suspicious payload execution. +- Trace the full ancestry and session context around the launch, such as an interactive shell, SSH login, sudo elevation, script runner, or service account, to determine whether the execution came from an expected workflow or an unusual entry point. +- Assess the user and host history for similar behavior by checking recent logins, shell history, and prior detached launches on the same asset or by the same account, since a first-seen event from a normally quiet user often increases concern. +- Inspect immediate follow-on activity from the spawned process, especially outbound network connections, file downloads, child process creation, or persistence changes, because detached execution is commonly used to keep malicious tooling running after logout. +- Confirm with the system owner whether the command aligns with approved long-running tasks such as maintenance, backups, or software updates, and if not, preserve the binary and related artifacts for deeper analysis and potential containment. + + +*False positive analysis* + + +- A Linux administrator may legitimately use nohup or setsid to launch an approved maintenance, backup, or data-processing script from an interactive shell so it continues after logout; verify the child command, executable path, initiating user, and execution time match expected operational activity on that host. +- An engineer troubleshooting or restarting a local application may detach the process with setsid during a remote session to avoid terminal interruption; verify the parent shell and account are authorized and that the spawned binary or script and working directory align with the host's normal application files. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network, terminate the detached child process started with `nohup`, `setsid`, or `disown` and any descendants, and preserve the executable, shell script, redirected output files, and shell history for evidence. +- Remove attacker persistence by deleting malicious cron jobs, systemd service or timer units, `rc.local` or shell profile modifications, unauthorized `authorized_keys` entries, and any dropped binaries or scripts referenced by the detached command. +- Reset compromised access by disabling or rotating credentials for the initiating account and any accounts used afterward, revoking active SSH sessions and tokens, and reviewing `sudoers`, newly added local users, and group memberships for unauthorized changes. +- Rebuild the host from a known-good image or restore from a trusted backup if the detached process ran a backdoor, reverse shell, downloader, or altered system binaries, and verify only approved packages, services, and startup items remain before returning it to production. +- Escalate to incident response immediately if the detached process contacted an external command-and-control address, executed from a writable temporary or home directory as root, spread to other hosts, or evidence shows credential theft or persistence beyond the original system. +- Harden the environment by restricting interactive use of backgrounding utilities where not required, tightening SSH and `sudo` access, enforcing application allowlisting and least privilege, and adding detections for detached launches from temporary directories, user home directories, and unexpected service accounts. + + + +==== 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] +---------------------------------- +host.os.type:linux and event.category:process and +event.action:("exec" or "exec_event" or "executed" or "process_started" or "start") and +process.name:("setsid" or "nohup" or "disown") and process.args_count:2 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: 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: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-emond-rules-creation-or-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-emond-rules-creation-or-modification.asciidoc new file mode 100644 index 0000000000..14a72453fa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-emond-rules-creation-or-modification.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-29-emond-rules-creation-or-modification]] +=== Emond Rules Creation or Modification + +Identifies the creation or modification of the Event Monitor Daemon (emond) rules. Adversaries may abuse this service by writing a rule to execute commands when a defined event occurs, such as system start up or user authentication. + +*Rule type*: eql + +*Rule indices*: + +* 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*: + +* https://www.xorrior.com/emond-persistence/ +* https://www.sentinelone.com/blog/how-malware-persists-on-macos/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 114 + +*Rule authors*: + +* Elastic +* Massimo Bertocchi + +*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 Emond Rules Creation or Modification* + + +The Event Monitor Daemon (emond) on macOS is a service that executes commands based on specific system events. Adversaries can exploit this by crafting rules to trigger malicious actions during events like startup or login. The detection rule monitors for new or altered emond rule files, signaling potential unauthorized modifications that could indicate persistence tactics. + + +*Possible investigation steps* + + +- Review the file path of the modified or newly created emond rule to determine if it matches known legitimate configurations or if it appears suspicious, focusing on paths like "/private/etc/emond.d/rules/*.plist" and "/private/var/db/emondClients/*". +- Check the timestamp of the file creation or modification to correlate with any known user activity or scheduled tasks that could explain the change. +- Analyze the contents of the modified or newly created plist file to identify any commands or scripts that are set to execute, looking for signs of malicious intent or unauthorized actions. +- Investigate the user account associated with the file modification event to determine if the activity aligns with their typical behavior or if it suggests potential compromise. +- Cross-reference the event with other security alerts or logs from the same timeframe to identify any related suspicious activities or patterns that could indicate a broader attack. + + +*False positive analysis* + + +- System or application updates may modify emond rule files as part of legitimate maintenance activities. Users can create exceptions for known update processes by identifying the associated process names or hashes and excluding them from alerts. +- Administrative tasks performed by IT personnel, such as configuring new system policies or settings, might involve legitimate changes to emond rules. To handle these, maintain a list of authorized personnel and their activities, and exclude these from triggering alerts. +- Security software or management tools that automate system configurations could also modify emond rules. Identify these tools and their expected behaviors, and configure exceptions based on their typical file paths or process identifiers. +- Scheduled maintenance scripts that interact with emond rules for system health checks or optimizations should be documented. Exclude these scripts by verifying their signatures or paths to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further execution of malicious rules. +- Review and back up the current emond rule files located in the specified directories to understand the scope of modifications and preserve evidence for further analysis. +- Remove or revert any unauthorized or suspicious emond rule files to their original state to stop any malicious actions triggered by these rules. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malware or persistence mechanisms. +- Restore the system from a known good backup if the integrity of the system is in question and unauthorized changes cannot be fully reversed. +- Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected by similar unauthorized emond rule modifications. +- Implement enhanced monitoring and alerting for changes to emond rule files to quickly detect and respond to future unauthorized modifications. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.action == "modification" and + file.path like ("/private/etc/emond.d/rules/*.plist", "/etc/emond.d/rules/*.plist", "/private/var/db/emondClients/*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Emond +** ID: T1546.014 +** Reference URL: https://attack.mitre.org/techniques/T1546/014/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Emond +** ID: T1546.014 +** Reference URL: https://attack.mitre.org/techniques/T1546/014/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-entra-id-high-risk-sign-in.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-entra-id-high-risk-sign-in.asciidoc new file mode 100644 index 0000000000..324c462172 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-entra-id-high-risk-sign-in.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-29-entra-id-high-risk-sign-in]] +=== Entra ID High Risk Sign-in + +Identifies high risk Microsoft Entra ID sign-ins by leveraging Microsoft's Identity Protection machine learning and heuristics. Identity Protection categorizes risk into three tiers: low, medium, and high. While Microsoft does not provide specific details about how risk is calculated, each level brings higher confidence that the user or sign-in is compromised. + +*Rule type*: query + +*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://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/overview-identity-protection +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Initial Access + +*Version*: 112 + +*Rule authors*: + +* Elastic +* Willem D'Haese + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID High Risk Sign-in* + + +This rule detects high-risk sign-ins in Microsoft Entra ID as identified by Identity Protection. These sign-ins are flagged with a risk level of `high` during the authentication process, indicating a strong likelihood of compromise based on Microsoft's machine learning and heuristics. This alert is valuable for identifying accounts under active attack or compromise using valid credentials. + + +*Possible investigation steps* + + +- Review the `azure.signinlogs.properties.user_id` and associated identity fields to determine the impacted user. +- Inspect the `risk_level_during_signin` field and confirm it is set to `high`. If `risk_level_aggregated` is also present and high, this suggests sustained risk across multiple sign-ins. +- Check `source.ip`, `source.geo.country_name`, and `source.as.organization.name` to evaluate the origin of the sign-in attempt. Flag unexpected geolocations or ASNs (e.g., anonymizers or residential ISPs). +- Review the `device_detail` fields such as `operating_system` and `browser` for new or unrecognized devices. +- Validate the `client_app_used` (e.g., legacy protocols, desktop clients) and `app_display_name` (e.g., Office 365 Exchange Online) to assess if risky legacy methods were involved. +- Examine `applied_conditional_access_policies` to verify if MFA or blocking policies were triggered or bypassed. +- Check `authentication_details.authentication_method` to see if multi-factor authentication was satisfied (e.g., "Mobile app notification"). +- Correlate this activity with other alerts or sign-ins from the same account within the last 24–48 hours. +- Contact the user to confirm if the sign-in was expected. If not, treat the account as compromised and proceed with containment. + + +*False positive analysis* + + +- Risky sign-ins may be triggered during legitimate travel, VPN use, or remote work scenarios from unusual locations. +- In some cases, users switching devices or networks rapidly may trigger high-risk scores. +- Automated scanners or penetration tests using known credentials may mimic high-risk login behavior. +- Confirm whether the risk was remediated automatically by Microsoft Identity Protection before proceeding with escalations. + + +*Response and remediation* + + +- If compromise is suspected, immediately disable the user account and revoke active sessions and tokens. +- Initiate credential reset and ensure multi-factor authentication is enforced. +- Review audit logs and sign-in history for the account to assess lateral movement or data access post sign-in. +- Inspect activity on services such as Exchange, SharePoint, or Azure resources to understand the impact. +- Determine if the attacker leveraged other accounts or escalated privileges. +- Use the incident findings to refine conditional access policies, such as enforcing MFA for high-risk sign-ins or blocking legacy protocols. +- Review and tighten policies that allow sign-ins from high-risk geographies or unknown devices. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.signinlogs and + ( + azure.signinlogs.properties.risk_level_during_signin:high or + azure.signinlogs.properties.risk_level_aggregated:high + ) and + not (event.outcome:failure and azure.signinlogs.properties.risk_level_aggregated:none and azure.signinlogs.properties.risk_state:none) and + not azure.signinlogs.properties.risk_state:(dismissed or confirmedSafe) + +---------------------------------- + +*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-29/prebuilt-rule-8-19-29-entra-id-user-sign-in-with-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-entra-id-user-sign-in-with-unusual-client.asciidoc new file mode 100644 index 0000000000..6511b823b5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-entra-id-user-sign-in-with-unusual-client.asciidoc @@ -0,0 +1,231 @@ +[[prebuilt-rule-8-19-29-entra-id-user-sign-in-with-unusual-client]] +=== Entra ID User Sign-in with Unusual Client + +Detects rare non-interactive sign-ins where an Entra ID client application authenticates on behalf of a principal user using an application (client) ID that is not commonly associated with that user's historical sign-in behavior. Adversaries with stolen credentials or OAuth tokens may abuse Entra ID–managed or first-party client IDs to perform on-behalf-of (OBO) authentication, blending into legitimate cloud traffic while avoiding traditional interactive sign-in flows. This technique is commonly observed in OAuth phishing, token theft, and access broker operations, and may precede lateral movement, persistence, or data access via Microsoft Graph or other cloud resources. The rule uses a New Terms approach to identify first-seen combinations of the UPN and Client ID within a defined history window, helping surface unexpected client usage that may indicate compromised identities, malicious automation, or unauthorized application impersonation. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* 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://securityscorecard.com/wp-content/uploads/2025/02/MassiveBotnet-Report_022125_03.pdf + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-in +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID User Sign-in with Unusual Client* + + +This rule identifies rare Azure Entra apps IDs requesting authentication on-behalf-of a principal user. An adversary with stolen credentials may specify an Azure-managed app ID to authenticate on-behalf-of a user. This is a rare event and may indicate an attempt to bypass conditional access policies (CAP) and multi-factor authentication (MFA) requirements. The app ID specified may not be commonly used by the user based on their historical sign-in activity. + + +*Possible investigation steps* + + +- Identify the source IP address from which the failed login attempts originated by reviewing `source.ip`. Determine if the IP is associated with known malicious activity using threat intelligence sources or if it belongs to a corporate VPN, proxy, or automation process. +- Analyze affected user accounts by reviewing `azure.signinlogs.properties.user_principal_name` to determine if they belong to privileged roles or high-value users. Look for patterns indicating multiple failed attempts across different users, which could suggest a password spraying attempt. +- Examine the authentication method used in `azure.signinlogs.properties.authentication_details` to identify which authentication protocols were attempted and why they failed. Legacy authentication methods may be more susceptible to brute-force attacks. +- Review the authentication error codes found in `azure.signinlogs.properties.status.error_code` to understand why the login attempts failed. Common errors include `50126` for invalid credentials, `50053` for account lockouts, `50055` for expired passwords, and `50056` for users without a password. +- Correlate failed logins with other sign-in activity by looking at `event.outcome`. Identify if there were any successful logins from the same user shortly after multiple failures or if there are different geolocations or device fingerprints associated with the same account. +- Review `azure.signinlogs.properties.app_id` to identify which applications were initiating the authentication attempts. Determine if these applications are Microsoft-owned, third-party, or custom applications and if they are authorized to access the resources. +- Check for any conditional access policies that may have been triggered by the failed login attempts by reviewing `azure.signinlogs.properties.authentication_requirement`. This can help identify if the failed attempts were due to policy enforcement or misconfiguration. + + +*False positive analysis* + + +- Automated scripts or applications using non-interactive authentication may trigger this detection, particularly if they rely on legacy authentication protocols recorded in `azure.signinlogs.properties.authentication_protocol`. +- Corporate proxies or VPNs may cause multiple users to authenticate from the same IP, appearing as repeated failed attempts under `source.ip`. +- User account lockouts from forgotten passwords or misconfigured applications may show multiple authentication failures in `azure.signinlogs.properties.status.error_code`. +- Exclude known trusted IPs, such as corporate infrastructure, from alerts by filtering `source.ip`. +- Exclude known custom applications from `azure.signinlogs.properties.app_id` that are authorized to use non-interactive authentication. +- Ignore principals with a history of failed logins due to legitimate reasons, such as expired passwords or account lockouts, by filtering `azure.signinlogs.properties.user_principal_name`. +- Correlate sign-in failures with password reset events or normal user behavior before triggering an alert. + + +*Response and remediation* + + +- Block the source IP address in `source.ip` if determined to be malicious. +- Reset passwords for all affected user accounts listed in `azure.signinlogs.properties.user_principal_name` and enforce stronger password policies. +- Ensure basic authentication is disabled for all applications using legacy authentication protocols listed in `azure.signinlogs.properties.authentication_protocol`. +- Enable multi-factor authentication (MFA) for impacted accounts to mitigate credential-based attacks. +- Review conditional access policies to ensure they are correctly configured to block unauthorized access attempts recorded in `azure.signinlogs.properties.authentication_requirement`. +- Review Conditional Access policies to enforce risk-based authentication and block unauthorized access attempts recorded in `azure.signinlogs.properties.authentication_requirement`. +- Implement a zero-trust security model by enforcing least privilege access and continuous authentication. +- Regularly review and update conditional access policies to ensure they are effective against evolving threats. +- Restrict the use of legacy authentication protocols by disabling authentication methods listed in `azure.signinlogs.properties.client_app_used`. +- Regularly audit authentication logs in `azure.signinlogs` to detect abnormal login behavior and ensure early detection of potential attacks. +- Regularly rotate client credentials and secrets for applications using non-interactive authentication to reduce the risk of credential theft. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and event.category: "authentication" + and azure.signinlogs.properties.is_interactive: false + and azure.signinlogs.properties.user_type: "Member" + and not azure.signinlogs.properties.client_app_used: "Browser" + and not source.as.organization.name: "MICROSOFT-CORP-MSN-AS-BLOCK" + and not azure.signinlogs.properties.app_id: ( + "1b3c667f-cde3-4090-b60b-3d2abd0117f0" or + "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or + "4b0964e4-58f1-47f4-a552-e2e1fc56dcd7" or + "ecd6b820-32c2-49b6-98a6-444530e5a77a" or + "268761a2-03f3-40df-8a8b-c3db24145b6b" or + "fc0f3af4-6835-4174-b806-f7db311fd2f3" or + "de50c81f-5f80-4771-b66b-cebd28ccdfc1" or + "ab9b8c07-8f02-4f72-87fa-80105867a763" or + "6f7e0f60-9401-4f5b-98e2-cf15bd5fd5e3" or + "d7b530a4-7680-4c23-a8bf-c52c121d2e87" or + "52c2e0b5-c7b6-4d11-a89c-21e42bcec444" or + "38aa3b87-a06d-4817-b275-7a316988d93b" or + "27922004-5251-4030-b22d-91ecd9a37ea4" or + "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223" or + "cab96880-db5b-4e15-90a7-f3f1d62ffe39" or + "3a4d129e-7f50-4e0d-a7fd-033add0a29f4" or + "29d9ed98-a469-4536-ade2-f981bc1d605e" or + "c0ab8ce9-e9a0-42e7-b064-33d422df41f1" or + "9ea1ad79-fdb6-4f9a-8bc3-2b70f96e34c7" or + "4813382a-8fa7-425e-ab75-3b753aab3abb" or + "08e18876-6177-487e-b8b5-cf950c1e598c" or + "0ec893e0-5785-4de6-99da-4ed124e5296c" or + "d3590ed6-52b3-4102-aeff-aad2292ab01c" or + "0dc2408a-bbc0-4238-871e-13b372f0200f" or + "af124e86-4e96-495a-b70a-90f90ab96707" or + "e9c51622-460d-4d3d-952d-966a5b1da34c" or + "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34" or + "e2ef5054-0287-4db6-afa3-013d96881fd3" or + "82864fa0-ed49-4711-8395-a0e6003dca1f" or + "60c8bde5-3167-4f92-8fdb-059f6176dc0f" or + "5d661950-3475-41cd-a2c3-d671a3162bc1" or + "145fc680-eb72-4bcf-b4d5-8277021a1ce8" or + "c1c74fed-04c9-4704-80dc-9f79a2e515cb" or + "a2760c41-63c9-42b5-8d58-bfa1fd9e2eb3" or + "6dec647e-42c4-45a6-8f13-e8250d34e033" or + "c98e5057-edde-4666-b301-186a01b4dc58" or + "0a31c71e-0abf-4238-add7-b1a24c165dc1" or + "a8759234-4b8b-4d94-8c0a-ee1ab73af270" or + "dae89220-69ba-4957-a77a-47b78695e883" or + "fd5f78f6-a28f-450b-abc7-777f3dbbfcba" or + "821caec6-bec3-4542-bead-d3c5fb6b4ef0" or + "a40d7d7d-59aa-447e-a655-679a4107e548" or + "bed12bc0-3a62-470d-998c-e47546e7b039" or + "f4060917-6abe-40d7-baa6-f634c0eda4ac" or + "b26aadf8-566f-4478-926f-589f601d9c74" or + "1f7f6f43-2f81-429c-8499-293566d0ab0c" or + "75f31797-37c9-498e-8dc9-53c16a36afca" or + "3e050dd7-7815-46a0-8263-b73168a42c10" or + "243c63a3-247d-41c5-9d83-7788c43f1c43" or + "75efb5bc-18a1-4e7b-8a66-2ad2503d79c6" or + "d32f3b53-b7d7-48df-8d0f-f8bf233b3f1f" or + "95de633a-083e-42f5-b444-a4295d8e9314" or + "3ff8e6ba-7dc3-4e9e-ba40-ee12b60d6d48" or + "871c010f-5e61-4fb1-83ac-98610a7e9110" or + "3e62f81e-590b-425b-9531-cad6683656cf" or + "8ec6bc83-69c8-4392-8f08-b3c986009232" or + "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0" or + "dd762716-544d-4aeb-a526-687b73838a22" or + "7f8f922d-7ee4-40a6-b435-aad8b84ebde0" or + "f8d98a96-0999-43f5-8af3-69971c7bb423" or + "aa580612-c342-4ace-9055-8edee43ccb89" or + "7f67af8a-fedc-4b08-8b4e-37c4d127b6cf" or + "00bf137d-f689-4c5d-83d9-7fc31904a7ea" or + "ceb96695-e468-48ba-ba21-35e2a242d396" or + "7fba38f4-ec1f-458d-906c-f4e3c4f41335" or + "a2a1fecc-b06e-4a1e-95c1-2afd94bcadff" or + "15ddab63-ba81-45db-9bb6-6f8bc445c459" or + "bc59ab01-8403-45c6-8796-ac3ef710b3e3" or + "00000003-0000-0ff1-ce00-000000000000" or + "4e291c71-d680-4d0e-9640-0a3358e31177" or + "4fb5cc57-dbbc-4cdc-9595-748adff5f414" or + "22098786-6e16-43cc-a27d-191a01a1e3b5" or + "ebde7daf-df42-4ade-81a4-d67b339b49e9" or + "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12" or + "a672d62c-fc7b-4e81-a576-e60dc46e951d" or + "0b1df6d3-2deb-44d4-b44b-7101937e0726" or + "04f0c124-f2bc-4f59-8241-bf6df9866bbd" or + "86f4c005-6582-4559-b6cf-8b3111236736" or + "a0a3c1d3-7b82-4010-bdb0-e7048fb8f1fe" or + "a187e399-0c36-4b98-8f04-1edc167a0996" or + "2d4d3d8e-2be3-4bef-9f87-7875a61c29de" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-external-ip-address-discovery-via-curl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-external-ip-address-discovery-via-curl.asciidoc new file mode 100644 index 0000000000..570bddfe3f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-external-ip-address-discovery-via-curl.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-29-external-ip-address-discovery-via-curl]] +=== External IP Address Discovery via Curl + +Detects applications making a curl request to a known public IP address lookup web service. Malware commonly performs this action during reconnaissance to assess potential targets and identify the victim's external IP address. + +*Rule type*: eql + +*Rule indices*: + +* 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*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic +* Massimo Bertocchi + +*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 External IP Address Discovery via Curl* + + +This rule detects macOS processes launching curl (or nscurl) to query common public “what is my IP” and geolocation services, often from unusual parent applications or untrusted/unsigned code. Attackers use this to learn the victim’s outward-facing address and network context to guide follow-on targeting, routing, or staging decisions. A typical pattern is a script or dropped binary spawning curl with a short command that hits ipify/ipinfo/ifconfig-style endpoints immediately after execution. + + +*Possible investigation steps* + + +- Review the full process tree and timeline around the curl execution to identify the initiating app/script, preceding download or execution activity, and any rapid follow-on discovery or persistence commands. +- Examine the curl/nscurl command line and stdout/stderr capture (if available) to confirm the external-IP lookup intent and whether results were written to disk, environment variables, or passed to subsequent processes. +- Correlate with network telemetry for the same host and time window to verify the outbound connection, destination IP/ASN, DNS resolution, TLS/SNI details, and any additional unexpected egress to non-lookup infrastructure. +- Validate the provenance of the parent executable by checking its path, quarantine/notarization status, signature trust, and recent file creation/modification events to assess whether it was dropped or launched from a user-writable location. +- Hunt for repeat occurrences across the endpoint (and fleet) that share the same parent, script content, or destination services, then check for associated indicators like new launch agents/daemons, cron jobs, or suspicious login items. + + +*False positive analysis* + + +- A user or admin runs a short shell one-liner (bash/zsh with an http-containing command line) that uses curl to quickly confirm the Mac’s external IP during routine troubleshooting, VPN verification, or connectivity checks. +- A legitimate but unsigned/not-yet-trusted macOS app launched from /Applications, a mounted /Volumes installer/dmg, or a temporary /private/var/folders path performs an external IP lookup via curl as part of initialization, telemetry, or network diagnostics. + + +*Response and remediation* + + +- Isolate the affected Mac from the network if the curl/nscurl external-IP lookup is spawned by an unsigned/untrusted parent or from user-writable paths (e.g., /private/var/folders, mounted /Volumes) to prevent follow-on command-and-control. +- Quarantine and remove the initiating artifact (app/script/binary) and any associated installers or DMGs, then block its hash and the specific lookup domains contacted (e.g., ipinfo.io, api.ipify.org, ifconfig.me) at egress/DNS to stop repeat discovery. +- Hunt for and delete persistence created around the event (LaunchAgents/LaunchDaemons, login items, cron entries) and terminate any remaining suspicious processes that inherit environment/output from the curl call. +- Reset exposed credentials and invalidate active sessions if the same parent process also accessed browsers, keychain, SSH keys, or configuration files shortly before/after the lookup, and rotate VPN/API tokens used on the host. +- Reimage or restore the endpoint from a known-good snapshot if additional unknown binaries, repeated external-IP lookups, or unexpected outbound connections are observed after cleanup, then validate with a follow-up scan and a clean process baseline. +- Escalate to IR leadership immediately if the external-IP lookup is followed by downloads/execution, persistence creation, or connections to newly registered/rare domains, and harden by restricting curl execution for non-admin contexts and tightening macOS app execution controls (Gatekeeper/notarization). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + ((process.parent.executable like ("/Applications/*", "/Volumes/*", "/private/var/folders/*")) or + (process.parent.name in ("bash", "sh", "zsh") and process.parent.command_line like "*http*") or + (process.parent.code_signature.trusted == false or process.parent.code_signature.exists == false or process.code_signature.exists == false)) and + process.name in ("curl", "nscurl") and + process.args_count <= 5 and + process.command_line like ("*ip-api.com*", "*ipwho.is*", "*checkip.dyndns.org*", "*api.ipify.org*", + "*whatismyip.akamai.com*", "*ifcfg.me*", "*ifconfig.me*", "*ident.me*", + "*icanhazip.com*", "*ipecho.net*", "*api.myip.com*", "*checkip.amazonaws.com*", + "*wtfismyip.com*", "*iplogger.*", "*freegeoip.net*", "*ipinfo.io*", + "*geoplugin.net*", "*httpbin.org*", "*myip.opendns.com*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Sub-technique: +** Name: Internet Connection Discovery +** ID: T1016.001 +** Reference URL: https://attack.mitre.org/techniques/T1016/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-first-time-destructive-mongodb-command-from-a-client-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-first-time-destructive-mongodb-command-from-a-client-ip.asciidoc new file mode 100644 index 0000000000..353cc780a2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-first-time-destructive-mongodb-command-from-a-client-ip.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-29-first-time-destructive-mongodb-command-from-a-client-ip]] +=== First-Time Destructive MongoDB Command from a Client IP + +Identifies the first client IP observed issuing MongoDB commands that can drop databases, collections, indexes, users, or roles within a five-day history window. Adversaries with access to an exposed or compromised MongoDB service may use these commands to destroy data, disrupt applications, or prepare a wipe-and-extort attack. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-network_traffic.mongodb-* + +*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.bleepingcomputer.com/news/security/mongo-lock-attack-ransoming-deleted-mongodb-databases/ +* https://flare.io/learn/resources/blog/mongodb-ransom +* https://attack.mitre.org/techniques/T1485/ + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Impact +* Data Source: Network Packet Capture +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First-Time Destructive MongoDB Command from a Client IP* + + +MongoDB wipe-and-extort campaigns commonly enumerate databases before dropping databases or collections and inserting a ransom note. This rule detects the first client IP observed issuing decoded MongoDB commands capable of destructive schema, data, identity, or access changes within a five-day history window. + + +*Possible investigation steps* + + +- Review `client.ip`, `server.ip`, `network.community_id`, `network_traffic.mongodb.method`, `network_traffic.mongodb.query`, `network_traffic.mongodb.resource`, and `network_traffic.mongodb.fullCollectionName`. +- Determine whether the client is an approved application, DBA workstation, migration host, or automation service. +- Search earlier events on the same `network.community_id` for `listDatabases`, `listCollections`, `usersInfo`, or `rolesInfo`, which may indicate reconnaissance before destruction. +- Search subsequent activity for database or collection creation and ransom-related strings such as `README`, `RECOVER`, `bitcoin`, or `meow`. +- Confirm the operation and affected resources in MongoDB audit logs and assess whether data was deleted. + + +*False positive analysis* + + +- Schema migrations and test cleanup can legitimately drop collections or indexes. +- Authorized identity lifecycle operations can drop users or roles. +- Scope exceptions to approved clients and maintenance windows rather than excluding command names globally. + + +*Response and remediation* + + +- Block the client and isolate the MongoDB service if the activity is unauthorized. +- Preserve MongoDB audit logs and packet evidence, identify affected databases, and begin recovery from immutable backups. +- Rotate database credentials, remove unauthorized users or roles, and restrict MongoDB network access to approved application and administration hosts. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Network Packet Capture integration with the MongoDB protocol analyzer enabled and +cleartext visibility into MongoDB transactions. TLS-encrypted or compressed MongoDB wire traffic may not expose +`network_traffic.mongodb.query`. Modern OP_MSG traffic often reports `network_traffic.mongodb.method` as `msg`, so the +query-text branch is required. Use MongoDB audit logs for authoritative user attribution and operation outcomes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:network_traffic.mongodb and +( + network_traffic.mongodb.method:( + "dropDatabase" or "drop" or "dropIndexes" or + "dropAllUsersFromDatabase" or "dropAllRolesFromDatabase" + ) or + ( + network_traffic.mongodb.method:"msg" and + network_traffic.mongodb.query:( + *dropDatabase* or *dropIndexes* or + *dropAllUsersFromDatabase* or *dropAllRolesFromDatabase* or + *\"drop\"* + ) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-first-time-seen-memcached-writer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-first-time-seen-memcached-writer.asciidoc new file mode 100644 index 0000000000..28b98d0c7a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-first-time-seen-memcached-writer.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-29-first-time-seen-memcached-writer]] +=== First Time Seen Memcached Writer + +Identifies the first successful or no-reply Memcached store command from a client to a server. Memcached commonly has no authentication, so an unauthorized writer can overwrite session tokens, poison cached application content, or alter security-sensitive state. This behavior can enable session hijacking such as the exposure described by CVE-2026-29093. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-network_traffic.memcached-* + +*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://nvd.nist.gov/vuln/detail/CVE-2026-29093 +* https://attack.mitre.org/techniques/T1565/001/ +* https://www.elastic.co/docs/reference/integrations/network_traffic + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Impact +* Data Source: Network Packet Capture +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen Memcached Writer* + + +Memcached permits store commands without authentication by default. A client with network access can use `set`, `add`, `replace`, `append`, `prepend`, or `cas` to overwrite session objects or inject content consumed by an application. This rule uses a seven-day new-terms history window to surface the first observed client, Memcached server, and store command combination performing a successful operation or issuing a store command with `noreply`. + +The rule does not inspect cached values and does not prove that a session was hijacked. It identifies an unusual writer relationship that requires application and asset context. + + +*Possible investigation steps* + + +- Review `client.ip`, `server.ip`, `server.port`, `network.community_id`, `network_traffic.memcached.request.command`, `network_traffic.memcached.request.keys`, `network_traffic.memcached.response.type`, and `network_traffic.memcached.response.status_code`. +- Determine whether the client is an approved application server, cache warmer, administrative host, deployment job, or newly scaled workload. +- Inspect key names for application-specific session prefixes such as `memc.sess.key`, `PHPSESSID`, or `session`. Do not retrieve or ingest cached values unless incident response requires it and access controls permit it. +- Search earlier Memcached events from the same client for `get`, `gets`, `stats`, `lru_crawler`, or key enumeration activity that could indicate discovery before modification. +- Search subsequent events for `flush_all`, delete bursts, privileged web sessions from new source addresses or user agents, and administrative actions without the normal authentication sequence. +- Review application and identity logs to determine whether the write was followed by session reuse or impersonation. + + +*False positive analysis* + + +- Autoscaling and deployments can introduce legitimate first-time writers. +- NAT or proxies can combine multiple application instances under one client address or make a known writer appear new. +- Add exceptions for validated client and server pairs rather than excluding store commands globally. + + +*Response and remediation* + + +- Block unauthorized clients and restrict Memcached listeners to approved application and administration networks. +- Invalidate affected sessions and rotate exposed credentials if session manipulation is suspected. +- Bind Memcached to private interfaces, enforce network-layer access controls, and disable UDP unless explicitly needed. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Network Packet Capture integration with the Memcached protocol analyzer enabled and +cleartext visibility into client-to-server transactions. The sensor must observe responses to confirm successful +operations, except when the client explicitly uses `noreply`. + +Keep value capture disabled unless it is explicitly required and protected. Cached values can contain live session +tokens, credentials, personal data, and other sensitive application content. Key and command metadata are sufficient +for this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:network_traffic.memcached and +client.ip:* and server.ip:* and +network_traffic.memcached.request.command:("set" or "add" or "replace" or "append" or "prepend" or "cas") and +( + network_traffic.memcached.response.type:("Success" or "success") or + network_traffic.memcached.response.status_code:0 or + network_traffic.memcached.request.noreply:true +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-first-time-seen-nfs-auth-sys-root-uid-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-first-time-seen-nfs-auth-sys-root-uid-access.asciidoc new file mode 100644 index 0000000000..c5ebdccda3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-first-time-seen-nfs-auth-sys-root-uid-access.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-29-first-time-seen-nfs-auth-sys-root-uid-access]] +=== First Time Seen NFS AUTH_SYS Root UID Access + +Identifies the first source and destination IP pair observed in a five-day history window where an NFS client asserts AUTH_SYS (RPC UNIX) credentials with UID 0 (root). NFSv3 and NFSv4 clients can claim arbitrary UIDs through AUTH_SYS, and weak export controls may honor root-equivalent access from unexpected hosts. This is a common precursor to unauthorized mounts, sensitive file reads, and remote encryption of exported shares. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-network_traffic.nfs* + +*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/T1213/ +* https://attack.mitre.org/techniques/T1039/ + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Network Security Monitoring +* Tactic: Collection +* Data Source: Network Packet Capture +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen NFS AUTH_SYS Root UID Access* + + +NFS AUTH_SYS allows the client to assert UID/GID values on the wire. UID 0 maps to superuser access on many exports unless root squashing or Kerberos (RPCSEC_GSS) is enforced. Attackers abuse this to read secrets, traverse exports, or stage ransomware writes without a local root shell on the NFS server. This rule uses a five-day history window to identify the first observed source and destination IP pair presenting root credentials. + + +*Possible investigation steps* + + +- Identify `source.ip` and confirm whether it is an approved NFS client for the targeted `destination.ip` export server. +- Review adjacent NFS operations from the same source for `READDIR`, `READ`, `WRITE`, or `REMOVE` activity that suggests enumeration, collection, or impact. +- Validate export policy on the server (`/etc/exports`, `exportfs -v`) for `no_root_squash`, overly broad client lists, or missing `sec=krb5`. +- Check endpoint telemetry on the source host for tooling such as `showmount`, `mount.nfs`, or Impacket-style NFS abuse. + + +*False positive analysis* + + +- Known backup, imaging, or virtualization platforms sometimes mount exports as root from fixed infrastructure IPs. Create exceptions for those sources only after confirming stable client identity and expected operation mix. +- Migration or DR runbooks may temporarily mount with root to preserve ownership. Correlate with change tickets and bounded maintenance windows. + + +*Response and remediation* + + +- Block unauthorized `source.ip` at the host firewall or export ACL and rotate any credentials read from the export. +- Enforce `root_squash`, narrow client allowlists, and RPCSEC_GSS on sensitive exports. +- Hunt for follow-on `WRITE`/`RENAME` bursts from the same client that may indicate ransomware activity. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic **network_traffic** integration (Packetbeat via Elastic Agent) with the **NFS** protocol +module enabled on a sensor that observes NFS traffic to or from monitored exports (host agent, SPAN/mirror, or gateway). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:network_traffic.nfs and +network_traffic.nfs.rpc.cred.uid:0 and +network_traffic.nfs.rpc.auth_flavor:unix and +source.ip:* and destination.ip:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Network Shared Drive +** ID: T1039 +** Reference URL: https://attack.mitre.org/techniques/T1039/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-endpoint-permission-enumeration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-endpoint-permission-enumeration.asciidoc new file mode 100644 index 0000000000..ee0bff7083 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-endpoint-permission-enumeration.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-29-gke-endpoint-permission-enumeration]] +=== GKE Endpoint Permission Enumeration + +Detects a single authenticated GKE identity from one source IP issuing a burst of API calls across many distinct actions and resources with a mix of successful and failed outcomes. That pattern is consistent with automated RBAC permission enumeration rather than steady-state controller traffic. Anonymous probing is covered by a separate rule. + +*Rule type*: esql + +*Rule indices*: None + +*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://heilancoos.github.io/research/2025/12/16/kubernetes.html#unauthenticated-api-access + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Endpoint Permission Enumeration* + + +The rule aggregates GKE audit events per `client.user.email` and `source.ip` over the rule lookback. It alerts when +the actor hits more than five distinct `event.action` values and more than three distinct `gcp.audit.resource_name` +values, produces both success and failure outcomes, and stays under 75 total events. Use +`Esql.earliest_timestamp` and `Esql.latest_timestamp` to bound the burst in Discover. + + +*Possible investigation steps* + + +- Review `Esql.event_action_values`, `Esql.gcp_audit_resource_name_values`, and `Esql.event_outcome_values` for targeted APIs + (secrets, RBAC, pods/exec) and which calls succeeded. +- Confirm whether `source.ip` and `Esql.user_agent_original_values` match expected admin or automation clients. +- Hunt for follow-on activity from the same identity: RoleBinding changes, secret reads, privileged pod creates, or + exec. + + +*False positive analysis* + + +- Platform engineers validating least-privilege RBAC can look like enumeration; correlate with change tickets. +- Chatty operators that occasionally fail authorization may approach the thresholds; raise exclusions only after + confirming the identity is expected. + + +*Response and remediation* + + +- If malicious, revoke or rotate the credential, tighten RBAC, and inspect for data access or persistence after the + burst. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-gcp.audit-* metadata _id, _index, _version +| where data_stream.dataset == "gcp.audit" + and service.name == "k8s.io" + and client.user.email is not null + and source.ip is not null + and to_string(source.ip) != "127.0.0.1" + and to_string(source.ip) != "::1" + and client.user.email != "system:anonymous" + and client.user.email != "system:unauthenticated" + and gcp.audit.resource_name != "readyz" + and gcp.audit.resource_name != "livez" + and gcp.audit.resource_name != "healthz" + and gcp.audit.resource_name != "version" +| stats + Esql.document_count = count(), + Esql.event_outcome_count_distinct = count_distinct(event.outcome), + Esql.event_action_count_distinct = count_distinct(event.action), + Esql.gcp_audit_resource_name_count_distinct = count_distinct(gcp.audit.resource_name), + Esql.earliest_timestamp = min(@timestamp), + Esql.latest_timestamp = max(@timestamp), + Esql.event_action_values = values(event.action), + Esql.event_outcome_values = values(event.outcome), + Esql.gcp_audit_resource_name_values = values(gcp.audit.resource_name), + Esql.user_agent_original_values = values(user_agent.original) + by client.user.email, source.ip +| where Esql.event_outcome_count_distinct == 2 + and Esql.event_action_count_distinct > 5 + and Esql.gcp_audit_resource_name_count_distinct > 3 + and Esql.document_count < 75 +| keep Esql.*, client.user.email, source.ip + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-multi-resource-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-multi-resource-discovery.asciidoc new file mode 100644 index 0000000000..e5a23a6ce0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-multi-resource-discovery.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-29-gke-multi-resource-discovery]] +=== GKE Multi-Resource Discovery + +Adversaries who land credentials in a GKE cluster—or abuse an over-privileged token, often map the environment before exfiltration or privilege escalation. A practical first pass is to learn where workloads run, how the cluster is partitioned, and what RBAC exists at namespace vs cluster scope. Rapid get/list traffic across many distinct API resource kinds that answer those questions (namespaces, workloads, roles, cluster-wide roles) is a common setup and orientation pattern for both interactive attackers and automated recon scripts. This rule highlights that cross-resource burst from a single client fingerprint within a one-minute bucket when both cluster-layout and RBAC resource kinds are touched, so analysts can separate routine automation from potential discovery ahead of follow-on actions. + +*Rule type*: esql + +*Rule indices*: None + +*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://microsoft.github.io/Threat-Matrix-for-Kubernetes/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Multi-Resource Discovery* + + +The rule groups GKE audit get/list events on namespaces, nodes, pods, configmaps, serviceaccounts, roles, +rolebindings, clusterroles, and clusterrolebindings into one-minute windows per `client.user.email`, `source.ip`, +and `user_agent.original`. It alerts when five or more distinct resource kinds appear and the burst includes both +cluster-layout kinds (namespaces, pods, or nodes) and RBAC kinds. Allowed and denied authorizations are both +included: failures still signal probing. + + +*Possible investigation steps* + + +- Review `Esql.enumerated_resources`, `Esql.enumerated_namespaces`, and `Esql.enumerated_resource_names` for + ordering and targeted APIs. +- Confirm whether `source.ip` and `user_agent.original` match expected admin or automation clients. +- Correlate with follow-on secret reads, RoleBinding changes, pod exec, or unusual user agents from the same actor. + + +*False positive analysis* + + +- Documented platform sync jobs that read layout and RBAC together; exclude known service accounts after validation. +- Upgrade or install windows that briefly query many resource kinds; correlate with change records. + + +*Response and remediation* + + +- If malicious, revoke or rotate the implicated credentials, tighten RBAC, and inspect for data access or persistence + established after the burst. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== 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.action in ( + "io.k8s.core.v1.namespaces.get", + "io.k8s.core.v1.namespaces.list", + "io.k8s.core.v1.nodes.get", + "io.k8s.core.v1.nodes.list", + "io.k8s.core.v1.pods.get", + "io.k8s.core.v1.pods.list", + "io.k8s.core.v1.configmaps.get", + "io.k8s.core.v1.configmaps.list", + "io.k8s.core.v1.serviceaccounts.get", + "io.k8s.core.v1.serviceaccounts.list", + "io.k8s.authorization.rbac.v1.roles.get", + "io.k8s.authorization.rbac.v1.roles.list", + "io.k8s.authorization.rbac.v1.rolebindings.get", + "io.k8s.authorization.rbac.v1.rolebindings.list", + "io.k8s.authorization.rbac.v1.clusterroles.get", + "io.k8s.authorization.rbac.v1.clusterroles.list", + "io.k8s.authorization.rbac.v1.clusterrolebindings.get", + "io.k8s.authorization.rbac.v1.clusterrolebindings.list" + ) + and source.ip is not null + and client.user.email is not null + and not to_string(source.ip) in ("127.0.0.1", "::1") + and not client.user.email like "system:kube-*" + and not client.user.email like "system:gke-*" + and not client.user.email like "system:node:*" + and not client.user.email like "system:serviceaccount:kube-system:*" + and not client.user.email like "system:serviceaccount:gke-managed*" + and not client.user.email in ( + "system:apiserver", + "system:addon-manager", + "system:kubestore-collector", + "gcp:kube-bootstrap", + "system:serviceaccount:security:trivy-operator" + ) + and not client.user.email like "system:serviceaccount:flux-system:*" + and not client.user.email like "system:serviceaccount:argocd:*" + and not client.user.email like "system:serviceaccount:argocd-system:*" + and not client.user.email like "system:serviceaccount:cattle-turtles-system:*" + and not client.user.email like "system:serviceaccount:*:palette-manager" +| eval Esql.time_interval = date_trunc(1 minute, @timestamp), + Esql.resource_kind = case( + event.action in ("io.k8s.core.v1.namespaces.get", "io.k8s.core.v1.namespaces.list"), "namespaces", + event.action in ("io.k8s.core.v1.nodes.get", "io.k8s.core.v1.nodes.list"), "nodes", + event.action in ("io.k8s.core.v1.pods.get", "io.k8s.core.v1.pods.list"), "pods", + event.action in ("io.k8s.core.v1.configmaps.get", "io.k8s.core.v1.configmaps.list"), "configmaps", + event.action in ("io.k8s.core.v1.serviceaccounts.get", "io.k8s.core.v1.serviceaccounts.list"), "serviceaccounts", + event.action in ("io.k8s.authorization.rbac.v1.roles.get", "io.k8s.authorization.rbac.v1.roles.list"), "roles", + event.action in ("io.k8s.authorization.rbac.v1.rolebindings.get", "io.k8s.authorization.rbac.v1.rolebindings.list"), "rolebindings", + event.action in ("io.k8s.authorization.rbac.v1.clusterroles.get", "io.k8s.authorization.rbac.v1.clusterroles.list"), "clusterroles", + event.action in ("io.k8s.authorization.rbac.v1.clusterrolebindings.get", "io.k8s.authorization.rbac.v1.clusterrolebindings.list"), "clusterrolebindings", + null + ), + Esql.is_rbac = case( + event.action in ( + "io.k8s.authorization.rbac.v1.roles.get", + "io.k8s.authorization.rbac.v1.roles.list", + "io.k8s.authorization.rbac.v1.rolebindings.get", + "io.k8s.authorization.rbac.v1.rolebindings.list", + "io.k8s.authorization.rbac.v1.clusterroles.get", + "io.k8s.authorization.rbac.v1.clusterroles.list", + "io.k8s.authorization.rbac.v1.clusterrolebindings.get", + "io.k8s.authorization.rbac.v1.clusterrolebindings.list" + ), + 1, + 0 + ), + Esql.is_layout = case( + event.action in ( + "io.k8s.core.v1.namespaces.get", + "io.k8s.core.v1.namespaces.list", + "io.k8s.core.v1.pods.get", + "io.k8s.core.v1.pods.list", + "io.k8s.core.v1.nodes.get", + "io.k8s.core.v1.nodes.list" + ), + 1, + 0 + ) +| stats + Esql.unique_resources = count_distinct(Esql.resource_kind), + Esql.rbac_event_count = sum(Esql.is_rbac), + Esql.layout_event_count = sum(Esql.is_layout), + Esql.enumerated_resources = values(Esql.resource_kind), + Esql.enumerated_namespaces = values(orchestrator.namespace), + Esql.enumerated_resource_names = values(gcp.audit.resource_name), + Esql.event_outcome_values = values(event.outcome) + by client.user.email, source.ip, user_agent.original, Esql.time_interval +| where Esql.unique_resources >= 5 + and Esql.rbac_event_count > 0 + and Esql.layout_event_count > 0 +| keep Esql.*, client.user.email, source.ip, user_agent.original + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-secret-access-from-node-or-denied-service-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-secret-access-from-node-or-denied-service-account.asciidoc new file mode 100644 index 0000000000..b815419b26 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-secret-access-from-node-or-denied-service-account.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-29-gke-secret-access-from-node-or-denied-service-account]] +=== GKE Secret Access from Node or Denied Service Account + +Detects GKE Secrets API activity that should not occur in normal cluster operation: a node identity (system:node:*) performing secrets get or list, or a pod service account failing a secrets get. Kubelet and node credentials are not expected to call the Secrets API for enumeration or direct reads, and a denied service-account secret get could indicate stolen-token probing or over-privileged tooling reaching beyond its RBAC. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*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://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Secret Access from Node or Denied Service Account* + + +This rule fires on two high-confidence patterns in GKE audit logs: + +- `system:node:*` successfully or unsuccessfully calling `secrets.get` or `secrets.list` +- `system:serviceaccount:*` receiving `event.outcome:failure` on `secrets.get` + +Treat node-originated Secrets API calls as priority. For denied service-account gets, determine whether +the identity is probing secrets outside its Role/ClusterRole or using an unexpected client from a +compromised token. + + +*Possible investigation steps* + + +- Resolve `client.user.email` to the node or workload and review RBAC bindings for secret `get`/`list` scope. +- Inspect `gcp.audit.resource_name`, `source.ip`, and `user_agent.original` for anomalous clients or + cross-namespace targets. +- Correlate with successful secret reads, pod exec, token creation, or RoleBinding changes in the same window. +- For node events, confirm whether kubelet, CSI, or maintenance tooling on that node should ever call the + Secrets API. + + +*False positive analysis* + + +- Node diagnostics or custom CSI helpers may rarely issue Secrets API calls; allowlist only after confirming + the path is approved. +- Broken RBAC on a newly deployed workload can produce repeated denied gets until permissions are fixed. + + +*Response and remediation* + + +- If malicious, revoke the node or service-account credentials, isolate the host or workload, rotate exposed + secrets, and tighten RBAC to least privilege for the affected identity. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and +source.ip:(* and not (127.0.0.1 or "::1")) and +( + ( + client.user.email:system\:node\:* and + event.action:(io.k8s.core.v1.secrets.get or io.k8s.core.v1.secrets.list) + ) or ( + client.user.email:system\:serviceaccount\:* and + event.action:io.k8s.core.v1.secrets.get 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: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-secret-access-via-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-secret-access-via-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..0c982af864 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-secret-access-via-unusual-user-agent.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-29-gke-secret-access-via-unusual-user-agent]] +=== GKE Secret Access via Unusual User Agent + +Detects GKE secrets get or list requests from a previously unseen combination of source IP, identity, and user agent, excluding the default Kubernetes client placeholder. Attackers who compromise a pod or steal a kubeconfig often use curl, custom scripts, or atypical clients from a new host to read service-account tokens, registry credentials, or application secrets. Anonymous identities are excluded; use dedicated anonymous-access rules for unauthenticated probing. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-gcp.audit-* + +*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://attack.mitre.org/techniques/T1552/007/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Secret Access via Unusual User Agent* + + +This new-terms rule alerts on secrets `get`/`list` when the (`source.ip`, `client.user.email`, `user_agent.original`) +triple is new in the history window. + + +*Possible investigation steps* + + +- Review `client.user.email`, `source.ip`, `user_agent.original`, and `gcp.audit.resource_name` for the secret and + namespace accessed. +- Determine whether the client fingerprint matches an approved admin path, CI runner, or controller upgrade. +- Pivot on the same identity or IP for secret bursts, pod exec, token creation, or RBAC changes. + + +*False positive analysis* + + +- New admin workstations, VPN egress IPs, or SDK version bumps can first-seen alert; tune after confirming ownership. +- First enablement surfaces legitimate clients until the history window fills. + + +*Response and remediation* + + +- If malicious, revoke the credential, rotate exposed secrets, isolate the source host or workload, and tighten who + can read secrets. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and +event.action:("io.k8s.core.v1.secrets.get" or "io.k8s.core.v1.secrets.list") and +user_agent.original:(* and not (*kubernetes/$Format* or kube-probe* or gke-exec-auth-plugin*)) and +source.ip:(* and not (127.0.0.1 or "::1")) and +client.user.email:(* and not ( + "system:anonymous" or "system:unauthenticated" or "system:addon-manager" or + "system:serviceaccount:kube-system:namespace-controller" +)) + +---------------------------------- + +*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: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc new file mode 100644 index 0000000000..06cdf5402a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-29-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 +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*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" + ) + 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-29/prebuilt-rule-8-19-29-gke-unusual-service-account-secret-access-via-new-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-unusual-service-account-secret-access-via-new-user-agent.asciidoc new file mode 100644 index 0000000000..5c2cdbdfa2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-gke-unusual-service-account-secret-access-via-new-user-agent.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-29-gke-unusual-service-account-secret-access-via-new-user-agent]] +=== GKE Unusual Service Account Secret Access via New User Agent + +Detects the first successful GKE secrets.get by a pod service account from a previously unseen combination of service-account identity, user agent, and source IP. Controllers routinely read secrets with a stable client fingerprint; a new user agent or source for that service account could indicate a stolen token used outside the workload (for example curl, a custom script, or kubectl from an unexpected host). + +*Rule type*: new_terms + +*Rule indices*: + +* logs-gcp.audit-* + +*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://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Unusual Service Account Secret Access via New User Agent* + + +This new-terms rule alerts when a `system:serviceaccount:*` identity successfully calls `secrets.get` with a +`client.user.email` + `user_agent.original` + `source.ip` combination not seen in the history window. + + +*Possible investigation steps* + + +- Confirm whether the service account normally uses this user agent or whether the client looks like an interactive + or scripting tool (`curl`, `python`, `kubectl`, generic HTTP libraries). +- Review `gcp.audit.resource_name` and namespace scope against the workload's expected secret mounts and RBAC. +- Pivot on the same `client.user.email` or `source.ip` for secret list/get bursts, exec, or RBAC changes. +- Compare to recent deployments or operator upgrades that would legitimately introduce a new client string. + + +*False positive analysis* + + +- Operator or library upgrades that change the user-agent string for an otherwise unchanged service account. +- First enablement of the rule will surface baseline controller clients until the history window fills. + + +*Response and remediation* + + +- If malicious, revoke the service-account token, rotate exposed secrets, isolate the originating workload or + host, and tighten RBAC so the identity can only read required secrets. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and event.outcome:success and +event.action:"io.k8s.core.v1.secrets.get" and +client.user.email:system\:serviceaccount\:* and +user_agent.original:(* and not *kubernetes/$Format*) and +source.ip:(* and not (127.0.0.1 or "::1")) + +---------------------------------- + +*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: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-local-scheduled-task-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-local-scheduled-task-creation.asciidoc new file mode 100644 index 0000000000..402d8322c5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-local-scheduled-task-creation.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-29-local-scheduled-task-creation]] +=== Local Scheduled Task Creation + +Indicates the creation of a scheduled task. Adversaries can use these to establish persistence, move laterally, and/or escalate privileges. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/hunting-for-persistence-using-elastic-security-part-1 +* https://www.elastic.co/security-labs/hunting-for-persistence-using-elastic-security-part-2 +* https://www.elastic.co/security-labs/invisible-miners-unveiling-ghostengine +* https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide + +*Version*: 214 + +*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 Local Scheduled Task Creation* + + +Scheduled tasks in Windows automate routine tasks, but adversaries exploit them for persistence, lateral movement, or privilege escalation. They may use command-line tools like `schtasks.exe` to create tasks under non-system accounts. The detection rule identifies suspicious task creation by monitoring specific processes and command-line arguments, excluding those initiated by system-level users, to flag potential misuse. + + +*Possible investigation steps* + + +- Review the process entity ID to identify the parent process that initiated the scheduled task creation. This can provide context on whether the task was created by a legitimate application or a potentially malicious one. +- Examine the command-line arguments used with schtasks.exe, specifically looking for unusual or suspicious parameters that might indicate malicious intent, such as unexpected task names or execution paths. +- Check the user account associated with the task creation to determine if it is a non-system account and assess whether this account should have the capability to create scheduled tasks. +- Investigate the integrity level of the process to confirm it is not running with elevated privileges, which could indicate an attempt to bypass security controls. +- Correlate the event with other recent activities on the host, such as file modifications or network connections, to identify any patterns or additional indicators of compromise. +- Review the code signature of the initiating process to determine if it is trusted or untrusted, which can help assess the legitimacy of the process creating the task. + + +*False positive analysis* + + +- Scheduled tasks created by legitimate administrative tools or scripts may trigger false positives. Users should identify and whitelist these known benign processes to prevent unnecessary alerts. +- Routine maintenance tasks initiated by IT departments, such as software updates or system checks, can be mistaken for suspicious activity. Exclude these tasks by specifying their unique process names or command-line arguments. +- Tasks created by trusted third-party applications for legitimate purposes might be flagged. Review and exclude these applications by verifying their code signatures and adding them to an exception list. +- Automated tasks set up by non-system accounts for regular operations, like backups or monitoring, can be misinterpreted. Document these tasks and exclude them based on their specific parameters or user accounts involved. +- Consider excluding tasks with a consistent and verified schedule that aligns with organizational policies, as these are less likely to be malicious. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious scheduled tasks identified by the alert using Task Scheduler or command-line tools like schtasks.exe to stop further execution. +- Review and remove any unauthorized scheduled tasks created by non-system accounts to eliminate persistence mechanisms. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious artifacts. +- Analyze the user account involved in the task creation for signs of compromise, and reset credentials if necessary to prevent further unauthorized access. +- 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 scheduled task creation events to detect similar threats in the future, ensuring alerts are configured to notify the appropriate teams promptly. + +==== 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/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=1m + [process where host.os.type == "windows" and event.type == "start" and + ((process.name : ("cmd.exe", "wscript.exe", "rundll32.exe", "regsvr32.exe", "wmic.exe", "mshta.exe", + "powershell.exe", "pwsh.exe", "powershell_ise.exe", "WmiPrvSe.exe", "wsmprovhost.exe", "winrshost.exe") or + process.pe.original_file_name : ("cmd.exe", "wscript.exe", "rundll32.exe", "regsvr32.exe", "wmic.exe", "mshta.exe", + "powershell.exe", "pwsh.dll", "powershell_ise.exe", "WmiPrvSe.exe", "wsmprovhost.exe", + "winrshost.exe")) or + ?process.code_signature.trusted == false) and + /* exclude legitimate software creating its own scheduled tasks */ + not ( + process.name : "cmd.exe" and + ( + ( + process.parent.executable : "?:\\Program Files\\Adobe\\Adobe Creative Cloud Experience\\libs\\node.exe" and + process.command_line : "*?:\\Program Files\\Adobe\\Adobe Creative Cloud Experience\\CCXProcess.exe*" + ) or + ( + process.parent.executable : "?:\\Program Files (x86)\\LG Software\\LG App Count\\LGAppCountObserver.exe" and + process.command_line : "*?:\\Program Files (x86)\\LG Software\\LG App Count\\*" + ) or + ( + process.parent.executable : "?:\\Program Files (x86)\\LG Software\\LG Update & Recovery\\URAlarm.exe" and + process.command_line : "*?:\\Program Files (x86)\\LG Software\\LG Update & Recovery\\Support\\*" + ) + ) + ) + ] by process.entity_id + [process where host.os.type == "windows" and event.type == "start" and + (process.name : "schtasks.exe" or process.pe.original_file_name == "schtasks.exe") and + process.args : ("/create", "-create") and process.args : ("/RU", "/SC", "/TN", "/TR", "/F", "/XML") and + /* exclude SYSTEM Integrity Level - look for task creations by non-SYSTEM user */ + not (?process.Ext.token.integrity_level_name : "System" or ?winlog.event_data.IntegrityLevel : "System") + ] 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: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-m365-identity-login-from-atypical-region.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-m365-identity-login-from-atypical-region.asciidoc new file mode 100644 index 0000000000..fb72468e8b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-m365-identity-login-from-atypical-region.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-29-m365-identity-login-from-atypical-region]] +=== M365 Identity Login from Atypical Region + +Detects successful Microsoft 365 portal logins from a country and region the user has not previously authenticated from in a specific time window. Atypical regions are identified by combining the user's country and region geolocation history; an authentication from a new country/region pair for that user may indicate an adversary attempting to access the account from an unusual location or behind a VPN. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/time-travelers-busted-how-to-detect-impossible-travel- + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Login from Atypical Region* + + +Microsoft 365 is a cloud-based suite offering productivity tools accessible from anywhere, making it crucial for business operations. Adversaries may exploit this by logging in from uncommon regions, potentially using VPNs to mask their origin. The detection rule identifies successful logins from atypical country/region pairs for a given user, flagging potential unauthorized access attempts by analyzing login events and user location patterns at country and region granularity. + + +*Possible investigation steps* + + +- Review the user associated with these sign-ins to determine if the login attempt was legitimate or if further investigation is needed. +- Analyze the geographic locations of the logins to identify any patterns or anomalies that may indicate malicious activity. +- Review the ISP information for the login attempts to identify any unusual or suspicious providers. +- Review the authorization request type to understand the context of the login attempts and whether they align with the user's typical behavior. +- Analyze the client application used for the login attempts to determine if it is consistent with the user's normal usage patterns (Teams, Office, etc.) +- Analyze the user-agent associated with the login attempts to identify any unusual or suspicious patterns. These could also indicate mobile and endpoint logins causing false-positives. + + +*False positive analysis* + + +- Users traveling or using VPNs may trigger this alert. Verify with the user if they were traveling or using a VPN at the time of the login attempt. +- Mobile access may also result in false positives, as users may log in from various locations while on the go. + + +*Response and remediation* + + +- Investigate the login attempt further by checking for any additional context or related events that may provide insight into the user's behavior. +- If the login attempt is deemed suspicious, consider implementing additional security measures, such as requiring multi-factor authentication (MFA) for logins from unusual locations. +- Educate users about the risks of accessing corporate resources from unfamiliar locations and the importance of using secure connections (e.g., VPNs) when doing so. +- Monitor for any subsequent login attempts from the same location or IP address to identify potential patterns of malicious activity. +- Consider adding exceptions to this rule for the user or source application ID if the login attempts are determined to be legitimate and not a security concern. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and + event.provider:AzureActiveDirectory and + event.action:UserLoggedIn and event.outcome:success and + o365.audit.Target.Type:(0 or 2 or 3 or 5 or 6 or 10) and + o365.audit.UserId:(* and not "Not Available") and + source.geo.country_name:* and + source.geo.region_name:* and + o365.audit.ApplicationId:(* and not ( + 08e18876-6177-487e-b8b5-cf950c1e598c or + 29d9ed98-a469-4536-ade2-f981bc1d605e or + 38aa3b87-a06d-4817-b275-7a316988d93b or + 3e62f81e-590b-425b-9531-cad6683656cf or + a809996b-059e-42e2-9866-db24b99a9782 or + d7b530a4-7680-4c23-a8bf-c52c121d2e87 + )) and + o365.audit.ExtendedProperties.RequestType:(* and not ( + "Consent:Set" or + "DeviceAuth:ReprocessTls" or + "Federation:oauth2claimsprovider" or + "Federation:oauth2msa" or + "Kmsi:kmsi" or + "Login:reprocess" or + "Login:resume" or + "MessagePrompt:MessagePrompt" or + "OrgIdWsFederation:federation" or + "PermitSso:PermitSso" or + "SAS:EndAuth" or + "SAS:ProcessAuth" or + "SSPR:end" or + "Saml2:processrequest" or + "WsFederation:wsfederation" + )) and + not user_agent.original:(*Android* or *PKeyAuth* or *WebView* or *iPad* or *iPhone*) + +---------------------------------- + +*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-29/prebuilt-rule-8-19-29-mark-of-the-web-removal-by-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-mark-of-the-web-removal-by-an-unusual-process.asciidoc new file mode 100644 index 0000000000..fbd05f695d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-mark-of-the-web-removal-by-an-unusual-process.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-29-mark-of-the-web-removal-by-an-unusual-process]] +=== Mark-of-the-Web Removal by an Unusual Process + +Identifies an unusual process deleting the Zone.Identifier alternate data stream from an executable or Windows Installer package. Attackers can remove this stream to bypass Mark-of-the-Web protections. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*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.forcepoint.com/blog/x-labs/screenconnect-attack +* https://www.sonicwall.com/blog/living-off-legit-tools-stealthy-installation-of-remote-monitoring-agents-using-smartscreen-bypass +* https://any.run/cybersecurity-blog/rmm-blind-spot-for-cisos/ +* https://www.cyfirma.com/research/apt36-multi-vector-execution-malware-campaign-targeting-indian-government-entities/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Mark-of-the-Web Removal by an Unusual Process* + + + +*Possible investigation steps* + + +- Which process and account removed Mark-of-the-Web from which artifact? + - Focus: Review `file.path`, `process.executable`, `process.name`, `user.name`, and `host.name`. + - Implication: The alert establishes an attributed ADS deletion, not execution or intent. Treat a download, security, or deployment workflow as a benign candidate only when the exact remover, account, artifact, and an independent workflow record align. + +- Does the deleting-process context fit an expected unblocking workflow? + - Focus: From related process events, review `process.command_line`, `process.parent.executable`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Hint: When `process.entity_id` is populated, review events for the same process entity on the alert host !{investigate{"description":"","label":"Events for the deleting process on this host","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"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Implication: PowerShell unblocking or deployment activity needs an expected parent, operator or task, command, and target artifact; a trusted signer alone is insufficient. If `process.entity_id` is absent, use `host.id`, `process.pid`, and a tight alert-time window; missing related process telemetry remains unresolved. + +- What provenance does the base executable or MSI have? + - Focus: Strip the terminal `:Zone.Identifier` or `:Zone.Identifier:$DATA` suffix, then search same-host file events for the base path and inspect `file.Ext.original.path`, `file.origin_url`, `file.origin_referrer_url`, `file.Ext.windows.zone_identifier`, and `file.hash.sha256` when populated. + - Hint: Start with the 24 hours before the deletion and widen to available retention when necessary. + - Implication: Missing download or file-origin telemetry is unresolved. Consistent source, hash, target directory, and a matching download or deployment record support the claimed workflow. + +- Was the base artifact executed or used in an installation attempt after deletion? + - Focus: For an EXE, match the base path to `process.executable`; for an MSI, find `msiexec.exe` with the exact base path in `process.args`. + - Hint: Search the same host for five minutes after the deletion, then widen when evidence warrants; review lineage and follow-on file or process activity. + - Implication: A match establishes observed execution or an installation attempt, not maliciousness or installation success. Inconsistent provenance, lineage, or follow-on behavior supports escalation; no match only limits observed impact. + +- Is the removal isolated or repeated on the host? + - Focus: Review deletions for the same ADS path !{investigate{"description":"","label":"File deletions for the same ADS path","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"deletion","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Hint: When `user.id` is populated, review file deletions by the same user and process name, then retain only EXE or MSI `Zone.Identifier` paths !{investigate{"description":"","label":"File deletions by the same user and process name","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"{{process.name}}","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"deletion","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Implication: If `user.id` is absent, use the exact-path results and a manual same-host search around the alert time. The broader transform returns all file deletions, not only MOTW removal; multiple unrelated matching artifacts support escalation, while a stable release set with the same expected workflow can support benign disposition. + +- Escalate when remover context, provenance, follow-on behavior, or repeated unrelated targets conflict with an expected workflow. Close only when alert telemetry and an independent download, deployment, or security-tool record align for the exact actor and artifact. Preserve evidence and escalate mixed or incomplete cases. + + +*False positive analysis* + + +- Browser, download-handler, security-product, administrative, and deployment workflows can remove Mark-of-the-Web legitimately. Confirm that the process identity and lineage, account and host, exact artifact, provenance, and an independent product or deployment record describe the same workflow before closing the alert. +- Add an exception only after recurring benign examples establish stable fields. Constrain it to alert fields such as the exact remover executable and signer, target path or package family, and expected account or host class; do not exclude PowerShell or all trusted processes globally. + + +*Response and remediation* + + +- For unresolved activity, preserve the alert and source events, then recover the deleting-process and artifact context. Do not isolate a host solely on this low-severity signal. +- If malicious activity or suspicious follow-on behavior is confirmed, contain affected hosts or accounts with reversible controls. Preserve volatile evidence when active or memory-resident behavior warrants it, then terminate malicious processes and quarantine artifacts or persistence after evidence review. +- For confirmed benign activity, close the alert and consider a narrow exception only after recurring examples establish stable fields. Document affected paths, scope, observed workflow evidence, and telemetry gaps. + + +==== 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] +---------------------------------- +file where host.os.type == "windows" and event.type == "deletion" and + file.path : ( + "*.exe:Zone.Identifier", + "*.exe:Zone.Identifier:$DATA", + "*.msi:Zone.Identifier", + "*.msi:Zone.Identifier:$DATA" + ) and + + /* Explorer may remove MOTW after SmartScreen */ + not ( + process.executable : "?:\\Windows\\explorer.exe" and + process.code_signature.trusted == true and + process.code_signature.subject_name : "Microsoft Windows" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Mark-of-the-Web Bypass +** ID: T1553.005 +** Reference URL: https://attack.mitre.org/techniques/T1553/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-mofcomp-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-mofcomp-activity.asciidoc new file mode 100644 index 0000000000..670bb48990 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-mofcomp-activity.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-29-mofcomp-activity]] +=== Mofcomp Activity + +Managed Object Format (MOF) files can be compiled locally or remotely through mofcomp.exe. Attackers may leverage MOF files to build their own namespaces and classes into the Windows Management Instrumentation (WMI) repository, or establish persistence using WMI Event Subscription. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-system.security* + +*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: Execution +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Mofcomp Activity* + +Mofcomp.exe is a tool used to compile Managed Object Format (MOF) files, which define classes and namespaces in the Windows Management Instrumentation (WMI) repository. Adversaries exploit this by creating malicious WMI scripts for persistence or execution. The detection rule identifies suspicious mofcomp.exe activity by filtering out legitimate processes and focusing on unusual executions, excluding known safe parent processes and system accounts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of mofcomp.exe and verify the command-line arguments used, focusing on any unusual or unexpected MOF file paths. +- Investigate the user account associated with the process execution, especially if it is not the system account (S-1-5-18), to determine if the account has been compromised or is being misused. +- Examine the parent process of mofcomp.exe to ensure it is not a known safe process like ScenarioEngine.exe, and assess whether the parent process is legitimate or potentially malicious. +- Check for any recent changes or additions to the WMI repository, including new namespaces or classes, which could indicate malicious activity or persistence mechanisms. +- Correlate the alert with other security events or logs from data sources like Microsoft Defender XDR or Crowdstrike to identify any related suspicious activities or patterns. + + +*False positive analysis* + + +- Legitimate SQL Server operations may trigger the rule when SQL Server components compile MOF files. To handle this, exclude processes with parent names like ScenarioEngine.exe and specific MOF file paths related to SQL Server. +- System maintenance tasks executed by trusted system accounts can cause false positives. Exclude activities initiated by the system account with user ID S-1-5-18 to reduce noise. +- Regular administrative tasks involving WMI may appear suspicious. Identify and document these tasks, then create exceptions for known safe parent processes or specific MOF file paths to prevent unnecessary alerts. +- Software installations or updates that involve MOF file compilation might be flagged. Monitor installation logs and exclude these processes if they are verified as part of legitimate software updates. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the mofcomp.exe process if it is confirmed to be executing malicious MOF files. +- Conduct a thorough review of the WMI repository to identify and remove any unauthorized namespaces or classes that may have been created by the attacker. +- Remove any malicious MOF files from the system to prevent re-execution. +- Restore the system from a known good backup if unauthorized changes to the WMI repository or system files are detected. +- Monitor for any recurrence of similar activity by setting up alerts for unusual mofcomp.exe executions and unauthorized WMI modifications. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- 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 : "mofcomp.exe" and process.args : "*.mof" and + not user.id : "S-1-5-18" and + not process.args : ( + "?:\\Program Files (x86)\\Microsoft Power BI Report Server\\*.mof", + "?:\\Program Files (x86)\\Microsoft SQL Server Reporting Services\\*.mof", + "?:\\Program Files (x86)\\Microsoft SQL Server\\*.mof", + "?:\\Program Files\\Microsoft Policy Platform\\*.mof", + "?:\\Program Files\\Microsoft Power BI Report Server\\*.mof", + "?:\\Program Files\\Microsoft SQL Server Reporting Services\\*.mof", + "?:\\Program Files\\Microsoft SQL Server\\*.mof", + "?:\\Windows\\System32\\wbem\\com.hp.provider.*.mof", + "?:\\Windows\\System32\\wbem\\CxAudioSvc_*.mof", + "?:\\Windows\\System32\\wbem\\Framework\\root\\*.mof", + "?:\\Windows\\System32\\wbem\\Veeam.Backup.*.mof", + "?:\\Windows\\System32\\wbem\\ZTITatoo.mof", + "?:\\Windows\\SysWOW64\\wbem\\Framework\\root\\*.mof" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Windows Management Instrumentation Event Subscription +** ID: T1546.003 +** Reference URL: https://attack.mitre.org/techniques/T1546/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-multiple-sonicwall-login-failures-followed-by-successful-login.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-multiple-sonicwall-login-failures-followed-by-successful-login.asciidoc new file mode 100644 index 0000000000..8ba54f9042 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-multiple-sonicwall-login-failures-followed-by-successful-login.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-29-multiple-sonicwall-login-failures-followed-by-successful-login]] +=== Multiple SonicWall Login Failures Followed by Successful Login + +Identifies multiple failed SonicWall authentication attempts against several user accounts from one source IP, followed by a successful remote-access login from the same source to the same appliance. This may indicate successful password spraying, credential stuffing, or password guessing. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/sonicwall-credential-stuffing-campaign +* https://www.elastic.co/docs/reference/integrations/sonicwall_firewall +* https://www.sonicwall.com/support/knowledge-base/monitoring-sslvpn-user-logins/kA1VN0000000JQz0AM + +*Tags*: + +* Domain: Network +* Domain: Identity +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Tactic: Initial Access +* Data Source: SonicWall +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple SonicWall Login Failures Followed by Successful Login* + + +This rule detects at least five failed authentication events affecting at least three users from one source IP to one SonicWall appliance, followed by at least one successful remote-access login after the failure activity began. The successful user does not have to be one of the failed users because credential attacks can test several credential pairs and shared source infrastructure can target multiple accounts. + +Failure event codes include incorrect or unknown credentials, RADIUS or LDAP authentication failures, and account lockouts. Successful event codes cover VPN- or WAN-zone administrator and remote-user logins, including SSL VPN. + + +*Possible investigation steps* + + +- Review `source.ip`, its ASN, geolocation, reputation, and prior activity. Determine whether it belongs to expected corporate proxy, VPN egress, managed service provider, jump-host, or monitoring infrastructure. +- Review `Esql.failed_user_names`, `Esql.successful_user_names`, `Esql.failed_logins`, `Esql.failed_user_count`, and `Esql.successful_logins`. Determine whether a successful user was also targeted by the failed attempts. +- Review `Esql.failure_event_codes` and `Esql.success_event_codes` to distinguish administrator, remote-user, SSL VPN, LDAP, RADIUS, and lockout activity. +- Examine the sequence between `Esql.first_failure`, `Esql.last_failure`, `Esql.first_success`, and `Esql.last_success`. Look for automated pacing, username enumeration, repeated attempts, or continued failures after the first successful login. +- Confirm whether MFA was required and completed for each successful authentication. +- Correlate successful VPN sessions with assigned tunnel IPs, internal authentication, DNS, network flow, and endpoint activity. For administrator logins, review subsequent SonicWall configuration changes. + + +*False positive analysis* + + +- Several users behind a shared public address may enter incorrect credentials while another user authenticates. +- Password rotation, expired cached credentials, LDAP or RADIUS issues, help-desk testing, and synthetic monitoring can generate failure-to-success patterns. +- Validate the source and workflow before adding an exception. Prefer an exception scoped by both source and appliance rather than excluding a user or source globally. + + +*Response and remediation* + + +- If unauthorized access is suspected, disable affected accounts, terminate active sessions, reset credentials, revoke tokens or keys, and enforce MFA. +- Block or restrict the source at the SonicWall appliance while investigating. +- Review configuration changes and downstream activity from successful VPN sessions. Isolate affected systems and begin incident response if post-authentication activity is identified. +- Preserve SonicWall authentication, VPN session, and configuration audit logs before making broad changes. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic **SonicWall Firewall** integration and SonicWall Enhanced Syslog authentication events. + +Configure the appliance to forward **Users > Authentication Access** and **Users > RADIUS Authentication** events. +Confirm that credential failure event codes `30`, `32`, `33`, `200`, `243`, `329`, `745`, `749`, and `1655`, and +successful remote-access event codes `235`, `236`, `237`, `238`, and `1080`, are collected. Verify that the integration +populates `data_stream.dataset`, `event.action`, `event.code`, `source.ip`, `user.name`, and either +`observer.serial_number` or a unique `observer.name`. + +If several customers share one Kibana space, ensure the appliance identity is unique per tenant so activity from +different customers is not aggregated together. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-sonicwall_firewall.log-* +| where + data_stream.dataset == "sonicwall_firewall.log" and + ( + ( + event.action == "login-failure" and + event.code in ("30", "32", "33", "200", "243", "329", "745", "749", "1655") + ) or ( + event.action == "login-success" and + event.code in ("235", "236", "237", "238", "1080") + ) + ) and + source.ip is not null and + user.name is not null and + (observer.serial_number is not null or observer.name is not null) +| eval + Esql.appliance_id = coalesce(observer.serial_number, observer.name), + Esql.is_failure = case(event.action == "login-failure", 1, 0), + Esql.is_success = case(event.action == "login-success", 1, 0), + Esql.failed_user = case(event.action == "login-failure", user.name, null), + Esql.successful_user = case(event.action == "login-success", user.name, null), + Esql.failure_event_code = case(event.action == "login-failure", event.code, null), + Esql.success_event_code = case(event.action == "login-success", event.code, null), + Esql.failure_timestamp = case(event.action == "login-failure", @timestamp, null), + Esql.success_timestamp = case(event.action == "login-success", @timestamp, null) +| stats + Esql.failed_logins = sum(Esql.is_failure), + Esql.successful_logins = sum(Esql.is_success), + Esql.failed_user_count = count_distinct(Esql.failed_user), + Esql.failed_user_names = values(Esql.failed_user), + Esql.successful_user_names = values(Esql.successful_user), + Esql.failure_event_codes = values(Esql.failure_event_code), + Esql.success_event_codes = values(Esql.success_event_code), + Esql.first_failure = min(Esql.failure_timestamp), + Esql.last_failure = max(Esql.failure_timestamp), + Esql.first_success = min(Esql.success_timestamp), + Esql.last_success = max(Esql.success_timestamp) + by Esql.appliance_id, source.ip +| where + Esql.failed_logins >= 5 and + Esql.failed_user_count >= 3 and + Esql.successful_logins >= 1 and + Esql.first_failure < Esql.last_success +| eval Esql.failure_to_success_seconds = date_diff("seconds", Esql.first_failure, Esql.last_success) +| sort Esql.failed_user_count desc, Esql.failed_logins desc +| keep source.ip, Esql.* + +---------------------------------- + +*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/ +* 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-29/prebuilt-rule-8-19-29-mysql-user-defined-function-injection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-mysql-user-defined-function-injection.asciidoc new file mode 100644 index 0000000000..c5dd3fcedd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-mysql-user-defined-function-injection.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-29-mysql-user-defined-function-injection]] +=== MySQL User-Defined Function Injection + +Identifies MySQL statements that create a user-defined function backed by a shared library. Adversaries with sufficient database privileges can place a malicious library in the MySQL plugin directory and register it with "CREATE FUNCTION ... SONAME", establishing a database-resident primitive for operating-system command execution. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.mysql-* + +*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://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html +* https://attack.mitre.org/techniques/T1505/001/ + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Network Packet Capture +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating MySQL User-Defined Function Injection* + + +MySQL can load native user-defined functions from shared libraries. Attackers who obtain the `FILE` privilege and write access to the plugin directory can write a malicious `.so` or `.dll`, register it with `CREATE FUNCTION ... SONAME`, and invoke operating-system commands as the MySQL service account. + + +*Possible investigation steps* + + +- Review `client.ip`, `server.ip`, `network.community_id`, `network_traffic.mysql.query`, `network_traffic.mysql.path`, and any response error fields. +- Extract the function and library names and verify whether they belong to an approved MySQL extension. +- Search prior queries on the same connection for `INTO DUMPFILE`, `INTO OUTFILE`, `LOAD_FILE`, plugin-directory discovery, or hexadecimal payload construction. +- On the database host, inspect the MySQL plugin directory for newly created `.so`, `.dll`, or other unexpected files. +- Correlate with child processes spawned by `mysqld` and with outbound connections from the database host. + + +*False positive analysis* + + +- Approved native UDF installation is uncommon but legitimate. Confirm the package source and change record. +- Do not exclude all DBA clients permanently; a compromised DBA workstation can perform the same operation. + + +*Response and remediation* + + +- Terminate unauthorized database sessions and isolate the database host if command execution is suspected. +- Remove the malicious function and library only after preserving evidence. +- Rotate database credentials, review grants containing `FILE`, and restrict writes to the plugin directory. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Network Packet Capture integration with the MySQL protocol analyzer enabled and +cleartext visibility into MySQL query traffic. TLS-encrypted sessions and incomplete or asymmetric capture can hide +query text. Use MySQL audit logs and endpoint telemetry for authoritative user attribution and proof of library +creation or command execution. + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "network_traffic.mysql" and + network_traffic.mysql.query like~ "*create*function*soname*" + +---------------------------------- + +*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: SQL Stored Procedures +** ID: T1505.001 +** Reference URL: https://attack.mitre.org/techniques/T1505/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-network-traffic-to-rare-destination-country.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-network-traffic-to-rare-destination-country.asciidoc new file mode 100644 index 0000000000..cc493b85ae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-network-traffic-to-rare-destination-country.asciidoc @@ -0,0 +1,214 @@ +[[prebuilt-rule-8-19-29-network-traffic-to-rare-destination-country]] +=== Network Traffic to Rare Destination Country + +A machine learning job detected a rare destination country name in the network logs. This can be due to initial access, persistence, command-and-control, or exfiltration activity. For example, when a user clicks on a link in a phishing email or opens a malicious document, a request may be sent to download and run a payload from a server in a country which does not normally appear in network traffic or business work-flows. Malware instances and persistence mechanisms may communicate with command-and-control (C2) infrastructure in their country of origin, which may be an unusual destination country for the source network. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Data Source: Elastic Defend +* Data Source: Network Packet Capture +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* 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 Network Traffic to Rare Destination Country* + + +Machine learning models analyze network logs to identify traffic to uncommon destination countries, which may indicate malicious activities like unauthorized access or data exfiltration. Adversaries exploit this by directing traffic to servers in atypical locations, often linked to command-and-control operations. The detection rule flags such anomalies, aiding in early threat identification and response. + + +*Possible investigation steps* + + +- Review the network logs to identify the specific destination country flagged as rare and assess its historical presence in the network traffic. +- Analyze the source IP addresses and user accounts associated with the flagged traffic to determine if they are legitimate or potentially compromised. +- Investigate the nature of the traffic, such as the protocols and ports used, to identify any unusual patterns or connections to known malicious infrastructure. +- Check for any recent phishing attempts or suspicious emails that may have led to the initiation of this traffic, focusing on links or attachments that could have been used to download malicious payloads. +- Correlate the flagged traffic with any other security alerts or incidents to identify potential patterns or coordinated attacks involving the rare destination country. +- Consult threat intelligence sources to determine if the destination country or specific IP addresses are associated with known threat actors or command-and-control servers. + + +*False positive analysis* + + +- Legitimate business communications with partners or clients in rare destination countries may trigger alerts. Users should review and whitelist these known entities to prevent future false positives. +- Routine software updates or patches from international vendors might be flagged. Identify and exclude these update servers from the detection rule to avoid unnecessary alerts. +- Employees traveling abroad and accessing company resources can generate alerts. Implement a process to temporarily whitelist these destinations based on travel schedules. +- Cloud services with global data centers may route traffic through uncommon countries. Verify the service's IP ranges and exclude them if they are part of normal operations. +- Research or market expansion activities targeting new regions might cause alerts. Document and exclude these activities if they align with business objectives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough scan of the isolated system for malware or unauthorized software, focusing on identifying any command-and-control (C2) communication channels. +- Block network traffic to and from the identified rare destination country at the firewall or proxy level to prevent further communication with potential malicious servers. +- Review and analyze logs from the affected system and network devices to identify any additional indicators of compromise or related suspicious activities. +- If malware is detected, remove it using appropriate tools and techniques, ensuring that all persistence mechanisms are eradicated. +- Restore the affected system from a clean backup if necessary, ensuring that all security patches and updates are applied. +- 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 the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*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 to your 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/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]. + + +*Network Packet Capture Integration Setup* + +The Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment — ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + + +*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 Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* 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: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over C2 Channel +** ID: T1041 +** Reference URL: https://attack.mitre.org/techniques/T1041/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious Link +** ID: T1204.001 +** Reference URL: https://attack.mitre.org/techniques/T1204/001/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-persistence-via-scheduled-job-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-persistence-via-scheduled-job-creation.asciidoc new file mode 100644 index 0000000000..9c34a55d4a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-persistence-via-scheduled-job-creation.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-29-persistence-via-scheduled-job-creation]] +=== Persistence via Scheduled Job Creation + +A job can be used to schedule programs or scripts to be executed at a specified date and time. Adversaries may abuse task scheduling functionality to facilitate initial or recurring execution of malicious code. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* + +*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: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide + +*Version*: 417 + +*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 Persistence via Scheduled Job Creation* + + +Scheduled jobs in Windows environments allow tasks to be automated by executing scripts or programs at specified times. Adversaries exploit this feature to maintain persistence by scheduling malicious code execution. The detection rule identifies suspicious job creation by monitoring specific file paths and extensions, excluding known legitimate processes, to flag potential abuse while minimizing false positives. + + +*Possible investigation steps* + + +- Review the file path and extension to confirm the presence of a scheduled job in the "?:\Windows\Tasks\" directory with a ".job" extension, which is indicative of a scheduled task. +- Examine the process executable path to determine if the job creation is associated with any known legitimate processes, such as CCleaner or ManageEngine, which are excluded in the detection rule. +- Investigate the origin of the process that created the scheduled job by checking the process execution history and command line arguments to identify any potentially malicious behavior. +- Analyze the scheduled job's content and associated scripts or programs to identify any suspicious or unauthorized code that may indicate malicious intent. +- Correlate the event with other security logs and alerts from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR to gather additional context and identify any related malicious activity. +- Assess the risk and impact of the scheduled job by determining if it aligns with known adversary tactics, techniques, and procedures (TTPs) related to persistence, as outlined in the MITRE ATT&CK framework. + + +*False positive analysis* + + +- Scheduled jobs created by CCleaner for crash reporting can trigger false positives. Exclude the path "?:\Windows\Tasks\CCleanerCrashReporting.job" when the process executable is "?:\Program Files\CCleaner\CCleaner64.exe". +- ManageEngine UEMS Agent and DesktopCentral Agent may create scheduled jobs for updates, leading to false positives. Exclude the path "?:\Windows\Tasks\DCAgentUpdater.job" when the process executable is "?:\Program Files (x86)\ManageEngine\UEMS_Agent\bin\dcagentregister.exe" or "?:\Program Files (x86)\DesktopCentral_Agent\bin\dcagentregister.exe". +- Regularly review and update exclusion lists to ensure they reflect the current environment and legitimate software behavior. +- Consider implementing a whitelist of known legitimate processes and paths to further reduce false positives while maintaining effective threat detection. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious scheduled jobs and limit lateral movement. +- Terminate any suspicious processes associated with the identified scheduled job, using tools like Task Manager or PowerShell, to halt any ongoing malicious activity. +- Delete the suspicious scheduled job file from the system to prevent future execution. This can be done using the Task Scheduler or command-line tools. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) solutions to identify and remove any additional malicious files or remnants. +- Review and audit other scheduled tasks on the system to ensure no additional unauthorized or suspicious jobs are present. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected. +- Implement enhanced monitoring and alerting for scheduled job creation activities across the network to detect similar threats in the future, leveraging the specific query fields used in the detection rule. + +==== 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-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + file.path : "?:\\Windows\\Tasks\\*" and file.extension : "job" and + not ( + ( + process.executable : "?:\\Program Files\\CCleaner\\CCleaner64.exe" and + file.path : "?:\\Windows\\Tasks\\CCleanerCrashReporting.job" + ) or + process.executable : ( + "?:\\Program Files (x86)\\DesktopCentral_Agent\\bin\\dcagentregister.exe", + "?:\\Program Files (x86)\\epson\\Epson Scan 2\\Update\\e_dtsksd.exe", + "?:\\Program Files (x86)\\ManageEngine\\UEMS_Agent\\bin\\dcagentregister.exe", + "?:\\Program Files (x86)\\ManageEngine\\UEMS_Agent\\dcconfig.exe", + "?:\\Program Files (x86)\\ManageEngine\\UEMS_Agent\\Updates\\UemsComponentUpgrader.exe", + "?:\\Program Files (x86)\\Skillbrains\\Updater\\*\\Updater.exe", + "?:\\Windows\\System32\\drivers\\RivetNetworks\\Killer\\CustomizeInstallFirstRun.exe" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-php-file-creation-in-wordpress-plugin-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-php-file-creation-in-wordpress-plugin-directory.asciidoc new file mode 100644 index 0000000000..b8cb6ee3db --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-php-file-creation-in-wordpress-plugin-directory.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-29-php-file-creation-in-wordpress-plugin-directory]] +=== PHP File Creation in WordPress Plugin Directory + +Detects the creation of a PHP file in the WordPress plugin directory, which is a common technique used by attackers to establish persistence on a compromised web server. Attackers may upload a malicious PHP file and call it from a web browser to gain remote access to the server. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/Icex0/wp2shell-poc + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating PHP File Creation in WordPress Plugin Directory* + + +This alert flags a new or modified PHP file under a WordPress plugin folder when it was written by a web server, PHP handler, shell, or download utility. That matters because attackers often hide webshells or rogue plugin code there to survive on a compromised site and run commands remotely. A common pattern is exploiting a vulnerable plugin to upload a backdoor into wp-content/plugins and then calling it from a browser. + + +*Possible investigation steps* + + +- Determine whether the new PHP file is part of a legitimate plugin installation or update by comparing its path, filename, hash, and timestamp against the official plugin package and your deployment records. +- Review the file contents for common webshell indicators such as obfuscation, eval or base64_decode chains, command execution functions, upload handlers, or hardcoded external URLs, and extract any indicators for broader searching. +- Correlate the write time with web access logs and WordPress or PHP logs to identify the originating HTTP request, source IP, authenticated user, target endpoint, and any upload or admin action that preceded the file creation. +- Trace the creating activity through parent and child processes, execution user, working directory, and any concurrent shell or download activity to separate expected maintenance from exploitation or post-compromise staging. +- Inspect the rest of the WordPress environment for related signs of compromise, including other newly modified plugin or theme files, unexpected administrator accounts, suspicious scheduled tasks, dropped archives, or unusual outbound connections. + + +*False positive analysis* + + +- A legitimate WordPress plugin installation or update can create or modify PHP files under `wp-content/plugins` through the normal web application update flow; verify the file path, name, hash, and timestamp match an approved plugin package and any recent administrator update activity. +- Authorized maintenance such as restoring a plugin from backup or deploying plugin code with `bash`, `sh`, `curl`, or `wget` can also trigger this alert; verify the process lineage and maintenance records show an expected bulk file change rather than an isolated unfamiliar PHP file. + + +*Response and remediation* + + +- Isolate the affected web server or container from the network and disable external access to the compromised WordPress site while preserving the malicious PHP file, related plugin directories, and relevant logs for evidence. +- Remove attacker persistence by deleting the malicious PHP file and any companion backdoors, rogue plugins, modified `.htaccess` entries, cron jobs, systemd timers, SSH keys, or unauthorized WordPress administrator accounts created during the intrusion. +- Reset exposed secrets by rotating WordPress admin passwords, hosting control panel credentials, SSH keys, database passwords, API tokens, and session cookies that may have been accessed from the compromised host. +- Restore the site from a known-good backup or redeploy the affected plugin and WordPress core from trusted packages, then verify hashes and review `wp-content/plugins`, `wp-content/themes`, and `uploads` for any remaining unauthorized PHP files or recent modifications. +- Escalate to incident response immediately if the webshell executed commands, multiple hosts show similar plugin-directory writes, sensitive data may have been accessed, or the attacker obtained root privileges, and expand scoping across reverse proxy, WAF, database, and authentication logs. +- Harden the environment by patching the exploited plugin or WordPress version, removing unused plugins, enforcing least-privilege write access so the web server cannot write to plugin directories, enabling MFA for administrators, and adding monitoring for new executable files under web content. + + +==== 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.type in ("creation", "change") and ( + process.name in ( + "nginx", "apache2", "httpd", "php-cgi", "php-fcgi", "php-cgi.cagefs", "sw-engine-fpm", + "wget", "curl", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh", "busybox" + ) or + process.name like ("php-fpm*", "lsphp*", "*.cgi", "*.fcgi") +) and +file.path like~ "*/wp-content/plugins/*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-postgresql-copy-program-command-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-postgresql-copy-program-command-execution.asciidoc new file mode 100644 index 0000000000..addac12a55 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-postgresql-copy-program-command-execution.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-29-postgresql-copy-program-command-execution]] +=== PostgreSQL COPY PROGRAM Command Execution + +Identifies PostgreSQL "COPY" statements that invoke an operating-system command through the "PROGRAM" option. A superuser or role with "pg_execute_server_program" can use this feature to execute arbitrary commands as the PostgreSQL service account, a technique used after credential compromise and by cryptomining campaigns. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.pgsql-* + +*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.postgresql.org/docs/current/sql-copy.html +* https://www.aquasec.com/blog/pg_mem-a-malware-hidden-in-the-postgres-processes/ +* https://www.wiz.io/blog/postgresql-cryptomining +* https://attack.mitre.org/techniques/T1059/ + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Network Packet Capture +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating PostgreSQL COPY PROGRAM Command Execution* + + +PostgreSQL supports `COPY ... FROM PROGRAM` and `COPY ... TO PROGRAM` for server-side process execution. Attackers who obtain a privileged database identity can use this feature to launch shells, download payloads, establish persistence, or deploy cryptominers from the PostgreSQL process context. + + +*Possible investigation steps* + + +- Review `client.ip`, `server.ip`, `network.community_id`, `network_traffic.pgsql.query`, and PostgreSQL error fields. +- Extract the command passed to `PROGRAM` and identify referenced shells, interpreters, downloaders, files, or network destinations. +- Confirm the database role and whether it has superuser or `pg_execute_server_program` privileges using PostgreSQL audit and server logs. +- Correlate the event with endpoint telemetry for `postgres` spawning `sh`, `bash`, `curl`, `wget`, `python`, `perl`, `nc`, miners, or other unusual child processes. +- Search earlier events from the client for authentication failures, role changes, extension creation, or database enumeration. + + +*False positive analysis* + + +- Approved ETL, backup, and administrative automation can use COPY PROGRAM. +- Scope exceptions to a documented client, command family, and maintenance context; do not globally exclude the `PROGRAM` keyword. + + +*Response and remediation* + + +- Terminate the database session and isolate the server if unauthorized process execution is confirmed. +- Preserve PostgreSQL, endpoint, and network evidence and remove malicious processes or persistence. +- Rotate affected credentials and revoke unnecessary superuser and `pg_execute_server_program` privileges. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Network Packet Capture integration with the PostgreSQL protocol analyzer enabled and +cleartext visibility into PostgreSQL query traffic. TLS-encrypted sessions, prepared statements, packet loss, and +asymmetric capture can hide or fragment query text. Use PostgreSQL audit logs and endpoint process telemetry to confirm +the database identity and command execution outcome. + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "network_traffic.pgsql" and + ( + network_traffic.pgsql.query like~ "*copy*from*program*" or + network_traffic.pgsql.query like~ "*copy*to*program*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-computer-account-ntlm-relay-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-computer-account-ntlm-relay-activity.asciidoc new file mode 100644 index 0000000000..686bf636de --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-computer-account-ntlm-relay-activity.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-29-potential-computer-account-ntlm-relay-activity]] +=== Potential Computer Account NTLM Relay Activity + +Identifies potential relay activities against a Computer account by identifying authentication events using the computer account coming from from hosts other than the server that owns the account. Attackers may relay the computer account hash after capturing it using forced authentication. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/p0dalirius/windows-coerced-authentication-methods +* https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications +* https://attack.mitre.org/techniques/T1187/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Active Directory +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Computer Account NTLM Relay Activity* + + + +*Possible investigation steps* + + +- Compare the source.ip to the target server host.ip addresses to make sure it's indeed a remote use of the machine account. +- Examine the source.ip activities as this is the attacker IP address used to relay. +- Review all relevant activities such as services creation, file and process events on the target server within the same period. +- Verify the machine account names that end with a dollar sign ($) to ensure they match the expected hostnames, and investigate any discrepancies. +- Check the network logon types to confirm if they align with typical usage patterns for the identified machine accounts. +- Investigate the context of the source IP addresses that do not match the host IP, looking for any signs of unauthorized access or unusual network activity. +- Correlate the findings with other security logs and alerts to identify any patterns or additional indicators of compromise related to the potential relay attack. + + +*False positive analysis* + + +- Machine accounts performing legitimate network logons from different IP addresses can trigger false positives. To manage this, identify and whitelist known IP addresses associated with legitimate administrative tasks or automated processes. +- Scheduled tasks or automated scripts that use machine accounts for network operations may be flagged. Review and document these tasks, then create exceptions for their associated IP addresses and hostnames. +- Load balancers or proxy servers that alter the source IP address of legitimate authentication requests can cause false alerts. Ensure these devices are accounted for in the network architecture and exclude their IP addresses from the rule. +- Temporary network reconfigurations or migrations might result in machine accounts appearing to log in from unexpected hosts. During such events, temporarily adjust the rule parameters or disable the rule to prevent unnecessary alerts. +- Regularly review and update the list of exceptions to ensure they reflect current network configurations and operational practices, minimizing the risk of overlooking genuine threats. + + +*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. + - If the involved server is a Domain Controller, coordinate the isolation of the server with infrastructure and identity teams to contain the threat while preserving service availability and forensic evidence. Prioritize this step if active compromise or attacker persistence is confirmed. +- Reset the domain controller's machine account password, along with any accounts suspected to be compromised or exposed. Ensure strong, unique credentials are used and apply tiered credential hygiene where applicable. +- Analyze recent authentication logs, event logs, and network traffic, focusing on suspicious activity and the source IPs referenced in the alert. Correlate findings to identify any lateral movement or additional compromised systems. +- Strengthen network segmentation, especially between domain controllers, administrative workstations, and critical infrastructure. This limits the attack surface and impedes credential relay or reuse across systems. +- Escalate the incident to the SOC or incident response team to coordinate a full investigation, containment, and recovery plan. Ensure stakeholders are kept informed throughout the response. +- Enhance detection mechanisms by tuning alerts and deploying additional telemetry focused on credential relay patterns, anomalous authentication, and NTLM-related activity. +- Conduct a structured post-incident review, documenting findings, identifying control gaps, and updating playbooks, configurations, or security policies to reduce the likelihood of similar incidents in the future. + + +==== Setup + + + +*Setup* + + +Audit Logon must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-logon + + +==== Rule query + + +[source, js] +---------------------------------- +authentication where host.os.type == "windows" and event.code in ("4624", "4625") and + winlog.logon.type == "Network" and winlog.event_data.AuthenticationPackageName == "NTLM" and + endswith~(user.name, "$") and user.name != "$" and + source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1" and + + /* Filter for a machine account that matches the hostname */ + startswith~(host.name, substring(user.name, 0, -1)) and + + /* Verify the machine account matches the full hostname, not just a prefix substring */ + (length(host.name) == length(user.name) - 1 or substring(host.name, length(user.name) - 1, length(user.name)) == ".") and + + /* Verify if the Source IP belongs to the host */ + not endswith(string(source.ip), string(host.ip)) and + indexOf(string(host.ip), string(source.ip)) == null + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Forced Authentication +** ID: T1187 +** Reference URL: https://attack.mitre.org/techniques/T1187/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Sub-technique: +** Name: LLMNR/NBT-NS Poisoning and SMB Relay +** ID: T1557.001 +** Reference URL: https://attack.mitre.org/techniques/T1557/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-credential-access-via-dcsync.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-credential-access-via-dcsync.asciidoc new file mode 100644 index 0000000000..7e91afe531 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-credential-access-via-dcsync.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-29-potential-credential-access-via-dcsync]] +=== Potential Credential Access via DCSync + +This rule identifies when a User Account starts the Active Directory Replication Process. Attackers can use the DCSync technique to get credential information of individual accounts or the entire domain, thus compromising the entire domain. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://threathunterplaybook.com/notebooks/windows/06_credential_access/WIN-180815210510.html +* https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing +* https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_ad_replication_non_machine_account.yml +* https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0027_windows_audit_directory_service_access.md +* https://attack.stealthbits.com/privilege-escalation-using-mimikatz-dcsync +* https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Privilege Escalation +* Data Source: Active Directory +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs + +*Version*: 222 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Credential Access via DCSync* + + +Active Directory replication is the process by which the changes that originate on one domain controller are automatically transferred to other domain controllers that store the same data. + +Active Directory data consists of objects that have properties, or attributes. Each object is an instance of an object class, and object classes and their respective attributes are defined in the Active Directory schema. Objects are defined by the values of their attributes, and changes to attribute values must be transferred from the domain controller on which they occur to every other domain controller that stores a replica of an affected object. + +Adversaries can use the DCSync technique that uses Windows Domain Controller's API to simulate the replication process from a remote domain controller, compromising major credential material such as the Kerberos krbtgt keys used legitimately for tickets creation, but also tickets forging by attackers. This attack requires some extended privileges to succeed (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All), which are granted by default to members of the Administrators, Domain Admins, Enterprise Admins, and Domain Controllers groups. Privileged accounts can be abused to grant controlled objects the right to DCsync/Replicate. + +More details can be found on https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing[Threat Hunter Playbook] and https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync[The Hacker Recipes]. + +This rule monitors for Event ID 4662 (Operation was performed on an Active Directory object) and identifies events that use the access mask 0x100 (Control Access) and properties that contain at least one of the following or their equivalent Schema-Id-GUID (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, DS-Replication-Get-Changes-In-Filtered-Set). It also filters out events that use computer accounts and also Azure AD Connect MSOL accounts (more details https://techcommunity.microsoft.com/t5/microsoft-defender-for-identity/ad-connect-msol-user-suspected-dcsync-attack/m-p/788028[here]). + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account and system owners and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Correlate security events 4662 and 4624 (Logon Type 3) by their Logon ID (`winlog.logon.id`) on the Domain Controller (DC) that received the replication request. This will tell you where the AD replication request came from, and if it came from another DC or not. +- Scope which credentials were compromised (for example, whether all accounts were replicated or specific ones). + + +*False positive analysis* + + +- Administrators may use custom accounts on Azure AD Connect, investigate if it is the case, and if it is properly secured. If noisy in your environment due to expected activity, consider adding the corresponding account as a exception. +- Although replicating Active Directory (AD) data to non-Domain Controllers is not a common practice and is generally not recommended from a security perspective, some software vendors may require it for their products to function correctly. If this rule is noisy in your environment due to expected activity, consider adding the corresponding account as a exception. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the 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. +- If the entire domain or the `krbtgt` user was compromised: + - Activate your incident response plan for total Active Directory compromise which should include, but not be limited to, a password reset (twice) of the `krbtgt` user. +- Investigate how the attacker escalated privileges and identify systems they used to conduct lateral movement. Use this information to determine ways the attacker could regain access to the environment. +- 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* + + +Audit Directory Service Access must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-access + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:"windows" and event.code:"4662" and + winlog.event_data.Properties:( + *DS-Replication-Get-Changes* or *DS-Replication-Get-Changes-All* or + *DS-Replication-Get-Changes-In-Filtered-Set* or *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2* or + *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2* or *89e95b76-444d-4c62-991a-0facbeda640c* + ) and winlog.event_data.AccessMask : "0x100" and + not winlog.event_data.SubjectUserName:(*$ or MSOL_*) and + not winlog.event_data.SubjectUserSid:"S-1-0-0" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: DCSync +** ID: T1003.006 +** Reference URL: https://attack.mitre.org/techniques/T1003/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Domain Accounts +** ID: T1078.002 +** Reference URL: https://attack.mitre.org/techniques/T1078/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-credential-access-via-windows-utilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-credential-access-via-windows-utilities.asciidoc new file mode 100644 index 0000000000..8d52c146ea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-credential-access-via-windows-utilities.asciidoc @@ -0,0 +1,216 @@ +[[prebuilt-rule-8-19-29-potential-credential-access-via-windows-utilities]] +=== Potential Credential Access via Windows Utilities + +Identifies the execution of known Windows utilities often abused to dump LSASS memory or the Active Directory database (NTDS.dit) in preparation for credential access. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* 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/ +* https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon + +*Version*: 322 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Credential Access via Windows Utilities* + + + +*Possible investigation steps* + + +- Which utility path did the alert take, and is the binary identity credible? + - Focus: `process.name`, `process.pe.original_file_name`, `process.executable`, `process.command_line`, and `process.code_signature.subject_name`. + - Implication: escalate faster when the alert path is a dump-capable utility from a user-writable, renamed, missing expected signer, or unexpected location; lower suspicion only when the utility family, signer, installed path, and command pattern fit one recognized diagnostic, SQL troubleshooting, crash-triage, or AD maintenance workflow. Identity alone does not clear the behavior. + +- Do the arguments identify a credential-dump objective? + - Focus: `process.command_line`: credential target, dump mode, script path, and output location. + - Hint: high-risk examples include "procdump -ma lsass.exe", Rundll32/comsvcs MiniDump, ntdsutil IFM output, and "diskshadow.exe /s" scripts that expose, copy, exec, or delete shadow-copy paths. + - Implication: escalate when arguments target LSASS, invoke Rundll32/comsvcs dumping, create NTDS/IFM output, drive VSS script execution, or write to user-writable or share paths; lower suspicion when the target is clearly non-credential and the output path matches the same recognized troubleshooting or backup workflow. + +- Does the parent chain explain why this host would run a dump or snapshot utility? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.ancestry`, and `process.Ext.session_info.logon_type`, with `user.id` defining the actor scope. + - Implication: escalate when the chain starts from shells, script hosts, Office processes, unexpected services, scheduled tasks, or remote-interactive sessions; lower suspicion only when the same actor, session type, and parent workflow explain the utility launch and do not conflict with command intent. + +- If file telemetry is available, did the utility create dump, shadow-copy, or directory database artifacts? + - Focus: recover file events with `host.id` + `process.entity_id`; if `process.entity_id` is missing, use `host.id` + `process.pid` + a tight alert window, then review `file.path`, `file.Ext.original.path`, and `file.Ext.header_bytes` for dump files, copied directory-database material, IFM folders, registry hives, shadow-copy output, or archive staging. !{investigate{"description":"","label":"File activity for the alerting process and children","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":"file","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":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when artifacts show LSASS dumps, AD database or credential-hive collection, shadow-copy access, or staged archives; close cannot rely on absent file events because missing file telemetry is unresolved, not benign. + +- Do child processes or connection events show collected material being staged or exported? + - Focus: child process starts, file activity, and network activity where `process.parent.entity_id` matches the alerting `process.entity_id` on `host.id`; if network telemetry is available, review `destination.ip`, `destination.port`, and `network.direction`. !{investigate{"description":"","label":"Child processes of the alerting process","providers":[[{"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"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Network activity for the alerting process and children","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"}],[{"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":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if the utility spawns a short-lived archiver or copy tool, pivot from that child into same-host connection events before broadening. + - Implication: escalate when the utility or child process spawns archivers, copy tools, "diskshadow.exe" exec children, or transfers dump material off-host; missing network telemetry is unresolved, not benign. + +- If local findings remain suspicious or unresolved, do related alerts show broader credential-access activity? + - Focus: related alerts for `user.id` covering dumping, privilege escalation, lateral movement, archiving, or staging. !{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"}} + - Hint: if the actor view is sparse, pivot to related alerts for `host.id` covering precursor access, persistence, archiving, or exfiltration. !{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 when either view shows a credential-access chain or reuse of the same utility pattern; do not close solely because related alerts are absent if command intent, artifacts, lineage, or post-dump cleanup remain suspicious. + +- Disposition: escalate when utility identity, command intent, lineage, artifacts, staging, or related scope indicate credential access; close only when identity, arguments, lineage, recovered artifacts, and supported scope all align with one recognized diagnostic, troubleshooting, crash-triage, backup, or IFM workflow; preserve artifacts and escalate when evidence is mixed or visibility is incomplete. + + +*False positive analysis* + + +- Recognized crash-triage, SQL troubleshooting, AD backup, or IFM workflows can trigger this rule. Confirm the same workflow across identity (`process.executable`, `process.code_signature.subject_name`), lineage (`process.parent.executable`), intent (`process.command_line`), actor/scope (`user.id`, `host.id`), and recovered artifact paths when available. Case records may corroborate the workflow, but do not close on recurrence alone; use prior alerts only after current telemetry aligns. +- Build exceptions only from the confirmed recurring workflow: `process.executable`, `process.code_signature.subject_name`, `process.parent.executable`, stable `process.command_line`, `user.id`, `host.id`, and recovered output path or dump-directory pattern when available. Avoid exceptions on `process.name`, `host.id`, utility family, or generic dump switches alone. + + +*Response and remediation* + + +- If confirmed benign, record the recognized diagnostic, backup, or directory-services evidence in `process.executable`, `process.command_line`, `process.parent.executable`, `user.id`, `host.id`, and recovered output paths when available, then reverse any temporary containment. Create an exception only if that same pattern recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the recovered `process.entity_id` or `process.pid` with `host.id` and time, `process.command_line`, script-file, dump, shadow-copy, and copied-database paths, child-process lineage via `process.parent.entity_id` / `process.parent.pid`, and any confirmed destination pairs before making destructive changes. Apply reversible containment first, such as temporary destination blocking or increased monitoring on the affected `host.id` and `user.id`. Escalate to host isolation only if dump material, IFM output, or staging transfers are confirmed and the host can tolerate interruption. +- If confirmed malicious, use endpoint response actions to isolate the host and terminate the dump or staging process after preserving `process.entity_id`, `process.parent.entity_id`, `process.command_line`, recovered output paths, any available `process.hash.sha256`, and confirmed destinations. If direct endpoint response is unavailable, hand off that artifact set immediately to the team that can isolate the system or block the destinations. +- If LSASS dumping is confirmed, assume exposure for all accounts with active sessions on the affected host, including interactive, service, and cached credentials. Prioritize resets for privileged, service, and lateral-movement-relevant accounts and review whether the dump material was staged or transferred before containment. +- If NTDS access or dump activity is confirmed on a domain controller, activate the organization's Active Directory compromise response plan, preserve the evidence needed to scope database and credential exposure, and begin privileged-account hygiene based on the systems and accounts implicated by the investigation before deleting copied database material. +- Review related hosts and users for the same `process.command_line` patterns, dump-file naming patterns, `process.parent.executable`, and confirmed destinations before deleting dump files, IFM output, shadow copies, utilities, or persistence mechanisms uncovered during the investigation, then remediate the delivery or privilege path that allowed the utility to run. + + +==== 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] +- 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.pe.original_file_name : "procdump" or process.name : "procdump.exe") and process.args : "-ma" + ) or + ( + process.name : "ProcessDump.exe" and not process.parent.executable regex~ """C:\\Program Files( \(x86\))?\\Cisco Systems\\.*""" + ) or + ( + (?process.pe.original_file_name : "WriteMiniDump.exe" or process.name : "WriteMiniDump.exe") and + not process.parent.executable regex~ """C:\\Program Files( \(x86\))?\\Steam\\.*""" + ) or + ( + (?process.pe.original_file_name : "RUNDLL32.EXE" or process.name : "RUNDLL32.exe") and + ( + process.args : "*MiniDump*" or + process.command_line : ("*comsvcs*#*24*", "*#*24* full*", "*comsvcs*24* full*") + ) + ) or + ( + (?process.pe.original_file_name : "RdrLeakDiag.exe" or process.name : "RdrLeakDiag.exe") and + process.args : "/fullmemdmp" + ) or + ( + (?process.pe.original_file_name : "SqlDumper.exe" or process.name : "SqlDumper.exe") and + process.args : "0x01100*") or + ( + (?process.pe.original_file_name : "TTTracer.exe" or process.name : "TTTracer.exe") and + process.args : "-dumpFull" and process.args : "-attach") or + ( + (?process.pe.original_file_name : "ntdsutil.exe" or process.name : "ntdsutil.exe") and + process.args : "cr*fu*") or + ( + (?process.pe.original_file_name : "diskshadow.exe" or process.name : "diskshadow.exe") and process.args : "/s") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ +* Sub-technique: +** Name: NTDS +** ID: T1003.003 +** Reference URL: https://attack.mitre.org/techniques/T1003/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-data-exfiltration-through-curl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-data-exfiltration-through-curl.asciidoc new file mode 100644 index 0000000000..7dcb17e23b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-data-exfiltration-through-curl.asciidoc @@ -0,0 +1,219 @@ +[[prebuilt-rule-8-19-29-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*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating 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-29/prebuilt-rule-8-19-29-potential-edr-freeze-via-werfaultsecure-abuse.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-edr-freeze-via-werfaultsecure-abuse.asciidoc new file mode 100644 index 0000000000..1d6269a609 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-edr-freeze-via-werfaultsecure-abuse.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-29-potential-edr-freeze-via-werfaultsecure-abuse]] +=== Potential EDR-Freeze via WerFaultSecure Abuse + +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. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* + +*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.zerosalarium.com/2025/09/EDR-Freeze-Puts-EDRs-Antivirus-Into-Coma.html +* https://binarydefense.com/resources/blog/dont-freeze-me-out-bro-arc-labs-technical-analysis-of-edr-freeze +* https://www.bleepingcomputer.com/news/security/new-edr-freeze-tool-uses-windows-wer-to-suspend-security-software/ + +*Tags*: + +* 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 + +*Version*: 1 + +*Rule authors*: + +* Aryu Zaw + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential EDR-Freeze via WerFaultSecure Abuse* + + +`WerFaultSecure.exe` is the Protected Process Light (PPL) variant of Windows Error Reporting, normally launched by the WER service hosted in `svchost.exe` to capture secure crash dumps of protected processes. Because it runs as a PPL and can read the memory of other protected processes, adversaries abuse it to dump or freeze security software. + +In the EDR-Freeze technique, an attacker starts `WerFaultSecure.exe` from their own process and directs it to dump a security process (for example `MsMpEng.exe`). `MiniDumpWriteDump` suspends every thread of the target while the dump is produced; the attacker then suspends `WerFaultSecure.exe` itself at that moment, leaving the EDR or antivirus frozen in a "coma" without ever terminating it, so traditional process-termination and tamper alerts never fire. + +This rule identifies `WerFaultSecure.exe` started by a parent other than the WER service with command-line arguments characteristic of a secure process memory dump (`/pid` and `/encfile`). Legitimate secure dumps are initiated by the WER service, so an abnormal parent process is the primary signal of abuse. + + +*Possible investigation steps* + + +- Identify the parent process via `process.parent.name`, `process.parent.executable`, and `process.parent.command_line`. Launches from shells, scripting engines, `rundll32.exe`, or unsigned binaries in user-writable paths are highly suspicious. +- Resolve the target process from the `/pid` argument value and determine whether it corresponds to a security product (EDR or antivirus such as `MsMpEng.exe`), `lsass.exe`, or another sensitive process. +- Review the full command line for the dump-type value (the public proof of concept uses `/type 268310`, a full dump) and for the `/cancel` event handle, which together with `/encfile` indicate a full secure memory dump. +- Look for a ProcessAccess event (Sysmon Event ID 10) or an Elastic Defend API event in which `WerFaultSecure.exe` is opened with `PROCESS_SUSPEND_RESUME` (access mask `0x800` / `2048`) by a non-WER process shortly after this execution. This is the act that freezes the dumper and keeps the target suspended. +- Check whether the targeted security agent stopped reporting telemetry (a heartbeat gap) around the time of the alert. +- Examine the parent process for prevalence, code signature, on-disk location, and any preceding download, injection, or privilege-escalation activity. +- Review activity for the user and host over the preceding 24-48 hours for related defense-evasion, credential-access, or lateral-movement behavior. + + +*False positive analysis* + + +- This activity is highly unusual: secure WER dumps are normally initiated by the WER service in `svchost.exe`, not by interactive or third-party processes, so benign matches are rare. +- Specialized crash-analysis, debugging, or enterprise diagnostics tooling could invoke `WerFaultSecure.exe` directly. If such a tool is confirmed and authorized, add an exception scoped to its `process.parent.executable` and code signature. + + +*Response and remediation* + + +- Isolate the affected host to prevent further post-compromise activity while the EDR or antivirus may be suspended. +- Verify the state of the targeted security agent and restart or resume it, then confirm that protection and telemetry have been restored. +- Terminate the suspicious `WerFaultSecure.exe` process and its parent, preserving command lines, handles, and any dump files for analysis. +- Investigate the parent process and its origin to determine the initial access vector and scope of compromise, and search the environment for the same parent binary or behavior on other hosts. +- Reset credentials that may have been exposed while the security agent was disabled, and run a full scan once protection is restored. +- Escalate to incident response when the targeted process is a security control, as a successful freeze indicates a hands-on-keyboard defense-evasion attempt. + + +==== 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.executable : "?:\\Windows\\System32\\WerFaultSecure.exe" and + + /* WerFaultSecure secure dumps are normally initiated by the WER service hosted in svchost.exe */ + process.parent.executable != null and + not process.parent.executable : ("?:\\Windows\\System32\\svchost.exe", "?:\\Windows\\System32\\wermgr.exe", "?:\\Windows\\System32\\WerFault.exe", "?:\\Windows\\System32\\WerFaultSecure.exe") and + + /* arguments used to take a secure memory dump of a target process (e.g. /pid /encfile /type 268310) */ + process.args : "/pid" and process.args : "/encfile" + +---------------------------------- + +*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-29/prebuilt-rule-8-19-29-potential-lateral-tool-transfer-via-smb-share.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-lateral-tool-transfer-via-smb-share.asciidoc new file mode 100644 index 0000000000..d3f0b73cf1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-lateral-tool-transfer-via-smb-share.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-29-potential-lateral-tool-transfer-via-smb-share]] +=== Potential Lateral Tool Transfer via SMB Share + +Identifies the creation or change of a Windows executable file over network shares. Adversaries may transfer tools or other files between systems in a compromised environment. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* 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.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper +* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Lateral Tool Transfer via SMB Share* + + +Adversaries can use network shares to host tooling to support the compromise of other hosts in the environment. These tools can include discovery utilities, credential dumpers, malware, etc. Attackers can also leverage file shares that employees frequently access to host malicious files to gain a foothold in other machines. + + +*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. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Retrieve the created file and determine if it is 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. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled task creation. + - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity can happen legitimately. Consider adding exceptions if it is expected and noisy in your environment. + + +*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. +- Review the privileges needed to write to the network share and restrict write access as needed. +- 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 + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=30s + [network where host.os.type == "windows" and event.type == "start" and process.pid == 4 and destination.port == 445 and + network.direction : ("incoming", "ingress") and + network.transport == "tcp" and source.ip != "127.0.0.1" and source.ip != "::1" + ] by process.entity_id + /* add more executable / script extensions here if they are not noisy in your environment */ + [file where host.os.type == "windows" and event.type in ("creation", "change") and process.pid == 4 and user.id like ("S-1-5-21*", "S-1-12-*") and + (file.Ext.header_bytes : "4d5a*" or file.extension : ("exe", "scr", "pif", "com", "dll", "bat", "cmd", "ps1", "vbs", "vbe", "js", "jse", "wsh", "wsf", "sct", "hta", "cpl")) and + not file.path : ( + "?:\\Windows\\VeeamVssSupport\\*", + "?:\\Windows\\VeeamLogShipper\\*" + )] by process.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ +* Technique: +** Name: Lateral Tool Transfer +** ID: T1570 +** Reference URL: https://attack.mitre.org/techniques/T1570/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-ssh-reverse-port-forwarding.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-ssh-reverse-port-forwarding.asciidoc new file mode 100644 index 0000000000..ac7afb2adc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-ssh-reverse-port-forwarding.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-29-potential-ssh-reverse-port-forwarding]] +=== Potential SSH Reverse Port Forwarding + +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. + +*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*: 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://thedfirreport.com/2025/11/04/from-bing-search-to-ransomware-bumblebee-and-adaptixc2-deliver-akira-2/ +* https://thedfirreport.com/2023/10/30/netsupport-intrusion-results-in-domain-compromise/ +* https://x.com/Securityinbits/status/2067602540209021196 + +*Tags*: + +* 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 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential SSH Reverse Port Forwarding Detected* + + + +*Possible investigation steps* + + +- What reverse-forward command triggered the alert? + - Focus: `@timestamp`, `host.id`, `user.name`, `process.name`, `process.command_line` + - Implication: Confirm via !{investigate{"description":"Recover the process start event and immediate process context for the alerted OpenSSH or Plink reverse-forward command.","label":"Matched process context","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"}]],"relativeFrom":"now-1h","relativeTo":"now"}} a process start for `ssh.exe` or `plink.exe`/Plink with the matched `-R` or `RemoteForward` artifact. Suspicious when the command exposes an internal service or SOCKS listener without host/account owner confirmation; close only when command, host, account, parent, and remote-forward values match a recognized recurring tunnel workflow for this account. +- Is the process lineage and executable consistent with the expected workflow? + - Focus: `process.parent.command_line`, `process.executable`, `process.hash.sha256`, `process.working_directory`, `process.Ext.relative_file_creation_time` + - Implication: Via !{investigate{"description":"Recover the process start event and immediate process context for the alerted OpenSSH or Plink reverse-forward command.","label":"Matched process context","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"}]],"relativeFrom":"now-1h","relativeTo":"now"}}, compare parent, path, hash, and file age. Escalate when shells, script interpreters, unusual parents, recently created binaries, or a Plink original name under another process name appear; benign requires the same artifact and parent tied to the verified host/account reverse-forward workflow. +- Is the tunnel active or recurring on this host? + - Focus: `host.id`, `process.entity_id`, `process.pid`, `process.uptime`, `process.exit_code` + - Implication: Use !{investigate{"description":"Find other process events with the same alerted process name on the same host for local recurrence and parent/account comparison.","label":"Same host process launches","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"{{process.name}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} to check whether the SSH/Plink process remained running, exited, or relaunched with reverse-forward arguments. Recurring or long-lived commands outside a confirmed window are suspicious; a single exited process supports closure only with owner confirmation and no unresolved process or network evidence. +- What remote SSH server and exposed service are implied? + - Focus: `process.args`, `process.command_line`, `destination.ip`, `destination.port`, `network.direction` + - Implication: Parse `-R`/`RemoteForward` syntax, then recover same-process connection events if network telemetry exists; `destination.*` and `network.*` are connection-event fields not present on the process alert. Missing network telemetry is unresolved, not benign. Escalate when the remote host, port, or exposed service does not match the confirmed workflow. +- Where else does the same binary or reverse-forward pattern appear? + - Focus: `process.hash.sha256`, `process.name`, `host.name`, `user.name`, `process.command_line` + - Implication: Use !{investigate{"description":"Find other events for the same executable hash to scope repeated use of the matched OpenSSH or Plink binary after local validation.","label":"Executable hash scope","providers":[[{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}]],"relativeFrom":"now-7d","relativeTo":"now"}} to scope the same hash, comparing command lines for `-R`/`RemoteForward` on other hosts/accounts. Absence of matches is not benign; broaden containment when the artifact appears beyond the source host/account. Close recurrence only when each match ties to the same confirmed workflow. + +Disposition: Escalate suspicious or unresolved commands; close only when alert-local and recovered evidence confirm the exact host/account/process/remote-forward scope; preserve and escalate mixed cases. + + +*False positive analysis* + + +- Benign activity is limited to a confirmed reverse SSH forwarding workflow where `process.command_line`, `host.id`, `user.name`, parent process, executable, remote server, and forward port are verified. +- Do not close because the binary is named `ssh.exe`/`plink.exe`, has a familiar path, or a trusted signature — the matched command and owner workflow must explain the `-R`/`RemoteForward` artifact. +- Scope exceptions to `host.id`, `user.name`, `process.executable` or `process.hash.sha256`, `process.parent.executable` or `process.parent.command_line`, and the exact reverse-forward args. Do not suppress all reverse forwarding across hosts or accounts. + + +*Response and remediation* + + +- Scope first by reviewing the exact command, same-process network evidence, same executable hash, same user/host activity, and related alerts for the same remote SSH server or port before cleanup. +- Preserve or export case evidence plus volatile process, memory, executable, and file-system artifacts before isolation, process termination, or other disruptive action. +- After evidence capture, use reversible containment such as isolating the affected host or blocking egress to the confirmed SSH server/port while credential and session review proceeds. +- For confirmed malicious tunneling, terminate the SSH/Plink process, remove persistence or scripts that launched it, rotate exposed credentials, and clean staged binaries only after scoping. +- Record confirmed indicators and logging or detection gaps for the responsible detection or logging owners after containment. + + +==== 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 : ("ssh.exe", "plink.exe") or + ?process.pe.original_file_name : ("Plink", "plink.exe") + ) and + ( + process.args like "-R*" or + process.args : "-oRemoteForward*" or + (process.args == "-o" and process.args : "*RemoteForward*") or + + /* -R can be combined with ~20 no-arg SSH flags (e.g. -NR, -fNR) */ + process.args regex """-[46AaCfGgKkMNnqsTtVvXxYy]+R.*""" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Sub-technique: +** Name: External Proxy +** ID: T1090.002 +** Reference URL: https://attack.mitre.org/techniques/T1090/002/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-tunneling-via-tailscaled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-tunneling-via-tailscaled.asciidoc new file mode 100644 index 0000000000..436b110e41 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-potential-tunneling-via-tailscaled.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-29-potential-tunneling-via-tailscaled]] +=== Potential Tunneling via Tailscaled + +Identifies the use of Tailscaled to potentially tunnel network traffic. This can be used by attackers to enable routing of network packets that would otherwise not reach their intended destination, or to bypass network restrictions and/or hide traffic from network monitoring. + +*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-* +* auditbeat-* + +*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://huggingface.co/blog/agent-intrusion-technical-timeline + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* 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 Potential Tunneling via Tailscaled* + + +This rule flags Tailscaled starting with proxy or SOCKS tunneling options, which can turn an endpoint into a covert relay for traffic that bypasses segmentation, egress controls, and normal monitoring. An attacker with access to a Windows, Linux, or macOS host can launch tailscaled.exe with a local SOCKS5 listener, then route remote administration, reconnaissance, or data-transfer traffic through the encrypted overlay to reach systems that were not directly accessible. + + +*Possible investigation steps* + + +- Determine whether the host is approved to run Tailscale by validating the user, device owner, recent change tickets, and any sanctioned remote-access or VPN use case. +- Review the execution chain and security context, including the parent process, command lineage, account privileges, logon session, and whether a service, scheduled task, or startup item was created to keep the tunnel available. +- Identify what the tunnel exposed by enumerating local listening ports, recent inbound and outbound connections, and any access to unusual internal subnets, administrative services, or blocked destinations after the process started. +- Correlate Tailscale-specific artifacts such as the logged-in tailnet, device registration or approval events, peer list, and advertised routes or exit-node settings to determine whether the node was joined to an unauthorized overlay. +- Hunt across the environment for the same user, tailnet, binary path, hash, or command pattern and review adjacent activity on the host for follow-on actions like remote administration, lateral movement, credential access, or data staging. + + +*False positive analysis* + + +- An administrator or engineer may legitimately start tailscaled with `--socks5-server` or `--outbound-http-proxy-listen` on an approved remote-access, lab, or jump system for maintenance, so verify the user and host are authorized for Tailscale and that the command line, install path, and start time match a documented change or normal operating pattern. +- A developer or IT user may temporarily enable these proxy options to troubleshoot connectivity between managed Windows, Linux, or macOS hosts, so confirm the activity with the asset owner and review resulting connections to ensure they were limited to expected internal destinations and business-related use. + + +*Response and remediation* + + +- Isolate the affected host from the network, terminate the running `tailscaled` process, and block the observed local proxy listener and any active Tailscale peer connections to stop the tunnel. +- Remove attacker persistence by uninstalling unauthorized Tailscale components and deleting related services, scheduled tasks, LaunchDaemons, systemd units, startup items, auth keys, and Tailscale state/config files left on the host. +- Revoke the enrolled device from the tailnet, invalidate any Tailscale auth keys or SSO sessions used to register it, and reset passwords or tokens for accounts that logged on while the tunnel was active. +- Restore the system to a known-good state by reimaging or recovering from a trusted backup if you cannot fully verify what the tunnel exposed or what changes were made after `tailscaled` was launched with proxy options. +- Escalate to incident response immediately if the tunnel reached domain controllers, administrative jump hosts, sensitive data repositories, or if you identify the same tailnet, binary, or proxy command line on multiple endpoints. +- Harden the environment by restricting Tailscale installation to approved systems, enforcing application control for `tailscaled`, limiting outbound access to Tailscale coordination or relay infrastructure where not required, and alerting on new proxy listeners or unauthorized tailnet enrollments. + + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and +process.name like~ ("tailscaled", "tailscaled.exe") and +process.args like~ ("*--socks5-server*", "*--outbound-http-proxy-listen*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-spike-in-firewall-denies.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-spike-in-firewall-denies.asciidoc new file mode 100644 index 0000000000..19927857af --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-spike-in-firewall-denies.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-29-spike-in-firewall-denies]] +=== Spike in Firewall Denies + +A machine learning job detected an unusually large spike in network traffic that was denied by network access control lists (ACLs) or firewall rules. Such a burst of denied traffic is usually caused by either 1) a mis-configured application or firewall or 2) suspicious or malicious activity. Unsuccessful attempts at network transit, in order to connect to command-and-control (C2), or engage in data exfiltration, may produce a burst of failed connections. This could also be due to unusually large amounts of reconnaissance or enumeration traffic. Denial-of-service attacks or traffic floods may also produce such a surge in traffic. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Data Source: Elastic Defend +* Data Source: Network Packet Capture +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* 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 Spike in Firewall Denies* + + +Firewalls and ACLs are critical in controlling network traffic, blocking unauthorized access. Adversaries may exploit misconfigurations or launch attacks like reconnaissance or denial-of-service to overwhelm these defenses. The 'Spike in Firewall Denies' detection rule leverages machine learning to identify unusual surges in denied traffic, signaling potential misconfigurations or malicious activities. + + +*Possible investigation steps* + + +- Review the time frame and source IP addresses associated with the spike in denied traffic to identify any patterns or anomalies. +- Check the firewall and ACL logs for any recent changes or misconfigurations that could have led to the increase in denied traffic. +- Investigate the destination IP addresses and ports targeted by the denied traffic to determine if they are associated with known malicious activity or if they are legitimate services. +- Analyze the volume and frequency of the denied requests to assess whether they align with typical denial-of-service attack patterns or reconnaissance activities. +- Correlate the denied traffic with other security alerts or logs to identify any related suspicious activities or potential indicators of compromise within the network. + + +*False positive analysis* + + +- Routine network scans by security tools or IT teams may trigger spikes in denied traffic. Regularly review and whitelist known IP addresses or tools to prevent these from being flagged. +- Misconfigured applications that frequently attempt unauthorized access can cause false positives. Identify and correct these configurations to reduce unnecessary alerts. +- Legitimate but high-volume business applications might generate traffic patterns similar to reconnaissance activities. Monitor and document these applications, and create exceptions for their traffic patterns. +- Scheduled maintenance or updates can lead to temporary spikes in denied traffic. Coordinate with IT teams to anticipate these events and adjust monitoring rules accordingly. +- Internal network changes, such as new device deployments or network architecture updates, might cause unexpected traffic patterns. Ensure these changes are communicated and accounted for in the firewall rules to minimize false positives. + + +*Response and remediation* + + +- Immediately isolate affected systems or segments of the network to prevent further unauthorized access or potential spread of malicious activity. +- Analyze the denied traffic logs to identify the source IP addresses and block them at the firewall or ACL level to prevent further attempts. +- Review and correct any misconfigurations in firewall rules or ACLs that may have contributed to the spike in denied traffic. +- Conduct a thorough investigation to determine if the spike is related to a denial-of-service attack and, if confirmed, engage with your internet service provider (ISP) for additional support and mitigation strategies. +- If malicious activity is suspected, escalate the incident to the security operations center (SOC) or incident response team for further analysis and response. +- Implement additional monitoring and alerting for similar patterns of denied traffic to enhance early detection of potential threats. +- Document the incident, including actions taken and lessons learned, to improve future response efforts and update incident response plans accordingly. + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*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 to your 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/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]. + + +*Network Packet Capture Integration Setup* + +The Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment — ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + + +*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: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over C2 Channel +** ID: T1041 +** Reference URL: https://attack.mitre.org/techniques/T1041/ +* 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/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Gather Victim Network Information +** ID: T1590 +** Reference URL: https://attack.mitre.org/techniques/T1590/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Network Denial of Service +** ID: T1498 +** Reference URL: https://attack.mitre.org/techniques/T1498/ +* Technique: +** Name: Endpoint Denial of Service +** ID: T1499 +** Reference URL: https://attack.mitre.org/techniques/T1499/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-spike-in-network-traffic-to-a-country.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-spike-in-network-traffic-to-a-country.asciidoc new file mode 100644 index 0000000000..5123f6095f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-spike-in-network-traffic-to-a-country.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-29-spike-in-network-traffic-to-a-country]] +=== Spike in Network Traffic To a Country + +A machine learning job detected an unusually large spike in network activity to one destination country in the network logs. This could be due to unusually large amounts of reconnaissance or enumeration traffic. Data exfiltration activity may also produce such a surge in traffic to a destination country that does not normally appear in network traffic or business workflows. Malware instances and persistence mechanisms may communicate with command-and-control (C2) infrastructure in their country of origin, which may be an unusual destination country for the source network. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Data Source: Elastic Defend +* Data Source: Network Packet Capture +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Spike in Network Traffic To a Country* + + +Monitoring network traffic for anomalies is a good methodology for uncovering various potentially suspicious activities. For example, data exfiltration or infected machines may communicate with a command-and-control (C2) server in another country your company doesn't have business with. + +This rule uses a machine learning job to detect a significant spike in the network traffic to a country, which can indicate reconnaissance or enumeration activities, an infected machine being used as a bot in a DDoS attack, or potentially data exfiltration. + + +*Possible investigation steps* + + +- Identify the specifics of the involved assets, such as role, criticality, and associated users. +- Investigate other alerts associated with the involved assets during the past 48 hours. +- Examine the data available and determine the exact users and processes involved in those connections. +- 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. +- Consider the time of day. If the user is a human (not a program or script), did the activity occurs during working hours? +- If this activity is suspicious, contact the account owner and confirm whether they are aware of it. + + +*False positive analysis* + + +- Understand the context of the connections by contacting the asset owners. If this activity is related to a new business process or newly implemented (approved) technology, consider adding exceptions — preferably with a combination of user and source conditions. + + +*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. +- 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. +- Consider implementing temporary network border rules to block or alert connections to the target country, if relevant. +- 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 requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*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 to your 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/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]. + + +*Network Packet Capture Integration Setup* + +The Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment — ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over C2 Channel +** ID: T1041 +** Reference URL: https://attack.mitre.org/techniques/T1041/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* 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: 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-29/prebuilt-rule-8-19-29-spike-in-network-traffic.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-spike-in-network-traffic.asciidoc new file mode 100644 index 0000000000..c88339ae74 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-spike-in-network-traffic.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-29-spike-in-network-traffic]] +=== Spike in Network Traffic + +A machine learning job detected an unusually large spike in network traffic. Such a burst of traffic, if not caused by a surge in business activity, can be due to suspicious or malicious activity. Large-scale data exfiltration may produce a burst of network traffic; this could also be due to unusually large amounts of reconnaissance or enumeration traffic. Denial-of-service attacks or traffic floods may also produce such a surge in traffic. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Data Source: Elastic Defend +* Data Source: Network Packet Capture +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide + +*Version*: 109 + +*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 Spike in Network Traffic* + +Machine learning models analyze network traffic patterns to identify anomalies, such as unexpected spikes. These spikes may indicate malicious activities like data exfiltration or denial-of-service attacks. Adversaries exploit network vulnerabilities to flood traffic or extract data. The 'Spike in Network Traffic' rule leverages ML to flag unusual traffic surges, aiding in early threat detection and response. + + +*Possible investigation steps* + + +- Review the timestamp and duration of the traffic spike to determine if it correlates with any scheduled business activities or known events. +- Analyze the source and destination IP addresses involved in the traffic spike to identify any unfamiliar or suspicious entities. +- Examine the types of network protocols and services involved in the spike to assess if they align with typical network usage patterns. +- Check for any recent changes in network configurations or security policies that might explain the unusual traffic patterns. +- Investigate any associated user accounts or devices to determine if they have been compromised or are exhibiting unusual behavior. +- Cross-reference the spike with other security alerts or logs to identify potential patterns or related incidents. + + +*False positive analysis* + + +- Business-related traffic surges: Regular spikes due to legitimate business activities, such as marketing campaigns or software updates, can trigger false positives. Users should analyze historical traffic patterns and create exceptions for known business events. +- Scheduled data backups: Routine data backups can cause significant network traffic. Users can exclude these by identifying backup schedules and configuring the rule to ignore traffic during these times. +- Software updates and patches: Large-scale updates from software vendors can lead to temporary traffic spikes. Users should maintain a list of update schedules and whitelist these events to prevent false alerts. +- Internal network scans: Regular security scans or inventory checks within the organization may cause traffic spikes. Users should document these activities and adjust the rule to recognize them as non-threatening. +- Cloud service synchronization: Synchronization activities with cloud services can generate high traffic volumes. Users should identify and exclude these regular sync patterns to reduce false positives. + + +*Response and remediation* + + +- Immediately isolate affected systems from the network to prevent further data exfiltration or traffic flooding. +- Conduct a thorough analysis of network logs to identify the source and destination of the traffic spike, focusing on any unauthorized or suspicious IP addresses. +- Block identified malicious IP addresses and domains at the firewall and update intrusion prevention systems to prevent further access. +- If data exfiltration is suspected, perform a data integrity check to assess any potential data loss or compromise. +- Notify the incident response team to assess the situation and determine if further escalation is necessary, including potential involvement of law enforcement if data theft is confirmed. +- Review and update network access controls and permissions to ensure only authorized users and devices have access to sensitive data and systems. +- Implement enhanced monitoring and alerting for similar traffic patterns to improve early detection and response to future incidents. + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*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 to your 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/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]. + + +*Network Packet Capture Integration Setup* + +The Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment — ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over C2 Channel +** ID: T1041 +** Reference URL: https://attack.mitre.org/techniques/T1041/ +* 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/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Network Denial of Service +** ID: T1498 +** Reference URL: https://attack.mitre.org/techniques/T1498/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-statistical-model-detected-c2-beaconing-activity-with-high-confidence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-statistical-model-detected-c2-beaconing-activity-with-high-confidence.asciidoc new file mode 100644 index 0000000000..d5c0c5dbe0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-statistical-model-detected-c2-beaconing-activity-with-high-confidence.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-29-statistical-model-detected-c2-beaconing-activity-with-high-confidence]] +=== Statistical Model Detected C2 Beaconing Activity with High Confidence + +A statistical model has identified command-and-control (C2) beaconing activity with high confidence. Beaconing can help attackers maintain stealthy communication with their C2 servers, receive instructions and payloads, exfiltrate data and maintain persistence in a network. + +*Rule type*: query + +*Rule indices*: + +* ml_beaconing.all + +*Severity*: low + +*Risk score*: 21 + +*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://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/beaconing +* https://www.elastic.co/security-labs/identifying-beaconing-malware-using-elastic + +*Tags*: + +* Domain: Network +* Data Source: Elastic Defend +* Use Case: C2 Beaconing Detection +* Tactic: Command and Control +* 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 Statistical Model Detected C2 Beaconing Activity with High Confidence* + + +Statistical models analyze network traffic patterns to identify anomalies indicative of C2 beaconing, a tactic where attackers maintain covert communication with compromised systems. Adversaries exploit this to issue commands, exfiltrate data, and sustain network presence. The detection rule leverages a high beaconing score to flag potential threats, aiding analysts in pinpointing suspicious activities linked to C2 operations. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify the source and destination IP addresses associated with the beaconing activity flagged by the beacon_stats.beaconing_score of 3. +- Correlate the identified IP addresses with known malicious IP databases or threat intelligence feeds to determine if they are associated with known C2 servers. +- Analyze the frequency and pattern of the beaconing activity to assess whether it aligns with typical C2 communication patterns, such as regular intervals or specific time frames. +- Investigate the domain names involved in the communication to check for any associations with malicious activities or suspicious registrations. +- Examine the payloads or data transferred during the flagged communication sessions to identify any potential exfiltration of sensitive information or receipt of malicious instructions. +- Cross-reference the involved systems with internal asset inventories to determine if they are critical assets or have been previously flagged for suspicious activities. +- Consult with the incident response team to decide on containment or remediation actions if the investigation confirms malicious C2 activity. + + +*False positive analysis* + + +- Regularly scheduled software updates or patch management systems may generate network traffic patterns similar to C2 beaconing. Users can create exceptions for known update servers to reduce false positives. +- Automated backup systems that frequently communicate with cloud storage services might be flagged. Identifying and excluding these backup services from the analysis can help mitigate this issue. +- Network monitoring tools that periodically check connectivity or system health can mimic beaconing activity. Whitelisting these monitoring tools can prevent them from being incorrectly flagged. +- Internal applications that use polling mechanisms to check for updates or status changes may trigger alerts. Documenting and excluding these applications from the rule can minimize false positives. +- Frequent communication with trusted third-party services, such as content delivery networks, may appear as beaconing. Establishing a list of trusted domains and excluding them from the analysis can help manage this. + + +*Response and remediation* + + +- Isolate the affected systems from the network to prevent further communication with the C2 server and contain the threat. +- Conduct a thorough analysis of the network traffic logs to identify any additional compromised systems or lateral movement within the network. +- Remove any malicious software or scripts identified on the compromised systems, ensuring all traces of the C2 communication channels are eradicated. +- Apply security patches and updates to all affected systems to close any vulnerabilities exploited by the attackers. +- Change all credentials and authentication tokens associated with the compromised systems to prevent unauthorized access. +- Monitor the network for any signs of re-infection or continued C2 activity, using enhanced detection rules and updated threat intelligence. +- Escalate the incident to the appropriate internal security team or external cybersecurity experts for further investigation and to assess the potential impact on the organization. + +==== Setup + + + +*Setup* + + +The rule requires the Network Beaconing Identification integration assets to be installed, as well as network logs collected by the Elastic Defend integration. + + +*Network Beaconing Identification Setup* + +The Network Beaconing Identification integration consists of a statistical framework to identify C2 beaconing activity in network logs. + + +*Prerequisite Requirements:* + +- Fleet is required for Network Beaconing Identification. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Network events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. + + +*The following steps should be executed to install assets associated with the Network Beaconing Identification integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Network Beaconing Identification and select the integration to see more details about it. +- Follow the instructions under the **Installation** section. + + +==== Rule query + + +[source, js] +---------------------------------- +beacon_stats.beaconing_score: 3 + +---------------------------------- + +*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: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Sub-technique: +** Name: Bidirectional Communication +** ID: T1102.002 +** Reference URL: https://attack.mitre.org/techniques/T1102/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-statistical-model-detected-c2-beaconing-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-statistical-model-detected-c2-beaconing-activity.asciidoc new file mode 100644 index 0000000000..a120884d8c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-statistical-model-detected-c2-beaconing-activity.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-29-statistical-model-detected-c2-beaconing-activity]] +=== Statistical Model Detected C2 Beaconing Activity + +A statistical model has identified command-and-control (C2) beaconing activity. Beaconing can help attackers maintain stealthy communication with their C2 servers, receive instructions and payloads, exfiltrate data and maintain persistence in a network. + +*Rule type*: query + +*Rule indices*: + +* ml_beaconing.all + +*Severity*: low + +*Risk score*: 21 + +*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://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/beaconing +* https://www.elastic.co/security-labs/identifying-beaconing-malware-using-elastic + +*Tags*: + +* Domain: Network +* Data Source: Elastic Defend +* Use Case: C2 Beaconing Detection +* Tactic: Command and Control +* Resources: Investigation Guide + +*Version*: 11 + +*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 Statistical Model Detected C2 Beaconing Activity* + + +Statistical models analyze network traffic patterns to identify anomalies indicative of C2 beaconing, a tactic used by attackers to maintain covert communication with compromised systems. Adversaries exploit this by sending periodic signals to C2 servers, often mimicking legitimate traffic. The detection rule leverages statistical analysis to flag unusual beaconing while excluding known benign processes, thus highlighting potential threats without overwhelming analysts with false positives. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify the source and destination IP addresses associated with the beaconing activity flagged by the statistical model. +- Cross-reference the identified IP addresses with threat intelligence databases to determine if they are associated with known malicious C2 servers. +- Analyze the frequency and pattern of the beaconing signals to assess whether they mimic legitimate traffic or exhibit characteristics typical of C2 communication. +- Investigate the processes running on the source system to identify any suspicious or unauthorized applications that may be responsible for the beaconing activity. +- Check for any recent changes or anomalies in the system's configuration or installed software that could indicate a compromise. +- Examine the historical network activity of the source system to identify any other unusual patterns or connections that may suggest a broader compromise. + + +*False positive analysis* + + +- The rule may flag legitimate processes that exhibit periodic network communication patterns similar to C2 beaconing. Processes like "metricbeat.exe" and "packetbeat.exe" are known to generate regular network traffic for monitoring purposes. +- Users can manage these false positives by adding exceptions for these known benign processes in the detection rule, ensuring they are not flagged as threats. +- Regularly review and update the list of excluded processes to include any new legitimate applications that may mimic beaconing behavior, reducing unnecessary alerts. +- Consider implementing a whitelist approach for processes that are verified as non-threatening, allowing the statistical model to focus on truly anomalous activities. +- Engage with network and security teams to understand the normal traffic patterns of your environment, which can help in refining the detection rule and minimizing false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further communication with the C2 server and limit potential data exfiltration. +- Terminate any suspicious processes identified by the alert that are not part of the known benign list, ensuring that any malicious activity is halted. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software or files. +- Review and analyze network logs to identify any other systems that may have communicated with the same C2 server, and apply similar containment measures to those systems. +- Restore the affected system from a known good backup to ensure that any persistent threats are removed, and verify the integrity of the restored system. +- Implement network segmentation to limit the ability of compromised systems to communicate with critical infrastructure and sensitive data. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional measures are needed to prevent recurrence. + +==== Setup + + + +*Setup* + + +The rule requires the Network Beaconing Identification integration assets to be installed, as well as network logs collected by the Elastic Defend integration. + + +*Network Beaconing Identification Setup* + +The Network Beaconing Identification integration consists of a statistical framework to identify C2 beaconing activity in network logs. + + +*Prerequisite Requirements:* + +- Fleet is required for Network Beaconing Identification. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Network events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. + + +*The following steps should be executed to install assets associated with the Network Beaconing Identification integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Network Beaconing Identification and select the integration to see more details about it. +- Follow the instructions under the **Installation** section. + + +==== Rule query + + +[source, js] +---------------------------------- +beacon_stats.is_beaconing: true and +not process.name: ("WaAppAgent.exe" or "metricbeat.exe" or "packetbeat.exe" or "WindowsAzureGuestAgent.exe" or "HealthService.exe" or "Widgets.exe" or "lsass.exe" or "msedgewebview2.exe" or + "MsMpEng.exe" or "OUTLOOK.EXE" or "msteams.exe" or "FileSyncHelper.exe" or "SearchProtocolHost.exe" or "Creative Cloud.exe" or "ms-teams.exe" or "ms-teamsupdate.exe" or + "curl.exe" or "rundll32.exe" or "MsSense.exe" or "wermgr.exe" or "java" or "olk.exe" or "iexplore.exe" or "NetworkManager" or "packetbeat" or "Ssms.exe" or "NisSrv.exe" or + "gamingservices.exe" or "appidcertstorecheck.exe" or "POWERPNT.EXE" or "miiserver.exe" or "Grammarly.Desktop.exe" or "SnagitEditor.exe" or "CRWindowsClientService.exe" or + "agentbeat" or "dnf" or "yum" or "apt" + ) + +---------------------------------- + +*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: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Sub-technique: +** Name: Bidirectional Communication +** ID: T1102.002 +** Reference URL: https://attack.mitre.org/techniques/T1102/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-successful-amqp-multi-queue-purge-burst.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-successful-amqp-multi-queue-purge-burst.asciidoc new file mode 100644 index 0000000000..c8950bc65e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-successful-amqp-multi-queue-purge-burst.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-29-successful-amqp-multi-queue-purge-burst]] +=== Successful AMQP Multi-Queue Purge Burst + +Identifies multiple successful AMQP queue purge operations issued by the same client to the same broker within a short period. The AMQP queue.purge method removes all messages from a queue that are not awaiting acknowledgment. Purging several distinct queues can indicate deliberate message destruction or disruption after broker credentials are compromised. + +*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.rabbitmq.com/amqp-0-9-1-reference +* https://attack.mitre.org/techniques/T1485/ + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Impact +* Data Source: Network Packet Capture +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Successful AMQP Multi-Queue Purge Burst* + + +The AMQP `queue.purge` method removes every ready message from the selected queue. This rule requires successful purge responses for at least three distinct queues from one client-to-broker pair, reducing noise from isolated administrative operations while identifying activity capable of causing broad message loss and application disruption. + + +*Possible investigation steps* + + +- Review `client.ip`, `server.ip`, `Esql.purge_count`, `Esql.queue_count`, `Esql.queues`, `Esql.first_purge`, and `Esql.last_purge` to determine the scope and timing of the activity. +- Search the underlying `logs-network_traffic.amqp-*` events and confirm that each transaction has `network_traffic.amqp.method: "queue.purge"`, `network_traffic.amqp.no-wait: false`, and `network_traffic.status: "OK"`. Together, these values indicate that Packetbeat observed the broker's `queue.purge-ok` response. +- Use RabbitMQ audit and application logs to identify the authenticated user associated with the client connection. AMQP message properties are not authoritative authentication identities. +- Determine whether the source is approved administration or maintenance automation and whether a documented change authorized purging all affected queues. +- Assess message loss and application impact. Review queue-depth metrics, dead-letter queues, publisher errors, consumer lag, and service availability around the alert. +- Correlate the client and account with `queue.delete`, `exchange.delete`, binding changes, unusual consumers, authentication anomalies, and endpoint alerts. + + +*False positive analysis* + + +- Queue maintenance, integration testing, disaster-recovery exercises, and application reset workflows may intentionally purge several queues. +- Treat confirmed recurring activity as a benign true positive and scope exceptions to approved client-to-broker pairs or queue names. Broadly excluding `queue.purge` would conceal the destructive behavior this rule is intended to detect. + + +*Response and remediation* + + +- Revoke or restrict unauthorized RabbitMQ credentials and block the client if the purge was not approved. +- Preserve broker, network, and application evidence before restarting affected services. +- Restore or replay messages from upstream systems, backups, or dead-letter infrastructure where possible. +- Review RabbitMQ permissions and remove unnecessary queue-configuration rights from application accounts. +- Investigate the client host and associated account for credential theft and additional destructive activity. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Network Packet Capture integration with the AMQP protocol analyzer enabled and cleartext +AMQP 0.9.1 visibility. AMQP header and method-argument parsing must remain enabled so the method, queue, and transaction +status are populated. AMQP over TLS is opaque to passive capture. RabbitMQ audit logs are required to map the observed +client connection to an authenticated broker identity. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-network_traffic.amqp-* +| WHERE + data_stream.dataset == "network_traffic.amqp" AND + network_traffic.amqp.method == "queue.purge" AND + network_traffic.amqp.`no-wait` == false AND + network_traffic.status == "OK" AND + client.ip IS NOT NULL AND + server.ip IS NOT NULL AND + network_traffic.amqp.queue IS NOT NULL +| STATS + Esql.purge_count = COUNT(*), + Esql.queue_count = COUNT_DISTINCT(network_traffic.amqp.queue), + Esql.queues = VALUES(network_traffic.amqp.queue), + Esql.first_purge = MIN(@timestamp), + Esql.last_purge = MAX(@timestamp) + BY client.ip, server.ip +| WHERE Esql.purge_count >= 3 AND Esql.queue_count >= 3 +| SORT Esql.queue_count DESC, Esql.purge_count DESC +| KEEP client.ip, server.ip, Esql.purge_count, Esql.queue_count, Esql.queues, Esql.first_purge, Esql.last_purge + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-curl-from-macos-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-curl-from-macos-application.asciidoc new file mode 100644 index 0000000000..b6e71de425 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-curl-from-macos-application.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-29-suspicious-curl-from-macos-application]] +=== Suspicious Curl from macOS Application + +Detects the use of curl by a macOS application binary to connect to a raw IP URI and download a second stage payload. Threat actors often utilize a benign looking or legitimate application as a first stage dropper. Curl is commonly used as it doesn't enforce Gatekeeper checks. + +*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://objective-see.org/blog/blog_0x71.html#-vpn-trojan-covid +* https://attack.mitre.org/techniques/T1105/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* 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 Suspicious Curl from macOS Application* + + +Trojanized macOS applications often use curl to download second-stage payloads from attacker-controlled infrastructure. By leveraging curl instead of direct downloads, these malicious applications can bypass Gatekeeper quarantine checks and evade built-in macOS security mechanisms. This detection rule identifies when applications from the /Applications directory spawn curl to connect to raw IP addresses, which is highly indicative of malicious payload retrieval activity. + + +*Possible investigation steps* + + +- Review the process.Ext.effective_parent.executable field to identify which application spawned the curl process and assess whether this application is expected to make network downloads. +- Examine the process.args fields to extract the destination IP address and URL path being accessed, and research these indicators in threat intelligence databases. +- Analyze the process.parent.command_line to understand the full context of how curl was invoked, including any output file paths that may indicate where payloads were written. +- Check the code signature of the parent application using the process.code_signature fields to determine if it is validly signed and if the signature matches known good versions. +- Investigate the origin of the suspicious application by reviewing installation logs, download history, and any recent DMG or PKG files that may have delivered the trojanized application. +- Search for any files created on disk around the time of the curl execution to identify downloaded payloads that may have been staged for execution. +- Correlate with other events on the same host to identify if the downloaded payload was subsequently executed. + + +*False positive analysis* + + +- Some legitimate applications may use curl for software updates or telemetry data collection. Verify the destination IP against the application vendor's known infrastructure. +- Development tools and IDEs may download dependencies or packages via curl during normal operations. Review the context and confirm with development teams. +- Homebrew and package managers may spawn curl from application contexts during installations. Verify if package management activities were expected. +- Add verified legitimate applications to the exclusion list in the query after confirming their behavior is expected. + + +*Response and remediation* + + +- Immediately quarantine the suspicious application by moving it to a secure location and removing it from /Applications to prevent further execution. +- Block the destination IP address at the network perimeter and on endpoint firewalls to prevent additional downloads. +- Search the file system for any payloads that may have been downloaded and quarantine them for analysis. +- Conduct a full malware scan on the affected system to identify any persistence mechanisms or additional malware components. +- Report the trojanized application to Apple Security and relevant threat intelligence sharing platforms. +- Review other systems in the environment for the same trojanized application to determine the scope of potential compromise. +- Investigate the delivery mechanism to understand how the trojanized application was installed and prevent future infections. + + +==== 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.args in ("-o", "--output", "--download", "-dl", "-dir", "--directory") and + process.args regex~ """https?:\/\/[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}(:[0-9]{1,5})?\/.*""" and + process.parent.name like~ ("bash", "sh", "zsh", "osascript", "tclsh*", "python*") and + process.Ext.effective_parent.executable like "/Applications/*" and + process.args_count <= 10 and + not process.args like "/Applications/*" and + not process.Ext.effective_parent.executable in ("/Applications/iTerm.app/Contents/MacOS/iTerm2", + "/Applications/Visual Studio Code.app/Contents/MacOS/Electron", + "/Applications/Warp.app/Contents/MacOS/stable") + +---------------------------------- + +*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: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Gatekeeper Bypass +** ID: T1553.001 +** Reference URL: https://attack.mitre.org/techniques/T1553/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-execution-via-windows-subsystem-for-linux.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-execution-via-windows-subsystem-for-linux.asciidoc new file mode 100644 index 0000000000..030c69b3e1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-execution-via-windows-subsystem-for-linux.asciidoc @@ -0,0 +1,233 @@ +[[prebuilt-rule-8-19-29-suspicious-execution-via-windows-subsystem-for-linux]] +=== Suspicious Execution via Windows Subsystem for Linux + +Detects Linux Bash commands from the Windows Subsystem for Linux. Adversaries may enable and use WSL for Linux to avoid detection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* 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://blog.f-secure.com/hunting-for-windows-subsystem-for-linux/ +* https://lolbas-project.github.io/lolbas/OtherMSBinaries/Wsl/ +* https://blog.qualys.com/vulnerabilities-threat-research/2022/03/22/implications-of-windows-subsystem-for-linux-for-adversaries-defenders-part-1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* 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 + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Execution via Windows Subsystem for Linux* + + +Windows Subsystem for Linux (WSL) allows users to run Linux binaries natively on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute Linux commands stealthily, bypassing traditional Windows security measures. The detection rule identifies unusual WSL activity by monitoring specific executable paths, command-line arguments, and parent-child process relationships, flagging deviations from typical usage patterns to uncover potential threats. + + +*Possible investigation steps* + + +- Review the process command line and executable path to determine if the execution of bash.exe or any other Linux binaries is expected or authorized for the user or system in question. +- Investigate the parent-child process relationship, especially focusing on whether wsl.exe is the parent process and if it has spawned any unexpected child processes that are not wslhost.exe. +- Examine the command-line arguments used with wsl.exe for any suspicious or unauthorized commands, such as accessing sensitive files like /etc/shadow or /etc/passwd, or using network tools like curl. +- Check the user's activity history and system logs to identify any patterns of behavior that might indicate misuse or compromise, particularly focusing on any deviations from typical usage patterns. +- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Microsoft Defender XDR, or Sysmon to gather additional context and determine if this is part of a broader attack or isolated incident. + + +*False positive analysis* + + +- Frequent use of WSL for legitimate development tasks may trigger alerts. Users can create exceptions for specific user accounts or directories commonly used for development to reduce noise. +- Automated scripts or tools that utilize WSL for system maintenance or monitoring might be flagged. Identify these scripts and whitelist their specific command-line patterns or parent processes. +- Docker-related processes may cause false positives due to their interaction with WSL. Exclude Docker executable paths from the detection rule to prevent unnecessary alerts. +- Visual Studio Code extensions that interact with WSL can generate alerts. Exclude known non-threatening extensions by specifying their command-line arguments in the exception list. +- Regular system updates or administrative tasks that involve WSL might be misidentified. Document these activities and adjust the detection rule to recognize them as benign. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, such as those involving bash.exe or wsl.exe with unusual command-line arguments. +- Conduct a thorough review of the affected system's WSL configuration and installed Linux distributions to identify any unauthorized changes or installations. +- Remove any unauthorized or suspicious Linux binaries or scripts found within the WSL environment. +- Reset credentials for any accounts that may have been compromised, especially if sensitive files like /etc/shadow or /etc/passwd were accessed. +- 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 WSL activities across the network to detect similar threats in the future, ensuring that alerts are promptly reviewed and acted upon. + +==== 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.executable : "?:\\Windows\\System32\\bash.exe" or ?process.pe.original_file_name == "Bash.exe") and + not process.command_line : ("bash", "bash.exe") + ) or + process.executable : "?:\\Users\\*\\AppData\\Local\\Packages\\*\\rootfs\\usr\\bin\\bash" or + ( + process.parent.name : "wsl.exe" and process.parent.command_line : "bash*" and not process.name : "wslhost.exe" + ) or + ( + process.name : "wsl.exe" and + ( + process.args : "--system" or + ( + process.args : "--manage" and process.args : "--set-default-user" and process.args : "root" + ) or + ( + (process.args : ("curl", "wget") and process.args : ("http://*", "https://*")) or + process.args : ("*curl*http://*", "*curl*https://*", "*wget*http://*", "*wget*https://*") + ) or + ( + ( + process.args like~ ("*/dev/tcp/*", "*/dev/udp/*", "*zsh/net/tcp*") and + process.args like ("*&>*", "*<>*", "*>&*", "*<&*") + ) or + ( + process.args : ("nc", "netcat", "nc.traditional", "ncat", "*/nc", "*/netcat", "*/nc.traditional", "*/ncat") and + process.args : ("sh", "/bin/sh", "bash", "/bin/bash") and + process.args : ("-e", "--exec", "-c", "--sh-exec") + ) or + ( + process.args like~ "*socat*" and + process.args like~ ("*exec:*", "*system:*", "*shell:*") and + process.args like~ ("*tcp*", "*udp*", "*openssl*") + ) + ) or + ( + process.args : ("-e", "--exec") and + process.args : ( + "/mnt/c/*.exe", "/mnt/c/*.ps1", "/mnt/c/*.bat", "/mnt/c/*.cmd", "/mnt/c/*.vbs", "/mnt/c/*.js", + "/mnt/c/*.hta" + ) and + not process.args : "*wslpath*" + ) or + process.args : ( + "*/etc/passwd*", "*/etc/shadow*", "*/etc/sudoers*", "*/etc/sudoers.d/*", "*/root/.ssh/*", "*/home/*/.ssh/*", + "*/root/.aws/credentials*", "*/home/*/.aws/credentials*", "*/root/.kube/config*", "*/home/*/.kube/config*", + "*/mnt/c/Windows/System32/config/SAM*", + "*/mnt/c/Windows/System32/config/SECURITY*", + "*/mnt/c/Windows/System32/config/SYSTEM", "*/mnt/c/Windows/System32/config/SYSTEM.*", + "*/mnt/c/Windows/NTDS/ntds.dit*", + "*/mnt/c/Users/*/AppData/Roaming/Microsoft/Credentials/*", + "*/mnt/c/Users/*/AppData/Local/Microsoft/Credentials/*", + "*/mnt/c/Users/*/AppData/Roaming/Microsoft/Protect/*", + "*/mnt/c/Users/*/.ssh/*", + "*/mnt/c/Users/*/.aws/credentials", + "*/mnt/c/Users/*/.azure/*", + "*/mnt/c/Users/*/.config/gcloud/*", + "*/mnt/c/Users/*/AppData/Local/Google/Chrome/User Data/*/Login Data*", + "*/mnt/c/Users/*/AppData/Local/Microsoft/Edge/User Data/*/Login Data*" + ) + ) + ) + ) and + not process.parent.executable : ("?:\\Program Files\\Docker\\*.exe", "?:\\Program Files (x86)\\Docker\\*.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: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: /etc/passwd and /etc/shadow +** ID: T1003.008 +** Reference URL: https://attack.mitre.org/techniques/T1003/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-execution-with-nodejs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-execution-with-nodejs.asciidoc new file mode 100644 index 0000000000..8c970ba731 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-execution-with-nodejs.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-29-suspicious-execution-with-nodejs]] +=== Suspicious Execution with NodeJS + +Identifies suspicious Node.js execution patterns, including PowerShell-launched module preloads and inline eval, decode, or child-process usage. + +*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://nodejs.org/api/child_process.html +* https://nodejs.org/api/cli.html#-r---require-module +* https://nodejs.org/api/globals.html#atobdata + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* 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*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Execution with NodeJS* + + + +*Possible investigation steps* + + +- Which Node execution path did the alert capture? + - Focus: `process.executable`, `process.command_line`, `process.parent.name`, and `process.pe.original_file_name`. + - Implication: escalate faster when the match is a PowerShell-launched preload or inline decode/spawn pattern; lower suspicion when parent and command-line evidence show a recognized version-manager, IDE, package-manager, or test-runner pattern. + +- Do the runtime identity and launcher context fit recognized Node use? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.command_line`, `user.id`, and `host.id`. + - Implication: escalate when the runtime is unsigned, renamed, mismatched to "node.exe", staged from Temp/AppData outside a recognized toolchain, or launched by PowerShell, Office, a browser, an archive utility, or a download path without matching IDE/package/build context; lower suspicion only when runtime identity and parent chain fit the same recurring Node workflow for that user or host. Identity alone does not clear suspicious arguments. + +- What do the arguments show about preload, script, or inline execution intent? + - Why: "-r" / "--require" preloads a module at startup; "child_process" enables OS subprocess creation. + - Focus: `process.command_line` and the script or preload path parsed from it. + - Implication: escalate when Node preloads an unexpected module, decodes inline content with 'atob(' or 'eval(', or references "child_process"; lower suspicion when the target is a recognized preload such as a test harness, transpiler, or source-map helper inside the same project tree. + +- If endpoint file telemetry is available, what provenance exists for the script or preload module? + - Focus: recover file events with `host.id` + `process.entity_id`, or `host.id` + `process.pid` + a tight alert window as weaker fallback; inspect `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and `file.Ext.original.path`. !{investigate{"description":"","label":"File events for the Node 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":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: missing file telemetry is unresolved, not benign; use parsed command-line paths and parent context as weaker evidence. + - Implication: escalate when the script or module was downloaded, extracted, renamed, or staged into AppData/Temp shortly before execution; lower suspicion when it stays in a stable repository, package cache, or product install tree consistent with the parent workflow. + +- If child-process or endpoint network telemetry is available, what did Node do next? + - Focus: recover child and network events with `host.id` + `process.entity_id`, or `host.id` + `process.pid` + the post-start window as weaker fallback; inspect child `process.name` / `process.executable`, DNS `dns.question.name`, and connection `destination.ip` / `destination.port`. + - !{investigate{"description":"","label":"Child processes spawned by Node","providers":[[{"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"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Network events for the Node 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: separate DNS events from connection events before interpreting destinations; missing child or network telemetry is unresolved, not benign. + - Implication: escalate when Node quickly launches shells, LOLBins, archivers, credential tooling, or reaches externally routable destinations unrelated to the workflow; lower suspicion when child activity and destinations stay bounded to recognized local development, build, package-registry, or deployment services. + +- If local evidence stays suspicious or unresolved, do related alerts show broader scripting, download, persistence, or beaconing activity? + - Focus: same-`user.id` related alerts or process events, especially PowerShell, archive, downloader, persistence, and outbound-connection activity. + - Hint: if `user.id` is missing or ambiguous, review same-host alerts and process events for `host.id` in the last 48 hours. + - !{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: expand scope when the host or user shows staged payload delivery, repeated Node misuse, persistence, or beaconing; keep scope local when behavior is isolated and local evidence supports one recognized workflow. + +- Escalate when branch, runtime, argument, lineage, or recovered artifact/child/network evidence shows staged script, unrecognized preload, inline decode, or spawn abuse; close only when those categories tightly support one recognized workflow with no contradictions; preserve artifacts and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Developer tooling, version managers, IDEs, package managers, and build/test runners can legitimately run "node.exe" from user-space paths or use "-r" preloads. Confirm one workflow: runtime path/hash/signer, parent, command line, and referenced script or preload path all align with the same toolchain. Without inventory or build records, telemetry-only closure requires exact workflow recurrence for the same `user.id` or `host.id` cohort plus no contradictory file, child-process, or network evidence; do not close on recurrence alone. +- Treat partial matches as unresolved. An OpenJS signer, "node.exe" name, or familiar parent does not explain AppData execution, inline decode/eval, or child-process behavior by itself. Before creating an exception, validate recurrence of the same Node binary, argument pattern, parent context, and script or preload path; avoid exceptions on `process.name` or `process.code_signature.subject_name` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the exact Node workflow: runtime path/hash/signer, parent launcher, command line, script or preload path, and `user.id` / `host.id` scope. Create an exception only when the same workflow recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the process start event, command line, binary hash/signature, script or preload artifact, child process chain, and any recovered DNS or connection events before containment. Apply reversible containment tied to the finding, such as temporary destination blocking, script quarantine, or heightened monitoring on the affected `host.id` and `user.id`. Escalate to host isolation only when follow-on execution, persistence, or outbound activity confirms broader compromise and host criticality allows interruption. +- If confirmed malicious, preserve `process.entity_id` or `process.pid` with `host.id` and time, parent process context, `process.command_line`, `process.hash.sha256`, referenced script or preload paths, child-process lineage, and confirmed network indicators before terminating Node or isolating the host. If direct endpoint response is unavailable, hand off that artifact set to the team that can isolate the system or block destinations. +- Scope related hosts and users for the same runtime hash, suspicious command-line pattern, script/preload paths, child-process lineage, and network indicators before deleting scripts, modules, or staged payloads. Then remove only the malicious artifacts identified during triage and remediate the delivery path or launcher that led to Node execution. +- Post-incident hardening: restrict unrecognized "node.exe" execution from user-writable paths, retain process-start, file-provenance, and network telemetry, and document adjacent variants found during triage, such as renamed Node runtimes, packaged Electron launchers, alternate preload patterns, or `--require` abuse without PowerShell. + +==== 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 : "node.exe" or ?process.pe.original_file_name == "node.exe" or + ?process.code_signature.subject_name : ("OpenJS Foundation", "Node.js Foundation")) and + +( + (process.args : ("-r", "--require", "--require=*") and + process.parent.name : ("powershell.exe", "pwsh.exe")) or + + process.command_line : ("*eval(*", "*atob(*", "*require*child_process*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-inter-process-communication-via-outlook.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-inter-process-communication-via-outlook.asciidoc new file mode 100644 index 0000000000..f5e168889d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-inter-process-communication-via-outlook.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-29-suspicious-inter-process-communication-via-outlook]] +=== Suspicious Inter-Process Communication via Outlook + +Detects Inter-Process Communication with Outlook via Component Object Model from an unusual process. Adversaries may target user email to collect sensitive information or send email on their behalf via API. + +*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://github.com/center-for-threat-informed-defense/adversary_emulation_library/blob/master/apt29/Archive/CALDERA_DIY/evals/payloads/stepSeventeen_email.ps1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Collection +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Inter-Process Communication via Outlook* + + +Outlook's integration with the Component Object Model (COM) allows processes to automate tasks like sending emails. Adversaries exploit this by using unusual processes to interact with Outlook, potentially to exfiltrate data or send unauthorized emails. The detection rule identifies such anomalies by monitoring for unexpected processes initiating communication with Outlook, especially those lacking trusted signatures or recently modified, indicating potential malicious activity. + + +*Possible investigation steps* + + +- Review the process entity ID to identify the specific process that initiated communication with Outlook and determine if it is one of the unusual processes listed, such as rundll32.exe, mshta.exe, or powershell.exe. +- Check the code signature status of the initiating process. If the process is unsigned or has an untrusted signature, investigate the source and legitimacy of the executable. +- Analyze the relative file creation and modification times of the initiating process. If the process was created or modified recently (within 500 seconds), it may indicate a newly introduced or altered executable, warranting further scrutiny. +- Investigate the effective parent process of OUTLOOK.EXE to understand the context of how Outlook was launched. Determine if the parent process is expected or if it is an unusual or suspicious process. +- Correlate the alert with any recent user activity or changes on the host to identify potential user actions or system changes that could explain the process behavior. +- Examine any network activity associated with the initiating process to identify potential data exfiltration or unauthorized email sending attempts. +- Review any additional alerts or logs related to the host or user account to identify patterns or additional indicators of compromise. + + +*False positive analysis* + + +- Legitimate administrative scripts or tools may trigger the rule if they use processes like PowerShell or cmd.exe to automate tasks involving Outlook. To manage this, identify and whitelist these scripts or tools by their specific file paths or hashes. +- Software updates or installations might cause processes to appear as recently modified, leading to false positives. Regularly update the list of trusted software and exclude these known update processes from triggering alerts. +- Custom in-house applications that interact with Outlook for business purposes may be flagged. Ensure these applications are signed with a trusted certificate or add them to an exception list based on their unique identifiers. +- Security tools or monitoring software that perform regular checks on Outlook might be misidentified. Verify these tools and exclude them by their process names or signatures to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified in the alert, particularly those interacting with Outlook, such as rundll32.exe, mshta.exe, or powershell.exe. +- Conduct a thorough review of the email account associated with the affected Outlook process to identify any unauthorized access or email activity. Reset the account credentials if necessary. +- Analyze the process code signatures and file modification times to determine if any legitimate applications have been compromised. Reinstall or update these applications as needed. +- 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 additional monitoring on the affected system and similar endpoints to detect any recurrence of the suspicious activity. +- Review and update endpoint protection policies to ensure that similar threats are detected and blocked in the future, leveraging the MITRE ATT&CK framework for guidance on email collection techniques. + +==== 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 with maxspan=1m +[process where host.os.type == "windows" and event.action == "start" and + ( + process.name : ( + "rundll32.exe", "mshta.exe", "powershell.exe", "pwsh.exe", + "cmd.exe", "regsvr32.exe", "cscript.exe", "wscript.exe" + ) or + ( + (process.code_signature.trusted == false or process.code_signature.exists == false) and + (process.Ext.relative_file_creation_time <= 500 or process.Ext.relative_file_name_modify_time <= 500) + ) + ) and + not ( + process.executable : "?:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe" and + process.parent.executable : "?:\\Program Files (x86)\\CyberCNSAgent\\cybercnsagent.exe" and + user.id == "S-1-5-18" + ) +] by process.entity_id +[process where host.os.type == "windows" and event.action == "start" and process.name : "OUTLOOK.EXE" and + process.Ext.effective_parent.name != null] by process.Ext.effective_parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Local Email Collection +** ID: T1114.001 +** Reference URL: https://attack.mitre.org/techniques/T1114/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Inter-Process Communication +** ID: T1559 +** Reference URL: https://attack.mitre.org/techniques/T1559/ +* Sub-technique: +** Name: Component Object Model +** ID: T1559.001 +** Reference URL: https://attack.mitre.org/techniques/T1559/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-service-was-installed-in-the-system.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-service-was-installed-in-the-system.asciidoc new file mode 100644 index 0000000000..461bab3528 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-service-was-installed-in-the-system.asciidoc @@ -0,0 +1,202 @@ +[[prebuilt-rule-8-19-29-suspicious-service-was-installed-in-the-system]] +=== Suspicious Service was Installed in the System + +Identifies the creation of a new Windows service with a suspicious service name or command value. Windows services typically run as SYSTEM and can be used for privilege escalation and persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-system.system* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Windows Security Event Logs +* Data Source: Windows System Event Logs + +*Version*: 118 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Service was Installed in the System* + + + +*Possible investigation steps* + + +- What exact service creation event and matched artifact caused the alert? + Focus: `event.code`, `host.name`, `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ImagePath`. + Implication: Event `4697` uses `winlog.event_data.ServiceFileName`; event `7045` uses `winlog.event_data.ImagePath`. Treat malware or credential-dump service names such as `mssecsvc2.0`, `WCESERVICE*`, `WCE SERVICE*`, `pwdump*`, `gsecdump*`, or `cachedump*`, or a command containing PAExec, Winexe, DumpSvc, PowerShell, command shell, admin share, user-writable, or service-control utility traits, as suspicious unless the exact host, service name, command, and alert time map to a validated change record or verified owner confirmation. + Review matching service events with !{investigate{"description":"","label":"Matched service on host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ServiceName","queryType":"phrase","value":"{{winlog.event_data.ServiceName}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ServiceName","queryType":"phrase","value":"{{winlog.event_data.ServiceName}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"7045","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + +- Do the installing account and service account explain this specific service creation? + Focus: `event.code`, `user.name`, `user.domain`, `winlog.logon.id`, `winlog.event_data.ServiceAccount` for event `4697`, and `winlog.event_data.AccountName` for event `7045`. + Implication: Event `4697` can identify the installing account and logon session and records the service account in `winlog.event_data.ServiceAccount`. Event `7045` records the service account in `winlog.event_data.AccountName`, but identifying the installer may require recovery of a matching Security event or surrounding service-control and process telemetry. Escalate if the recovered installer identity cannot be tied to the exact service install, if the service runs as a privileged or unexpected account, or if the account context conflicts with the claimed workflow. A benign branch requires recovered evidence that the same account created this same service during a validated maintenance or deployment window on this host. Missing Security or corroborating telemetry remains unresolved. + Search recent service install events on the matched host with !{investigate{"description":"","label":"Recent service installs on host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"7045","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + +- Does the live host still show the same service configuration and referenced artifact? + Focus: On the matched `host.id` or `host.name`, retrieve the current service by exact `winlog.event_data.ServiceName` with `sc.exe qc`, `sc.exe queryex`, or `Get-CimInstance Win32_Service -Filter Name=''`; record the service path, account, status, and start context, then inspect the referenced executable or script on disk when it is still present. + Implication: Live service configuration can confirm current path, account, status, and start context, but configuration alone does not prove the service command executed. Escalate when the current service or referenced artifact supports persistence, or when process telemetry, service-control logs, or other execution events show the service command ran. If live-host retrieval or artifact inspection is unavailable, the unavailable live-host evidence remains unresolved. A benign branch requires the live or recovered service state to match the exact expected service lifecycle, such as a short-lived remote support service removed after the named deployment task, without extra commands or altered paths. + +- Are there corroborating process, file, registry, or authentication events on the same host around the service installation? + Focus: `host.id`, `winlog.event_data.ServiceName`, `winlog.event_data.ServiceAccount` for event `4697`, `winlog.event_data.AccountName` for event `7045`, `user.name`, and `winlog.record_id`. + Implication: Process, file, registry, and service-control telemetry are supporting sources and may be absent from the final alert; recover them manually by host and time before drawing conclusions. Escalate if recovered events show the service launching shell, LOLBin, credential-dumping, or user-writable path payloads. If those supporting sources are missing, keep the case unresolved instead of treating absence as benign. + +- If local evidence is suspicious or unresolved, has the same service name appeared on other hosts? + Focus: `winlog.event_data.ServiceName`, `host.name`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ImagePath`, `user.name`. + Implication: Use this only after the local service and artifact checks above. Reuse across hosts supports a lateral movement, remote administration, or shared deployment hypothesis; scope containment and account review to matching hosts when the service name or installer context is suspicious. A benign branch requires recovered events on the additional hosts to share the same deployment window, installing account when available, and exact service command for one validated change record. Absence of related alerts does not prove benign. + Pivot on the service name across hosts with !{investigate{"description":"","label":"Same service name across hosts","providers":[[{"excluded":false,"field":"winlog.event_data.ServiceName","queryType":"phrase","value":"{{winlog.event_data.ServiceName}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"}],[{"excluded":false,"field":"winlog.event_data.ServiceName","queryType":"phrase","value":"{{winlog.event_data.ServiceName}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"7045","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + +Disposition: Escalate suspicious service commands, mismatched installer or service-account context, persistent live service state, or repeated hosts; close only when alert-local fields plus recovered service and host evidence prove the exact expected workflow; preserve and escalate mixed or incomplete cases for more context before final disposition. + + +*False positive analysis* + + +- Remote administration and deployment tools such as PAExec, RemCom, and Winexe can create temporary services that match the suspicious service-name or command patterns. Close only when the recovered `winlog.event_data.ServiceName`, command field, installing account, target host, and timing all match one validated maintenance or deployment action. +- PowerShell, `pwsh.exe`, `cmd.exe`, `rundll32`, `regsvr32`, `msbuild`, `bitsadmin`, `certutil`, or `vssadmin` in a service command should remain suspicious until the referenced script or command content, service account, and owner confirmation explain the exact alert artifact on this host. +- Scope exceptions to durable alert fields. For event `4697`, use exact `winlog.event_data.ServiceName` and `winlog.event_data.ServiceFileName`; for event `7045`, use exact `winlog.event_data.ServiceName` and `winlog.event_data.ImagePath`. Add `host.id` or `host.name`, plus `user.name` and `user.domain`, when those fields repeat in the validated benign pattern. + + +*Response and remediation* + + +- Collect and preserve case evidence, export the alert and matched service event, and preserve volatile process, memory, executable, script, service configuration, and file-system artifacts that could be lost before isolation, process termination, service removal, cleanup, or other disruptive action. +- Review recovered evidence and scope affected hosts/accounts by service name, service command, installing account, target host, and related authentication before containment decisions. +- If malicious service execution is confirmed, use the endpoint response integration as the preferred path to isolate affected hosts, and disable exposed accounts as reversible containment while retaining evidence. When direct response is unavailable, document handoff to the responsible incident-response or endpoint-operations owner for host isolation and to the identity owner for account containment. +- After scoping and preservation, stop malicious service processes if running, remove the malicious service or persistence entry, quarantine associated executable or script files, and run an antimalware scan. +- Reset or rotate credentials for accounts that installed, ran, or were accessed by the malicious service after credential exposure review. +- Record confirmed service names, commands, recovered file hashes, installing accounts, affected hosts, and telemetry or detection gaps for responsible detection and logging owners after scoping and containment. + + +==== Setup + + + +*Setup* + + +Audit Security System Extension must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-security-system-extension + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and +( + ( + event.code : "4697" and + ( + ( + ( + winlog.event_data.ServiceFileName : ( + "*COMSPEC*", "*\\127.0.0.1*", "*Admin$*", "*powershell*", "*rundll32*", "*cmd.exe*", + "*echo*", "*RemComSvc*", "*.bat*", "*.cmd*", "*certutil*", "*vssadmin*", "*certmgr*", "*bitsadmin*", + "*\\Users\\*", "*\\Windows\\Tasks\\*", "*\\PerfLogs\\*", "*\\Windows\\Debug\\*", + "*regsvr32*", "*msbuild*", "*winexesvc.exe*", "*DumpSvc.exe*", "*pwsh.exe*", "*PAExec*" + ) or + winlog.event_data.ServiceFileName regex~ """%systemroot%\\[a-z0-9]+\.exe""" + ) and + not winlog.event_data.ServiceFileName: ( + "%SystemRoot%\\PSEXESVC.exe", "%SystemRoot%\\\\RemComSvc.exe", + "%SystemRoot%\\pbpsdeploy.exe", "%SystemRoot%\\system32\\RemComSvc.exe", + "\"C:\\Program Files\\Common Files\\Zoom\\Support\\CptService.exe*", + "\"C:\\Program Files\\Common Files\\ZoomVDIPluginManagement\\Support\\CptService.exe*", + "\"C:\\Program Files (x86)\\CheckPoint\\Endpoint Security\\EFR\\host\\cpsechost.exe\" service" + ) + ) or + winlog.event_data.ServiceName : ( + "mssecsvc2.0", "WCESERVICE*", "WCE SERVICE*", "pwdump*", "gsecdump*", "cachedump*" + ) + ) + ) or + ( + event.code : "7045" and + ( + ( + winlog.event_data.ImagePath : ( + "*COMSPEC*", "*\\127.0.0.1*", "*Admin$*", "*powershell*", "*rundll32*", "*cmd.exe*", + "*echo*", "*.bat*", "*.cmd*", "*certutil*", "*vssadmin*", "*certmgr*", "*bitsadmin*", + "*\\Users\\*", "*\\Windows\\Tasks\\*", "*\\PerfLogs\\*", "*\\Windows\\Debug\\*", + "*regsvr32*", "*msbuild*", "*winexesvc.exe*", "*DumpSvc.exe*", "*pwsh.exe*", "*PAExec*" + ) and + not winlog.event_data.ImagePath : ( + "%SystemRoot%\\PSEXESVC.exe", "%SystemRoot%\\\\RemComSvc.exe", + "%SystemRoot%\\pbpsdeploy.exe", "%SystemRoot%\\system32\\RemComSvc.exe", + "\"C:\\Program Files\\Common Files\\Zoom\\Support\\CptService.exe*", + "\"C:\\Program Files\\Common Files\\ZoomVDIPluginManagement\\Support\\CptService.exe*", + "\"C:\\Program Files (x86)\\CheckPoint\\Endpoint Security\\EFR\\host\\cpsechost.exe\" service" + ) + ) or + winlog.event_data.ServiceName : ( + "mssecsvc2.0", "WCESERVICE*", "WCE SERVICE*", "pwdump*", "gsecdump*", "cachedump*" + ) + ) + ) +) + +---------------------------------- + +*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/ +* 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: Service Execution +** ID: T1569.002 +** Reference URL: https://attack.mitre.org/techniques/T1569/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-uid-change-to-root-via-python.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-uid-change-to-root-via-python.asciidoc new file mode 100644 index 0000000000..e9e5c15eca --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-uid-change-to-root-via-python.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-29-suspicious-uid-change-to-root-via-python]] +=== Suspicious UID Change to Root via Python + +Detects a UID change event to 0 (root) where the responsible process is a Python interpreter running from a user- or world-writable working directory and the parent process is non-root. This may be indicative of a local privilege escalation exploit executed via Python. Using the new terms feature, noise from automated tools or system processes is partially filtered out. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*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://research.jfrog.com/post/dissecting-and-exploiting-linux-lpe-variant-dirtyclone-cve-2026-43503/ +* https://github.com/mooder1/dirtyclone-CVE-2026-43503 + +*Tags*: + +* Data Source: Elastic Defend +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious UID Change to Root via Python* + + +This rule flags a Linux process where a Python interpreter launched from a user- or world-writable location suddenly switches to UID 0 even though its parent was not running as root, a strong sign of local privilege escalation. An attacker might drop or compile an exploit in /tmp or a home directory, execute it through python3, and use the resulting root context to take full control of the host. + + +*Possible investigation steps* + + +- Reconstruct the full process ancestry and command line around the Python execution, including any shell, script, package manager, or developer tooling that launched it, to quickly separate expected admin activity from an unexpected exploit chain. +- Review the Python code and surrounding file activity in writable directories for exploit indicators such as dropped ELF binaries, compiled modules, kernel-targeting source, symlink abuse, or references to known privilege-escalation PoCs. +- Correlate the event with session context by identifying the associated user login, TTY, SSH source, sudo or su history, and recent commands to determine whether the root transition was intentional or adversary-driven. +- Examine actions performed immediately after the privilege change for signs of follow-on compromise, such as spawning an interactive root shell, modifying sudoers or PAM, creating cron or systemd persistence, adding users or SSH keys, or disabling security tooling. +- Validate whether the host was susceptible to a local privilege-escalation path at the time by checking kernel and OS version, recent patch status, and whether the observed artifacts match public exploits relevant to that platform. + + +*False positive analysis* + + +- A developer or administrator may be legitimately testing a custom privileged Python helper from `/tmp` or a home directory that uses an approved setuid-root wrapper or retained capabilities to switch to UID 0, so verify the script and interpreter ownership, permissions/capabilities, and whether the activity matches a documented maintenance or test window. +- A local installation, upgrade, or recovery workflow can stage Python code in `/var/tmp`, `/dev/shm`, or `/home` and briefly elevate to root to complete expected file or permission changes, so confirm the parent process lineage, review the script contents and resulting system modifications, and ensure they align with recent authorized admin activity. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network except for approved response channels, suspend the compromised user session, and preserve the malicious Python script, its parent shell history, and any binaries dropped in `/tmp`, `/var/tmp`, `/dev/shm`, or the user home directory for forensic review. +- Kill the attacker-controlled Python process and any spawned root shell or child processes, then remove persistence such as new cron entries, rogue systemd services or timers, modified `/etc/rc.local`, added `authorized_keys`, backdoored `sudoers`, and unauthorized local accounts. +- Quarantine or delete exploit files and any trojaned binaries they replaced, rotate passwords and any SSH keys, API tokens, or service credentials exposed on the host, and review lateral access from that system while it was running with root privileges. +- Rebuild or restore the host from a known-good image if root-level changes cannot be fully scoped, then validate the kernel, installed packages, PAM configuration, `/etc/sudoers`, critical system binaries, and endpoint security tooling against a trusted baseline before reconnecting it. +- Escalate to incident response immediately if you find PAM or `sudoers` tampering, kernel module loading, additional root-capable accounts, signs of data staging or exfiltration, or the same Python-based privilege escalation pattern on more than one host. +- Harden the environment by patching the kernel and vulnerable packages, mounting `/tmp` and `/dev/shm` with `noexec`, `nodev`, and `nosuid` where feasible, removing unnecessary setuid bits and file capabilities, and alerting on interpreters elevating to root from user-writable directories. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:change and event.action:uid_change and +user.id:0 and not process.parent.user.id:0 and not process.parent.group.id:0 and process.name:python* and +process.working_directory:(/tmp* or /var/tmp* or /dev/shm* or /home/* or /run/user* or /var/run/user* or /var/www*) and +process.parent.working_directory:(/tmp* or /var/tmp* or /dev/shm* or /home/* or /run/user* or /var/run/user* or /var/www*) and +process.command_line:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* 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: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-windows-powershell-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-windows-powershell-arguments.asciidoc new file mode 100644 index 0000000000..98b6b7793c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-suspicious-windows-powershell-arguments.asciidoc @@ -0,0 +1,282 @@ +[[prebuilt-rule-8-19-29-suspicious-windows-powershell-arguments]] +=== Suspicious Windows Powershell Arguments + +Identifies the execution of PowerShell with suspicious argument values. This behavior is often observed during malware installation leveraging PowerShell. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-crowdstrike.fdr* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Windows Security Event Logs +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Resources: Investigation Guide + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Windows Powershell Arguments* + + +PowerShell is a powerful scripting language and command-line shell used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's capabilities to execute malicious scripts, download payloads, and obfuscate commands. The detection rule identifies unusual PowerShell arguments indicative of such abuse, focusing on patterns like encoded commands, suspicious downloads, and obfuscation techniques, thereby flagging potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the process command line and arguments to identify any encoded or obfuscated content, such as Base64 strings or unusual character sequences, which may indicate malicious intent. +- Check the parent process of the PowerShell execution, especially if it is explorer.exe or cmd.exe, to determine if the PowerShell instance was launched from a suspicious or unexpected source. +- Investigate any network activity associated with the PowerShell process, particularly looking for connections to known malicious domains or IP addresses, or the use of suspicious commands like DownloadFile or DownloadString. +- Examine the user account associated with the PowerShell execution to determine if it aligns with expected behavior or if it might be compromised. +- Correlate the event with other security alerts or logs from the same host or user to identify patterns or additional indicators of compromise. +- Assess the risk and impact of the detected activity by considering the context of the environment, such as the presence of sensitive data or critical systems that might be affected. + + +*False positive analysis* + + +- Legitimate administrative scripts may use encoded commands for obfuscation to protect sensitive data. Review the script's source and purpose to determine if it is authorized. If confirmed, add the script's hash or specific command pattern to an allowlist. +- Automated software deployment tools might use PowerShell to download and execute scripts from trusted internal sources. Verify the source and destination of the download. If legitimate, exclude the specific tool or process from the detection rule. +- System maintenance tasks often involve PowerShell scripts that manipulate files or system settings. Identify routine maintenance scripts and exclude their specific command patterns or file paths from triggering the rule. +- Security software may use PowerShell for scanning or remediation tasks, which can mimic suspicious behavior. Confirm the software's legitimacy and add its processes to an exception list to prevent false alerts. +- Developers might use PowerShell for testing or development purposes, which can include obfuscation techniques. Validate the developer's activities and exclude their specific development environments or scripts from the rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activities. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or scripts. +- Review and clean up any unauthorized changes to system configurations or scheduled tasks that may have been altered by the malicious PowerShell activity. +- Restore any affected files or system components from known good backups to ensure system integrity and functionality. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised. +- Implement additional monitoring and logging for PowerShell activities across the network to enhance detection of similar threats in the future. + +==== 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 : "powershell.exe" and + + not ( + ?user.id == "S-1-5-18" and + /* Don't apply the user.id exclusion to Sysmon for compatibility */ + not data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon") + ) and + + not process.parent.executable : ( + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe" + ) and + + ( + process.command_line : ( + "*^*^*^*^*^*^*^*^*^*", + "*`*`*`*`*", + "*+*+*+*+*+*+*", + "*[char[]](*)*-join*", + "*Base64String*", + "*[*Convert]*", + "*.Compression.*", + "*-join($*", + "*MemoryStream*", + "*WriteAllBytes*", + "* -enc *", + "* -ec *", + "* /e *", + "* /enc *", + "* /ec *", + "*WebClient*", + "*DownloadFile*", + "*DownloadString*", + "* iex*", + "* iwr*", + "* aQB3AHIAIABpA*", + "*Reflection.Assembly*", + "*Assembly.GetType*", + "*$env:temp\\*start*", + "*powercat*", + "*nslookup -q=txt*", + "*$host.UI.PromptForCredential*", + "*Net.Sockets.TCPClient*", + "*curl *;Start*", + "powershell.exe \"<#*", + "*ssh -p *", + "*http*|iex*", + "*@SSL\\DavWWWRoot\\*.ps1*", + "*.lnk*.Seek(0x*", + "*[string]::join(*", + "*[Array]::Reverse($*", + "* hidden $(gc *", + "*=wscri& set*", + "*http'+'s://*", + "*.content|i''Ex*", + "*//:sptth*", + "*//:ptth*", + "*h''t''t''p*", + "*'tp'':''/'*", + "*$env:T\"E\"MP*", + "*;cmd /c $?", + "*s''t''a''r*", + "*$*=Get-Content*AppData*.SubString(*$*", + "*=cat *AppData*.substring(*);*$*", + "*-join'';*|powershell*", + "*.Content;sleep *|powershell*", + "*h\''t\''tp:\''*", + "*-e aQB3AHIAIABp*", + "*iwr *https*).Content*", + "*$env:computername*http*", + "*;InVoKe-ExpRESsIoN $COntent.CONTENt;*", + "*WebClient*example.com*", + "*=iwr $*;iex $*", + "*ServerXmlHttp*IEX*", + "*XmlDocument*IEX*" + ) or + + ( + process.command_line : "*.replace*" and + /* exclude known process and network inventory collection patterns */ + not process.command_line : ( + "*Get-CimInstance -Class Win32_Process*ConvertTo-Csv*Select-Object*$_.Replace*", + "*function replace_unallowed*$s.replace*Get-Counter*Network Adapter*" + ) + ) or + + (process.args : "-c" and process.args : "&{'*") or + + (process.args : "-Outfile" and process.args : "Start*") or + + (process.args : "-bxor" and process.args : "0x*") or + + process.args : "$*$*;set-alias" or + + process.args == "-e" or + + // ATHPowerShellCommandLineParameter + process.args : ("-EncodedCommandParamVariation", "-UseEncodedArguments", "-CommandParamVariation") or + + ( + process.parent.name : ("explorer.exe", "cmd.exe") and + process.command_line : ("*-encodedCommand*", "*Invoke-webrequest*", "*WebClient*", "*Reflection.Assembly*")) + ) and + not process.command_line : ( + "*Use-Icinga -Minimal*", + "*& {$j = sajb {Add-Type -AssemblyName*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* 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: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* 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-29/prebuilt-rule-8-19-29-system-public-ip-discovery-via-dns-query.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-system-public-ip-discovery-via-dns-query.asciidoc new file mode 100644 index 0000000000..027a215077 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-system-public-ip-discovery-via-dns-query.asciidoc @@ -0,0 +1,235 @@ +[[prebuilt-rule-8-19-29-system-public-ip-discovery-via-dns-query]] +=== System Public IP Discovery via DNS Query + +Identifies DNS queries to known public IP address lookup web services from suspicious Windows processes, which can reveal external IP or internet-connectivity discovery before follow-on activity. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.network-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* +* 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://attack.mitre.org/techniques/T1016/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* 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 System Public IP Discovery via DNS Query* + + + +*Possible investigation steps* + + +- Does the alert-local DNS event show request-only, successful resolution, or lookup failure for a public-IP service? + - Why: request events show intent to resolve the service; result events plus `dns.resolved_ip` show resolver response, not a connection. + - Focus: `dns.question.name`, `event.action`, `dns.resolved_ip`, `dns.Ext.status`, and `@timestamp`. + - Implication: escalate faster when a suspicious process resolves a service that reports public egress IP; lower concern only when the lookup failed or stayed request-only and identity, lineage, and network checks all fit the same recognized connectivity test. + +- Is the alerting binary a recognized tool or a suspicious LOLBin/script host in this context? + - Focus: alert or recovered process identity: `process.name`, `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when the lookup comes from a LOLBin, scripting runtime, unsigned binary, user-writable path, or signer mismatch; lower concern when a stable signed updater, endpoint-management, or managed connectivity-check component owns the exact binary. Identity alone does not close the alert. + +- Does the launch chain explain why this process needed external-IP discovery? + - Focus: recovered process start and parent context on `host.id` and `process.entity_id`: `process.command_line`, `process.parent.executable`, `process.parent.command_line`, `user.id`, and `process.Ext.session_info.logon_type`. !{investigate{"description":"","label":"Process events for the DNS-querying 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":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when Office, a browser child, a script host, a service session, or an unexpected remote session launched the lookup; lower concern when parent, command line, user, and session all match one recognized troubleshooting, updater, endpoint-management, or managed connectivity-check workflow. + +- Did the process connect to the resolved public-IP service or pivot to other external infrastructure? + - Focus: same-process network events on `host.id` and `process.entity_id`, separating DNS results from connections and correlating `dns.resolved_ip` to `destination.ip`, `destination.port`, and `destination.as.organization.name`. !{investigate{"description":"","label":"Network events for the DNS-querying 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: Missing network telemetry is unresolved, not benign. When present, treat `dns.question.name` as DNS evidence and `destination.ip` as connection evidence, including direct public-IP connections that bypass DNS. + - Implication: escalate when the process reaches the resolved service, contacts unrelated public infrastructure, or later connects directly to public IPs without DNS; lower concern only when connection telemetry shows no related external connection or an environment-confirmed proxy path aligned with the same workflow. + +- Did the same process launch follow-on commands that turn the lookup into staging, discovery, or C2 preparation? + - Focus: child process starts where `process.parent.entity_id` matches `process.entity_id`: `process.name`, `process.command_line`, `process.executable`, and `process.code_signature.subject_name`. !{investigate{"description":"","label":"Child processes spawned by the DNS-querying process","providers":[[{"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"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when shells, downloaders, installers, reconnaissance commands, or persistence tooling follow the lookup; lower concern when no child activity appears and earlier identity and lineage support one recognized connectivity check. + +- If local evidence stays suspicious or unresolved, do related alerts show the same binary-and-domain tuple around this user or host? + - Focus: related alert history for `user.id` and `host.id`: `dns.question.name`, `process.hash.sha256`, `process.code_signature.subject_name`, and recovered `process.parent.executable`. Review user and host alerts only after local DNS result, lineage, and follow-on network checks stay suspicious or unresolved. + - !{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 the case when the same hash, signer, parent, and public-IP service recur across other hosts for the same user or other users on the same host; keep response local when related alerts remain limited to one confirmed maintenance cohort. + +- Based on DNS outcome, binary identity, launch chain, same-process network behavior, child processes, and scope, what disposition is supported? + - Implication: escalate on unauthorized public-IP discovery plus suspicious lineage, external egress, child commands, or spread; close only when DNS outcome, binary identity, parent chain, user/session context, connection behavior, child activity, and scope bind one recognized workflow with no contradictions; preserve mixed or incomplete cases and escalate. + + +*False positive analysis* + + +- Administrative troubleshooting, software updater, endpoint-management, and managed connectivity-check workflows may query public-IP services to confirm egress or NAT behavior. Confirm that identity (`process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`), lineage (`process.parent.executable`, `process.parent.command_line`), user/session context, DNS evidence (`dns.question.name`, `dns.resolved_ip`), and any connection evidence converge on the same exact workflow. Without organizational confirmation, close only when telemetry proves the exact component and workflow; otherwise treat the pattern as candidate exception evidence. +- Before creating an exception, require a stable `process.hash.sha256` or `process.code_signature.subject_name`, `process.parent.executable`, the specific `dns.question.name`, and scope anchor (`host.id`, `host.name`, or `user.id`). Avoid exceptions on `dns.question.name` alone, `process.name` alone, or the full public-IP service list because benign tooling and malware use the same services. + + +*Response and remediation* + + +- If confirmed benign, document the exact evidence that proved the workflow: binary identity, parent chain, user/session context, DNS result, connection behavior, and recurrence scope. Then reverse any temporary containment and build a narrow exception only for that confirmed workflow. +- If suspicious but unconfirmed, preserve the alert, process start, DNS result, same-process connection events, child process starts, and related alert history before containment. Apply reversible containment such as temporary domain or DNS blocking, outbound restrictions for the affected process or host, or heightened monitoring on the affected `host.id` or `user.id`; escalate to host isolation only if follow-on child processes, suspicious external egress, or broader spread appears and host criticality allows it. +- If confirmed malicious, isolate the host or restrict egress when binary identity, lineage, DNS, connection, or child-process evidence shows unauthorized internet discovery or pre-C2 activity. Block confirmed malicious `dns.question.name`, `dns.resolved_ip`, `destination.ip`, `process.hash.sha256`, and related domains, then scope other hosts and users for the same indicators before terminating processes or deleting artifacts. +- Eradicate only the scripts, binaries, scheduled tasks, run keys, or configuration changes identified during the investigation after scoping related hosts and users. Remediate the launcher, user context, or deployment path that introduced the public-IP lookup. +- Post-incident hardening: restrict unsigned or user-writable scripting and LOLBin execution where feasible, keep endpoint DNS and network telemetry enabled, and document any connectivity-check pattern or visibility gap for future triage. + + +==== 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-22-setup[Sysmon Event ID 22 - DNS Query] + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type == "windows" and dns.question.name != null and process.name != null and +( + process.name : ("MSBuild.exe", "mshta.exe", "wscript.exe", "powershell.exe", "pwsh.exe", "msiexec.exe", "rundll32.exe", + "bitsadmin.exe", "InstallUtil.exe", "RegAsm.exe", "vbc.exe", "RegSvcs.exe", "python.exe", "regsvr32.exe", "dllhost.exe", + "node.exe", "javaw.exe", "java.exe", "*.pif", "*.com", "curl.exe", "bun.exe") 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 : + ( + "ip-api.com", + "checkip.dyndns.org", + "api.ipify.org", + "api.ipify.com", + "whatismyip.akamai.com", + "bot.whatismyipaddress.com", + "ifcfg.me", + "ident.me", + "ipof.in", + "ip.tyk.nu", + "icanhazip.com", + "curlmyip.com", + "wgetip.com", + "eth0.me", + "ipecho.net", + "ip.appspot.com", + "api.myip.com", + "geoiptool.com", + "api.2ip.ua", + "api.ip.sb", + "ipinfo.io", + "checkip.amazonaws.com", + "wtfismyip.com", + "iplogger.*", + "freegeoip.net", + "freegeoip.app", + "geoplugin.net", + "myip.dnsomatic.com", + "www.geoplugin.net", + "api64.ipify.org", + "ip4.seeip.org", + "*.geojs.io", + "*portmap.io", + "api.db-ip.com", + "geolocation-db.com", + "httpbin.org", + "myip.opendns.com" + ) and +not ( + process.executable : ( + "?:\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\*.exe", + "\\Device\\HarddiskVolume*\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\*.exe" + ) and user.id in ("S-1-5-18", "S-1-5-19") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Sub-technique: +** Name: Internet Connection Discovery +** ID: T1016.001 +** Reference URL: https://attack.mitre.org/techniques/T1016/001/ +* 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/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-thrift-rpc-method-from-an-external-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-thrift-rpc-method-from-an-external-client.asciidoc new file mode 100644 index 0000000000..2804f2208e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-thrift-rpc-method-from-an-external-client.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-29-thrift-rpc-method-from-an-external-client]] +=== Thrift RPC Method from an External Client + +Identifies the first decoded Apache Thrift RPC relationship from a public client address to a server. Thrift commonly connects trusted internal microservices and data platforms, and an externally originated method invocation can indicate an exposed service, unauthorized access, or exploitation of a public-facing Thrift endpoint. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-network_traffic.thrift-* + +*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://nvd.nist.gov/vuln/detail/CVE-2018-1320 +* https://attack.mitre.org/techniques/T1190/ +* https://thrift.apache.org/docs/ + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Network Packet Capture +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Thrift RPC Method from an External Client* + + +Thrift is frequently used by internal microservices and Hadoop ecosystem services such as HBase, Hive, Spark, and Impala. Many deployments rely on network trust or application-specific authentication. This rule uses a five-day new-terms history window to surface the first observed public client and Thrift server pair that completes a decoded method invocation. + +The alert proves that a Thrift transaction was decoded, but it does not prove authentication bypass or successful exploitation. + + +*Possible investigation steps* + + +- Review `client.ip`, `server.ip`, `server.port`, `network_traffic.thrift.service`, `network_traffic.thrift.method`, `network_traffic.thrift.path`, `network_traffic.thrift.exceptions`, and `network.community_id`. +- Identify the server application and determine whether the service is intended to accept Internet originated Thrift calls. +- Validate the client against partner, VPN, administrator, and approved service inventories. +- Review the service IDL and determine whether the invoked method reads sensitive data, changes configuration, deletes resources, or executes jobs. +- Correlate with service authentication and audit logs because the passive transaction does not expose authoritative authentication state. + + +*False positive analysis* + + +- Authorized partner APIs and intentionally public Thrift services may alert on a new client/server relationship. +- NAT, proxies, or sensor placement can cause an expected caller to appear under a public address. +- Add narrow exceptions for approved client and server pairs rather than excluding a service or method globally. + + +*Response and remediation* + + +- Restrict exposed Thrift listeners to approved networks and require authenticated, encrypted transport. +- Block unauthorized clients and isolate the server if sensitive or administrative methods were invoked. +- Review downstream data access and endpoint activity for evidence of collection, lateral movement, or execution. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Network Packet Capture integration with the Thrift protocol analyzer enabled. Packetbeat +supports TBinary over TSocket or TFramed transport. Compact, JSON, HTTP-wrapped, SASL-wrapped, custom, and encrypted +Thrift transports may not decode. Configure the relevant service IDL files so service, method, parameter, and exception +names are available where supported. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:network_traffic.thrift and +client.ip:( + * and + not ( + 10.0.0.0/8 or + 100.64.0.0/10 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.2.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.88.99.0/24 or + 192.168.0.0/16 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 + 224.0.0.0/4 or + 240.0.0.0/4 or + "::1" or + "fc00::/7" or + "fe80::/10" or + "ff00::/8" + ) +) and +server.ip:* and +network_traffic.thrift.method:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-unusual-base64-encoding-decoding-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-unusual-base64-encoding-decoding-activity.asciidoc new file mode 100644 index 0000000000..1b9f5867c9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-unusual-base64-encoding-decoding-activity.asciidoc @@ -0,0 +1,248 @@ +[[prebuilt-rule-8-19-29-unusual-base64-encoding-decoding-activity]] +=== Unusual Base64 Encoding/Decoding Activity + +This rule leverages ESQL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or network-based security controls. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 13 + +*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 Base64 Encoding/Decoding Activity* + +Base64 encoding is a method to convert binary data into ASCII text, often used for data transmission. Adversaries exploit this to obfuscate malicious payloads or commands, bypassing security controls. The detection rule identifies suspicious Base64 activity on Linux by monitoring specific processes and command patterns, flagging anomalies for further investigation. + + +*Possible investigation steps* + + +- Review the process name and command line arguments to understand the context of the Base64 activity. Check if the process name matches known legitimate applications or scripts. +- Examine the timestamp of the event to determine if the activity occurred during normal operational hours or if it coincides with other suspicious activities. +- Investigate the host operating system type and agent ID to identify the specific Linux system involved and assess if it has a history of similar alerts or other security incidents. +- Analyze the process command line for any unusual patterns or parameters that might indicate obfuscation or malicious intent, such as the presence of decode flags or unexpected Base64 operations. +- Correlate the event with other logs or alerts from the same host or network to identify potential lateral movement or coordinated attacks. +- Check for any recent changes or deployments on the affected system that might explain the Base64 activity, such as new software installations or updates. +- Consult threat intelligence sources to determine if the observed Base64 patterns or command line arguments are associated with known malware or attack techniques. + + +*False positive analysis* + + +- Routine administrative scripts may use base64 encoding for legitimate data processing tasks. Review the process.command_line and process.args fields to identify known scripts and consider excluding them from the rule. +- Backup or data transfer operations might employ base64 encoding to handle binary data. Verify the process.name and process.command_line to ensure these operations are recognized and add exceptions for these specific processes. +- Development environments often use base64 encoding for testing purposes. Identify development-related processes by examining the process.name and process.command_line and exclude them if they are part of regular development activities. +- Automated system monitoring tools might trigger this rule if they use base64 encoding for log or data analysis. Check the agent.id and process.command_line to confirm these tools and exclude them from the rule if they are verified as non-threatening. +- Security tools that perform data encoding for analysis or reporting could be flagged. Validate these tools by reviewing the process.name and process.command_line and create exceptions for them if they are part of the security infrastructure. + + +*Response and remediation* + + +- Isolate the affected Linux system from the network to prevent further data exfiltration or lateral movement by the adversary. +- Terminate any suspicious processes identified by the alert, particularly those involving base64 encoding/decoding, to halt potential malicious activity. +- Conduct a thorough review of the process command lines and arguments flagged by the alert to identify any malicious scripts or payloads. Remove or quarantine these files as necessary. +- Check for any unauthorized user accounts or privilege escalations that may have been established during the attack and revoke access immediately. +- Restore any affected systems or files from a known good backup to ensure the integrity of the system and data. +- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the suspicious base64 activity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts exist. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.process-* metadata _id, _index, _version +| mv_expand event.action +| where + host.os.type == "linux" and + event.type == "start" and + event.action == "exec" and ( + ( + process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and + (process.args like "--d*" or process.args like "-d*") + ) or + ( + process.name == "openssl" and + process.args == "enc" and + process.args in ("-d", "-base64", "-a") + ) or + ( + process.name like "python*" and ( + ( + process.args == "base64" and + process.args in ("-d", "-u", "-t") + ) or + ( + process.args == "-c" and + process.command_line like "*base64*" and + process.command_line like "*b64decode*" + ) + ) + ) or + ( + process.name like "perl*" and + process.command_line like "*decode_base64*" + ) or + ( + process.name like "ruby*" and + process.args == "-e" and + process.command_line like "*Base64.decode64*" + ) + ) +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + process.name, + process.args, + process.command_line, + process.parent.name, + process.parent.command_line, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace +| stats + Esql.event_count = count(), + Esql.process_parent_name_values = values(process.parent.name), + Esql.process_parent_command_line_values = values(process.parent.command_line), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by process.name, process.command_line +| where + Esql.agent_id_count_distinct == 1 and + Esql.event_count < 15 +| sort Esql.event_count asc + +// Extract unique values to ECS fields for alerts exclusion +| eval agent.id = mv_min(Esql.agent_id_values), + host.name = mv_min(Esql.host_name_values) + +| keep agent.id, host.name, process.name, process.command_line, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-unusual-file-creation-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-unusual-file-creation-via-web-server.asciidoc new file mode 100644 index 0000000000..9a8ecad8d6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rule-8-19-29-unusual-file-creation-via-web-server.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-29-unusual-file-creation-via-web-server]] +=== Unusual File Creation via Web Server + +This rule leverages the "new_terms" rule type to detect unusual file creations originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical file creations. As file creations from web server processes are common, the "new_terms" rule type approach helps to identify deviations from normal behavior. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.file* + +*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 +* Domain: Web +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Command and Control +* Tactic: Initial Access +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual File Creation via Web Server* + + +This alert flags a Linux web server process creating or renaming a file in web content or application directories that it does not normally touch, which can reveal a compromised service writing attacker-controlled content. That matters because web-facing processes rarely need to drop new executable or template files outside normal deployment activity. A common pattern is an intruder exploiting a vulnerable upload handler or plugin to place a web shell, JSP, PHP, or script-backed page under the site root for persistent remote access. + + +*Possible investigation steps* + + +- Determine whether the file aligns with an approved deployment, plugin or theme update, package installation, or administrator change in the same time window by reviewing change records and system update history. +- Inspect the file contents, hash, ownership, permissions, and timestamps for signs of a web shell, dropped payload, hidden redirect, or script stager, and compare it with known-good application files from the same host or image. +- Review the web service’s parent and child activity around the event for spawned shells, interpreters, archive extraction, or permission changes that would indicate exploitation followed by payload execution or persistence setup. +- Correlate nearby web access, reverse-proxy, and application log events to identify suspicious upload, template-edit, admin-panel, deserialization, or remote-code-execution requests immediately before the file appeared and any follow-up requests to the new file. +- Scope the compromise by searching the host and peer web servers for similarly named files, unexpected cron or systemd persistence, modified startup scripts, or outbound connections made by the web service account after the creation event. + + +*False positive analysis* + + +- Approved application deployment, patching, or first-run initialization can cause the web server or application server to create new files in the web root, so verify the event time against authorized change activity and confirm the file path, owner, and hash match the expected release contents. +- Legitimate web application features such as user uploads or automatic generation of images, media, attachments, or cache files can create new content under upload-facing directories, so review nearby web or application requests and confirm the file extension, location, and contents are consistent with normal business use. + + +*Response and remediation* + + +- Isolate the affected web server from the internet and internal network, remove it from the load balancer, and temporarily disable the compromised site or virtual host while keeping only secured management access for containment. +- Eradicate attacker persistence by deleting the malicious web shell or dropped script, removing any unauthorized cron jobs, systemd units, startup scripts, SSH keys, or writable symlinks created by the web service account, and disabling any backdoored application user or admin account. +- Restore the service to a known-good state by rebuilding the host from a trusted image or redeploying the application from clean source, recovering web content and configuration from a verified backup taken before the file appeared, and validating expected ownership and permissions across the web root. +- Rotate all secrets exposed to the host, including web application credentials, API tokens, database passwords, and TLS private keys, and invalidate active sessions or cookies if the malicious file could have intercepted user or administrator access. +- Escalate to incident response immediately if you find the same malicious file on multiple web servers, observe the web process spawning a shell or making outbound command-and-control connections, or confirm access to databases, payment data, or domain credentials. +- Harden the environment by patching the exploited CMS, plugin, framework, or server component, restricting the web service account to only required write paths, disabling script execution in upload directories, and adding detections for new executable or template files under the web root. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:file and host.os.type:linux and event.action:(creation or rename) and ( + process.name: ( + "nginx" or "apache2" or "httpd" or "caddy" or "lighttpd" or "httpd.worker" or "httpd-worker" or "httpd-prefork" or + "php-cgi" or "php-fcgi" or "php-cgi.cagefs" or "frankenphp" or "lshttpd" or "litespeed" or "openlitespeed" or + "fcgiwrap" or "uwsgi" or "daphne" or "uvicorn" or "hypercorn" or "granian" or "waitress-serve" or "flask" or + "puma" or "unicorn" or "unicorn_rails" or "thin" or "rackup" or "mongrel_rails" or "starman" or "plackup" or + "twiggy" or "hypnotoad" or "starlet" or "unitd" or "unitd-debug" or php-fpm* or lsphp* or gunicorn* or + "nginx3" or "apache" or *.cgi or *.fcgi + ) or + (process.name: "java" and file.extension: ("jsp" or "jspx" or "jspf" or "tag" or "tagx" or "war" or "ear")) or + (process.name: ("node" or "nodejs") and file.extension: ("js" or "mjs" or "cjs" or "ts" or "mts" or "cts")) or + (process.name: "dotnet" and file.extension: ("cshtml" or "razor")) or + (process.name: (mono* or xsp* or mod-mono-server* or fastcgi-mono-server*) and file.extension: ("asp" or "aspx" or "ashx" or "asmx" or "ascx" or "cshtml")) or + (process.name: python* and file.extension: ("wsgi" or "cgi" or "fcgi")) or + (process.name: ruby* and file.extension: ("erb" or "ru")) or + (process.name: perl* and file.extension: ("cgi" or "fcgi" or "psgi")) or + (process.name: lua* and file.extension: ("lua" or "luac")) +) and +file.path:( + /home/*/* or /var/www/* or /srv/www/* or /srv/http/* or /usr/share/nginx/* or /var/lib/nginx/* or + /usr/share/caddy/* or /usr/local/lsws/* or /opt/bitnami/* or */sites/*/files/* or /opt/easyengine/* or + */wp-content/* or */httpdocs/* or */httpsdocs/* or */htdocs/* or */wwwroot/* or */webroot/* or */cgi-bin/* or + */upload/* or */uploads/* or */images/* or */media/* or */userfiles/* or */attachments/* or + /usr/share/webapps/* or /usr/share/zabbix/* or /usr/share/phpmyadmin/* or /usr/share/phpMyAdmin/* or + /var/lib/roundcube/* or /usr/share/cacti/* or /usr/share/nagios* or /var/lib/tomcat* or /usr/share/tomcat* or + /usr/local/tomcat/* or /opt/tomcat* or /var/lib/jetty* or /usr/share/jetty* or + /usr/local/cpanel/* or /usr/local/psa* or /opt/psa/admin/* or /usr/share/webmin/* or + /usr/libexec/webmin/* or /usr/local/nginx/* or /usr/local/apache* or /usr/sap/* or /opt/rh/* or + */public_html/* or */private_html/* or */public/* or */private/* or */deployments/* or */autodeploy/* or + */dropins/* or */installedApps/* or /srv/caddy/* or /usr/local/openresty/* or */fileadmin/* or */custom_apps/* or + */vhost* or /opt/apache-tomcat* or /opt/jetty* or /usr/local/jetty* or */wildfly*/* or */jboss*/* or */glassfish/* or + */user_projects/domains/* or */resin*/webapps/* or */installedApps/* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rules-8-19-29-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rules-8-19-29-appendix.asciidoc new file mode 100644 index 0000000000..fd65f7d330 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rules-8-19-29-appendix.asciidoc @@ -0,0 +1,77 @@ +["appendix",role="exclude",id="prebuilt-rule-8-19-29-prebuilt-rules-8-19-29-appendix"] += Downloadable rule update v8.19.29 + +This section lists all updates associated with version 8.19.29 of the Fleet integration *Prebuilt Security Detection Rules*. + + +include::prebuilt-rule-8-19-29-potential-tunneling-via-tailscaled.asciidoc[] +include::prebuilt-rule-8-19-29-aws-s3-bucket-acl-modified-to-allow-public-access-by-new-identity.asciidoc[] +include::prebuilt-rule-8-19-29-aws-ec2-nacl-entry-created-or-replaced-allowing-all-traffic-by-new-identity.asciidoc[] +include::prebuilt-rule-8-19-29-aws-iam-permission-boundary-or-guardrail-policy-deleted-by-unusual-identity.asciidoc[] +include::prebuilt-rule-8-19-29-aws-batch-job-submitted-with-container-override-by-unusual-identity.asciidoc[] +include::prebuilt-rule-8-19-29-aws-iam-user-self-created-access-key-subsequently-used.asciidoc[] +include::prebuilt-rule-8-19-29-aws-sagemaker-execution-role-passed-by-unusual-principal.asciidoc[] +include::prebuilt-rule-8-19-29-aws-bedrock-high-risk-filesystem-or-execution-tool-invocation.asciidoc[] +include::prebuilt-rule-8-19-29-azure-aks-coredns-or-kube-dns-configuration-modified.asciidoc[] +include::prebuilt-rule-8-19-29-azure-aks-certificate-signing-request-created-or-approved.asciidoc[] +include::prebuilt-rule-8-19-29-azure-aks-secret-get-or-list-with-suspicious-user-agent.asciidoc[] +include::prebuilt-rule-8-19-29-azure-aks-kubernetes-events-deleted.asciidoc[] +include::prebuilt-rule-8-19-29-azure-aks-potential-api-enumeration-by-user.asciidoc[] +include::prebuilt-rule-8-19-29-azure-aks-suspicious-self-subject-review-by-service-account-or-node-identity.asciidoc[] +include::prebuilt-rule-8-19-29-azure-aks-ephemeral-container-added-to-pod.asciidoc[] +include::prebuilt-rule-8-19-29-gke-secret-access-from-node-or-denied-service-account.asciidoc[] +include::prebuilt-rule-8-19-29-gke-secret-access-via-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-29-gke-unusual-service-account-secret-access-via-new-user-agent.asciidoc[] +include::prebuilt-rule-8-19-29-gke-endpoint-permission-enumeration.asciidoc[] +include::prebuilt-rule-8-19-29-gke-multi-resource-discovery.asciidoc[] +include::prebuilt-rule-8-19-29-gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc[] +include::prebuilt-rule-8-19-29-direct-process-execution-via-background-utility.asciidoc[] +include::prebuilt-rule-8-19-29-unusual-file-creation-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-29-suspicious-uid-change-to-root-via-python.asciidoc[] +include::prebuilt-rule-8-19-29-first-time-seen-nfs-auth-sys-root-uid-access.asciidoc[] +include::prebuilt-rule-8-19-29-multiple-sonicwall-login-failures-followed-by-successful-login.asciidoc[] +include::prebuilt-rule-8-19-29-cassandra-javascript-udf-creation.asciidoc[] +include::prebuilt-rule-8-19-29-postgresql-copy-program-command-execution.asciidoc[] +include::prebuilt-rule-8-19-29-successful-amqp-multi-queue-purge-burst.asciidoc[] +include::prebuilt-rule-8-19-29-first-time-destructive-mongodb-command-from-a-client-ip.asciidoc[] +include::prebuilt-rule-8-19-29-first-time-seen-memcached-writer.asciidoc[] +include::prebuilt-rule-8-19-29-thrift-rpc-method-from-an-external-client.asciidoc[] +include::prebuilt-rule-8-19-29-mysql-user-defined-function-injection.asciidoc[] +include::prebuilt-rule-8-19-29-potential-edr-freeze-via-werfaultsecure-abuse.asciidoc[] +include::prebuilt-rule-8-19-29-mark-of-the-web-removal-by-an-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-29-potential-data-exfiltration-through-curl.asciidoc[] +include::prebuilt-rule-8-19-29-correlated-alerts-on-similar-user-identities.asciidoc[] +include::prebuilt-rule-8-19-29-alerts-in-different-att-ck-tactics-by-host.asciidoc[] +include::prebuilt-rule-8-19-29-aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc[] +include::prebuilt-rule-8-19-29-entra-id-high-risk-sign-in.asciidoc[] +include::prebuilt-rule-8-19-29-entra-id-user-sign-in-with-unusual-client.asciidoc[] +include::prebuilt-rule-8-19-29-statistical-model-detected-c2-beaconing-activity.asciidoc[] +include::prebuilt-rule-8-19-29-statistical-model-detected-c2-beaconing-activity-with-high-confidence.asciidoc[] +include::prebuilt-rule-8-19-29-m365-identity-login-from-atypical-region.asciidoc[] +include::prebuilt-rule-8-19-29-unusual-base64-encoding-decoding-activity.asciidoc[] +include::prebuilt-rule-8-19-29-php-file-creation-in-wordpress-plugin-directory.asciidoc[] +include::prebuilt-rule-8-19-29-suspicious-curl-from-macos-application.asciidoc[] +include::prebuilt-rule-8-19-29-external-ip-address-discovery-via-curl.asciidoc[] +include::prebuilt-rule-8-19-29-emond-rules-creation-or-modification.asciidoc[] +include::prebuilt-rule-8-19-29-spike-in-firewall-denies.asciidoc[] +include::prebuilt-rule-8-19-29-spike-in-network-traffic.asciidoc[] +include::prebuilt-rule-8-19-29-network-traffic-to-rare-destination-country.asciidoc[] +include::prebuilt-rule-8-19-29-spike-in-network-traffic-to-a-country.asciidoc[] +include::prebuilt-rule-8-19-29-suspicious-inter-process-communication-via-outlook.asciidoc[] +include::prebuilt-rule-8-19-29-connection-to-commonly-abused-web-services.asciidoc[] +include::prebuilt-rule-8-19-29-potential-ssh-reverse-port-forwarding.asciidoc[] +include::prebuilt-rule-8-19-29-potential-credential-access-via-windows-utilities.asciidoc[] +include::prebuilt-rule-8-19-29-potential-credential-access-via-dcsync.asciidoc[] +include::prebuilt-rule-8-19-29-potential-computer-account-ntlm-relay-activity.asciidoc[] +include::prebuilt-rule-8-19-29-suspicious-execution-via-windows-subsystem-for-linux.asciidoc[] +include::prebuilt-rule-8-19-29-system-public-ip-discovery-via-dns-query.asciidoc[] +include::prebuilt-rule-8-19-29-mofcomp-activity.asciidoc[] +include::prebuilt-rule-8-19-29-suspicious-execution-with-nodejs.asciidoc[] +include::prebuilt-rule-8-19-29-suspicious-windows-powershell-arguments.asciidoc[] +include::prebuilt-rule-8-19-29-potential-lateral-tool-transfer-via-smb-share.asciidoc[] +include::prebuilt-rule-8-19-29-persistence-via-scheduled-job-creation.asciidoc[] +include::prebuilt-rule-8-19-29-local-scheduled-task-creation.asciidoc[] +include::prebuilt-rule-8-19-29-suspicious-service-was-installed-in-the-system.asciidoc[] +include::prebuilt-rule-8-19-29-component-object-model-hijacking.asciidoc[] +include::prebuilt-rule-8-19-29-multiple-alerts-in-different-att-ck-tactics-on-a-single-host.asciidoc[] +include::prebuilt-rule-8-19-29-potential-cve-2025-41244-vmtoolsd-lpe-exploitation-attempt.asciidoc[] diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rules-8-19-29-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rules-8-19-29-summary.asciidoc new file mode 100644 index 0000000000..652300f34d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-29/prebuilt-rules-8-19-29-summary.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-29-prebuilt-rules-8-19-29-summary]] +[role="xpack"] +== Update v8.19.29 + +This section lists all updates associated with version 8.19.29 of the Fleet integration *Prebuilt Security Detection Rules*. + + +[width="100%",options="header"] +|============================================== +|Rule |Description |Status |Version + +|<> | Identifies the use of Tailscaled to potentially tunnel network traffic. This can be used by attackers to enable routing of network packets that would otherwise not reach their intended destination, or to bypass network restrictions and/or hide traffic from network monitoring. | new | 1 + +|<> | Detects a principal modifying an S3 bucket ACL to grant public read or write access that has not been observed doing so within the history window, using canned ACLs such as public-read or public-read-write. ACL-based public access is a distinct API path (PutBucketAcl) that can bypass some Block Public Access controls. Monitoring for new identities performing this change helps surface freshly compromised credentials being used to stage data for exfiltration or inadvertently expose sensitive content. | new | 1 + +|<> | Detects a principal account creating or replacing - or attempts to create or replace - an AWS Network Access Control List (NACL) entry using protocol -1 (all traffic). Both successful and failed outcomes are included. A NACL entry with protocol -1 passes all traffic regardless of port, which would disable network-layer controls for the affected subnets. Monitoring for new identities performing this change helps surface freshly compromised credentials or unauthorized principals removing a defense-in-depth layer to facilitate lateral movement or data exfiltration. This signal only flags if this behavior was not observed historically in a specific time window. | new | 1 + +|<> | Detects the first time an AWS identity successfully deletes an IAM managed policy whose ARN contains guardrail-related keywords (for example Boundary, Deny, Restrict, Guard, SCP, Guardrail). Adversaries who have obtained elevated IAM privileges may delete policies to remove restrictive permissions boundaries, eliminate deny-based guardrails, or clean up after a privilege escalation operation. Infrastructure-as-code tools (Terraform, CloudFormation, Pulumi, and Ansible) are excluded because policy lifecycle management is a routine part of automated deployments. A policy deletion by an identity not seen performing this activity during the prior seven days may indicate newly compromised credentials being used to modify the account's permission structure. | new | 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. | new | 1 + +|<> | Detects an AWS IAM user using an existing credential to create a new access key for itself and subsequently using the new key within one hour. This behavior can indicate an adversary converting compromised credentials into an additional long-term credential for persistence. Unlike a standalone self-service key creation alert, requiring subsequent use of the new key reduces noise from unused or abandoned credential-rotation operations. | new | 1 + +|<> | Identifies the first time an IAM principal passes a given execution role (`roleArn`) to an Amazon SageMaker resource, via `CreateNotebookInstance`, `CreateTrainingJob`, `CreateProcessingJob`, `CreateAutoMLJob`, or `CreatePipeline`. These actions require `iam:PassRole` and attach an IAM role that the created resource then runs as. An adversary holding both SageMaker create permissions and a broad `iam:PassRole` grant can pass a more privileged role to a resource they control and execute code as that role, escalating privileges. The rule keys on the combination of the calling principal and the passed `roleArn`, so it surfaces a principal using an execution role it has not used before in the last 7 days; a role whose account differs from the caller's, or that is more privileged than the caller, is especially suspicious. | new | 1 + +|<> | Detects when a Bedrock model is prompted to invoke high-risk tools associated with shell execution, filesystem operations, or process spawning. Adversaries may use compromised AI agent pipelines or manipulated prompts to instruct the model to execute arbitrary system commands, read or write sensitive files, or spawn subprocesses — extending the blast radius of a credential compromise or prompt injection attack. | new | 2 + +|<> | Detects an identity creating or modifying the CoreDNS or kube-dns ConfigMap in the kube-system namespace on AKS (Azure Kubernetes Service), excluding known AKS control-plane and platform identities. Rewriting cluster DNS (by editing coredns/kube-dns or creating and editing coredns-custom) enables cluster-wide adversary-in-the-middle by redirecting internal service resolution to attacker-controlled IPs, allowing credential capture and traffic interception. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token is not excluded. | new | 1 + +|<> | Detects an identity creating a client-authentication CertificateSigningRequest (signer kubernetes.io/kube-apiserver-client) or approving a CSR on AKS (Azure Kubernetes Service), excluding node bootstrap and platform controllers. Adversaries submit and self-approve a CSR against the kube-apiserver-client signer to mint a long-lived client certificate for an arbitrary subject (for example a Common Name in system:masters), giving durable authenticated access that survives token revocation. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token forging a certificate is not excluded. | new | 1 + +|<> | Detects successful AKS (Azure Kubernetes Service) secret get or list operations where the user agent matches scripting runtimes (python, ruby, perl), command-line HTTP clients (curl, wget, HTTPie), or generic HTTP libraries (Go-http-client, okhttp, Apache-HttpClient, Guzzle, axios, undici) rather than typical kubectl or named controller traffic. Reading Kubernetes secrets with a generic client is a common credential-access step after a token or kubeconfig is stolen, and offensive tooling (for example peirates and kdigger) frequently reaches the API with a default Go HTTP client. | new | 1 + +|<> | Detects an identity deleting Kubernetes events on AKS (Azure Kubernetes Service), excluding known AKS control-plane and platform identities. Adversaries delete events (individually or in bulk via deletecollection) to remove evidence of pod creation, exec, or scheduling activity and impair incident response after operating in the cluster. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token wiping events is not excluded. | new | 1 + +|<> | Detects a single Kubernetes identity in AKS (Azure Kubernetes Service) that is denied (HTTP 403 Forbidden) across multiple distinct API resource types within a short window. Broad authorization failures spanning many resources are a strong signal of API enumeration (reconnaissance with a stolen service account token), as an actor probes what its credentials can reach before privilege escalation. Detection is based on the breadth of denied resources rather than the raw failure count, so single-resource controller retry loops do not trigger it. | new | 1 + +|<> | Detects AKS (Azure Kubernetes Service) service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC before privilege escalation. | new | 1 + +|<> | Detects an identity injecting an ephemeral (debug) container into a running AKS (Azure Kubernetes Service) pod via the pods/ephemeralcontainers subresource, excluding known AKS control-plane and platform identities. Ephemeral containers share the target pod's namespaces and give stealthy interactive access to its processes and mounted secrets without creating a new pod. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token used to attach a debug container is not excluded. | new | 1 + +|<> | Detects GKE Secrets API activity that should not occur in normal cluster operation: a node identity (system:node:*) performing secrets get or list, or a pod service account failing a secrets get. Kubelet and node credentials are not expected to call the Secrets API for enumeration or direct reads, and a denied service-account secret get could indicate stolen-token probing or over-privileged tooling reaching beyond its RBAC. | new | 1 + +|<> | Detects GKE secrets get or list requests from a previously unseen combination of source IP, identity, and user agent, excluding the default Kubernetes client placeholder. Attackers who compromise a pod or steal a kubeconfig often use curl, custom scripts, or atypical clients from a new host to read service-account tokens, registry credentials, or application secrets. Anonymous identities are excluded; use dedicated anonymous-access rules for unauthenticated probing. | new | 1 + +|<> | Detects the first successful GKE secrets.get by a pod service account from a previously unseen combination of service-account identity, user agent, and source IP. Controllers routinely read secrets with a stable client fingerprint; a new user agent or source for that service account could indicate a stolen token used outside the workload (for example curl, a custom script, or kubectl from an unexpected host). | new | 1 + +|<> | Detects a single authenticated GKE identity from one source IP issuing a burst of API calls across many distinct actions and resources with a mix of successful and failed outcomes. That pattern is consistent with automated RBAC permission enumeration rather than steady-state controller traffic. Anonymous probing is covered by a separate rule. | new | 1 + +|<> | Adversaries who land credentials in a GKE cluster—or abuse an over-privileged token, often map the environment before exfiltration or privilege escalation. A practical first pass is to learn where workloads run, how the cluster is partitioned, and what RBAC exists at namespace vs cluster scope. Rapid get/list traffic across many distinct API resource kinds that answer those questions (namespaces, workloads, roles, cluster-wide roles) is a common setup and orientation pattern for both interactive attackers and automated recon scripts. This rule highlights that cross-resource burst from a single client fingerprint within a one-minute bucket when both cluster-layout and RBAC resource kinds are touched, so analysts can separate routine automation from potential discovery ahead of follow-on actions. | new | 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. | new | 1 + +|<> | This is a New Terms rule that identifies the first occurrence of setsid or nohup being used to directly execute a process on a host. Attackers may leverage these tools to execute commands in a new session and/or to ignore signals. | new | 1 + +|<> | This rule leverages the "new_terms" rule type to detect unusual file creations originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical file creations. As file creations from web server processes are common, the "new_terms" rule type approach helps to identify deviations from normal behavior. | new | 1 + +|<> | Detects a UID change event to 0 (root) where the responsible process is a Python interpreter running from a user- or world-writable working directory and the parent process is non-root. This may be indicative of a local privilege escalation exploit executed via Python. Using the new terms feature, noise from automated tools or system processes is partially filtered out. | new | 1 + +|<> | Identifies the first source and destination IP pair observed in a five-day history window where an NFS client asserts AUTH_SYS (RPC UNIX) credentials with UID 0 (root). NFSv3 and NFSv4 clients can claim arbitrary UIDs through AUTH_SYS, and weak export controls may honor root-equivalent access from unexpected hosts. This is a common precursor to unauthorized mounts, sensitive file reads, and remote encryption of exported shares. | new | 1 + +|<> | Identifies multiple failed SonicWall authentication attempts against several user accounts from one source IP, followed by a successful remote-access login from the same source to the same appliance. This may indicate successful password spraying, credential stuffing, or password guessing. | new | 1 + +|<> | Identifies Cassandra Query Language statements that create a JavaScript user-defined function. On vulnerable and dangerously configured Cassandra servers, adversaries can abuse scripted UDF creation to escape the JavaScript sandbox and execute operating-system commands, including through CVE-2021-44521. | new | 1 + +|<> | Identifies PostgreSQL "COPY" statements that invoke an operating-system command through the "PROGRAM" option. A superuser or role with "pg_execute_server_program" can use this feature to execute arbitrary commands as the PostgreSQL service account, a technique used after credential compromise and by cryptomining campaigns. | new | 1 + +|<> | Identifies multiple successful AMQP queue purge operations issued by the same client to the same broker within a short period. The AMQP queue.purge method removes all messages from a queue that are not awaiting acknowledgment. Purging several distinct queues can indicate deliberate message destruction or disruption after broker credentials are compromised. | new | 2 + +|<> | Identifies the first client IP observed issuing MongoDB commands that can drop databases, collections, indexes, users, or roles within a five-day history window. Adversaries with access to an exposed or compromised MongoDB service may use these commands to destroy data, disrupt applications, or prepare a wipe-and-extort attack. | new | 1 + +|<> | Identifies the first successful or no-reply Memcached store command from a client to a server. Memcached commonly has no authentication, so an unauthorized writer can overwrite session tokens, poison cached application content, or alter security-sensitive state. This behavior can enable session hijacking such as the exposure described by CVE-2026-29093. | new | 1 + +|<> | Identifies the first decoded Apache Thrift RPC relationship from a public client address to a server. Thrift commonly connects trusted internal microservices and data platforms, and an externally originated method invocation can indicate an exposed service, unauthorized access, or exploitation of a public-facing Thrift endpoint. | new | 1 + +|<> | Identifies MySQL statements that create a user-defined function backed by a shared library. Adversaries with sufficient database privileges can place a malicious library in the MySQL plugin directory and register it with "CREATE FUNCTION ... SONAME", establishing a database-resident primitive for operating-system command execution. | new | 1 + +|<> | 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. | new | 1 + +|<> | Identifies an unusual process deleting the Zone.Identifier alternate data stream from an executable or Windows Installer package. Attackers can remove this stream to bypass Mark-of-the-Web protections. | new | 1 + +|<> | Detects the use of curl to upload files to an internet server. Threat actors often will collect and exfiltrate data on a system to their C2 server for review. Many threat actors have been observed using curl to upload the collected data. Use of curl in this way, while not inherently malicious, should be considered highly abnormal and suspicious activity. | update | 9 + +|<> | This rule correlates alerts from multiple integrations and event categories that involve different user.name values which may represent the same real-world identity. It uses an LLM-based similarity analysis to evaluate whether multiple user identifiers (e.g. naming variations, formats, aliases, or domain differences) likely belong to the same person. | update | 4 + +|<> | This rule correlates medium-or-higher severity alerts involving the same host from at least two distinct detection rules mapped to three or more ATT&CK tactics. Analysts can use this to prioritize triage and response, as this combination may indicate host compromise. | update | 7 + +|<> | Identifies an AWS principal performing a high volume of Amazon Bedrock inference API calls against a single model within a short window. Membership inference attacks require hundreds to thousands of statistically similar queries whose prompts and responses are intentionally content-benign, making guardrail- and content-based rules ineffective. This rule detects the high-frequency single-model probing pattern that precedes membership inference and related exfiltration via the inference API. It is a behavioral / volumetric precursor: it does not observe model confidence scores and a fixed call-count threshold only catches the loud variant, so paced, low-and-slow, or credential-distributed probing will evade it. Definitive membership inference detection requires ML anomaly analysis over per-entity inference-rate and response-distribution baselines. | update | 2 + +|<> | Identifies high risk Microsoft Entra ID sign-ins by leveraging Microsoft's Identity Protection machine learning and heuristics. Identity Protection categorizes risk into three tiers: low, medium, and high. While Microsoft does not provide specific details about how risk is calculated, each level brings higher confidence that the user or sign-in is compromised. | update | 112 + +|<> | Detects rare non-interactive sign-ins where an Entra ID client application authenticates on behalf of a principal user using an application (client) ID that is not commonly associated with that user's historical sign-in behavior. Adversaries with stolen credentials or OAuth tokens may abuse Entra ID–managed or first-party client IDs to perform on-behalf-of (OBO) authentication, blending into legitimate cloud traffic while avoiding traditional interactive sign-in flows. This technique is commonly observed in OAuth phishing, token theft, and access broker operations, and may precede lateral movement, persistence, or data access via Microsoft Graph or other cloud resources. The rule uses a New Terms approach to identify first-seen combinations of the UPN and Client ID within a defined history window, helping surface unexpected client usage that may indicate compromised identities, malicious automation, or unauthorized application impersonation. | update | 8 + +|<> | A statistical model has identified command-and-control (C2) beaconing activity. Beaconing can help attackers maintain stealthy communication with their C2 servers, receive instructions and payloads, exfiltrate data and maintain persistence in a network. | update | 11 + +|<> | A statistical model has identified command-and-control (C2) beaconing activity with high confidence. Beaconing can help attackers maintain stealthy communication with their C2 servers, receive instructions and payloads, exfiltrate data and maintain persistence in a network. | update | 10 + +|<> | Detects successful Microsoft 365 portal logins from a country and region the user has not previously authenticated from in a specific time window. Atypical regions are identified by combining the user's country and region geolocation history; an authentication from a new country/region pair for that user may indicate an adversary attempting to access the account from an unusual location or behind a VPN. | update | 12 + +|<> | This rule leverages ESQL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or network-based security controls. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. | update | 13 + +|<> | Detects the creation of a PHP file in the WordPress plugin directory, which is a common technique used by attackers to establish persistence on a compromised web server. Attackers may upload a malicious PHP file and call it from a web browser to gain remote access to the server. | update | 2 + +|<> | Detects the use of curl by a macOS application binary to connect to a raw IP URI and download a second stage payload. Threat actors often utilize a benign looking or legitimate application as a first stage dropper. Curl is commonly used as it doesn't enforce Gatekeeper checks. | update | 3 + +|<> | Detects applications making a curl request to a known public IP address lookup web service. Malware commonly performs this action during reconnaissance to assess potential targets and identify the victim's external IP address. | update | 2 + +|<> | Identifies the creation or modification of the Event Monitor Daemon (emond) rules. Adversaries may abuse this service by writing a rule to execute commands when a defined event occurs, such as system start up or user authentication. | update | 114 + +|<> | A machine learning job detected an unusually large spike in network traffic that was denied by network access control lists (ACLs) or firewall rules. Such a burst of denied traffic is usually caused by either 1) a mis-configured application or firewall or 2) suspicious or malicious activity. Unsuccessful attempts at network transit, in order to connect to command-and-control (C2), or engage in data exfiltration, may produce a burst of failed connections. This could also be due to unusually large amounts of reconnaissance or enumeration traffic. Denial-of-service attacks or traffic floods may also produce such a surge in traffic. | update | 110 + +|<> | A machine learning job detected an unusually large spike in network traffic. Such a burst of traffic, if not caused by a surge in business activity, can be due to suspicious or malicious activity. Large-scale data exfiltration may produce a burst of network traffic; this could also be due to unusually large amounts of reconnaissance or enumeration traffic. Denial-of-service attacks or traffic floods may also produce such a surge in traffic. | update | 109 + +|<> | A machine learning job detected a rare destination country name in the network logs. This can be due to initial access, persistence, command-and-control, or exfiltration activity. For example, when a user clicks on a link in a phishing email or opens a malicious document, a request may be sent to download and run a payload from a server in a country which does not normally appear in network traffic or business work-flows. Malware instances and persistence mechanisms may communicate with command-and-control (C2) infrastructure in their country of origin, which may be an unusual destination country for the source network. | update | 110 + +|<> | A machine learning job detected an unusually large spike in network activity to one destination country in the network logs. This could be due to unusually large amounts of reconnaissance or enumeration traffic. Data exfiltration activity may also produce such a surge in traffic to a destination country that does not normally appear in network traffic or business workflows. Malware instances and persistence mechanisms may communicate with command-and-control (C2) infrastructure in their country of origin, which may be an unusual destination country for the source network. | update | 111 + +|<> | Detects Inter-Process Communication with Outlook via Component Object Model from an unusual process. Adversaries may target user email to collect sensitive information or send email on their behalf via API. | update | 13 + +|<> | Adversaries may implement command and control (C2) communications that use common web services to hide their activity. This attack technique is typically targeted at an organization and uses web services common to the victim network, which allows the adversary to blend into legitimate traffic activity. These popular services are typically targeted since they have most likely been used before compromise, which helps malicious traffic blend in. | update | 132 + +|<> | 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. | update | 2 + +|<> | Identifies the execution of known Windows utilities often abused to dump LSASS memory or the Active Directory database (NTDS.dit) in preparation for credential access. | update | 322 + +|<> | This rule identifies when a User Account starts the Active Directory Replication Process. Attackers can use the DCSync technique to get credential information of individual accounts or the entire domain, thus compromising the entire domain. | update | 222 + +|<> | Identifies potential relay activities against a Computer account by identifying authentication events using the computer account coming from from hosts other than the server that owns the account. Attackers may relay the computer account hash after capturing it using forced authentication. | update | 111 + +|<> | Detects Linux Bash commands from the Windows Subsystem for Linux. Adversaries may enable and use WSL for Linux to avoid detection. | update | 214 + +|<> | Identifies DNS queries to known public IP address lookup web services from suspicious Windows processes, which can reveal external IP or internet-connectivity discovery before follow-on activity. | update | 5 + +|<> | Managed Object Format (MOF) files can be compiled locally or remotely through mofcomp.exe. Attackers may leverage MOF files to build their own namespaces and classes into the Windows Management Instrumentation (WMI) repository, or establish persistence using WMI Event Subscription. | update | 12 + +|<> | Identifies suspicious Node.js execution patterns, including PowerShell-launched module preloads and inline eval, decode, or child-process usage. | update | 5 + +|<> | Identifies the execution of PowerShell with suspicious argument values. This behavior is often observed during malware installation leveraging PowerShell. | update | 215 + +|<> | Identifies the creation or change of a Windows executable file over network shares. Adversaries may transfer tools or other files between systems in a compromised environment. | update | 114 + +|<> | A job can be used to schedule programs or scripts to be executed at a specified date and time. Adversaries may abuse task scheduling functionality to facilitate initial or recurring execution of malicious code. | update | 417 + +|<> | Indicates the creation of a scheduled task. Adversaries can use these to establish persistence, move laterally, and/or escalate privileges. | update | 214 + +|<> | Identifies the creation of a new Windows service with a suspicious service name or command value. Windows services typically run as SYSTEM and can be used for privilege escalation and persistence. | update | 118 + +|<> | Identifies Component Object Model (COM) hijacking via registry modification. Adversaries may establish persistence by executing malicious content triggered by hijacked references to COM objects. | update | 121 + +|<> | This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. | deprecated | 8 + +|<> | This rule looks for processes that behave like an attacker trying to exploit a known vulnerability in VMware tools (CVE-2025-41244). The vulnerable behavior involves the VMware tools service or its discovery scripts executing other programs to probe their version strings. An attacker can place a malicious program in a writable location (for example /tmp) and have the tools execute it with elevated privileges, resulting in local privilege escalation. The rule flags launches where vmtoolsd or the service discovery scripts start other child processes. | deprecated | 5 + +|============================================== diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc index c672d0cd2b..0d35052387 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 +|<> | 04 Aug 2026 | 35 | 34 | +This release includes new rules for Linux, AWS, GCP, Windows, Azure, Network Traffic, SonicWall, and macOS. New rules for Linux include detection for privilege escalation, persistence, execution, and command and control. New rules for AWS include detection for execution, collection, defense evasion, privilege escalation, and persistence. New rules for GCP include detection for discovery, privilege escalation, and credential access. New rules for Windows include detection for defense evasion and command and control. New rules for Azure include detection for discovery, credential access, defense evasion, and execution. New rules for Network Traffic include detection for impact, collection, initial access, execution, and persistence. New rules for SonicWall include detection for credential access. New rules for macOS include detection for command and control. Additionally, significant tuning for Linux, Windows, macOS, Azure, and Microsoft 365 rules improves efficacy and performance. + + |<> | 22 Jul 2026 | 55 | 95 | This release includes new rules for Linux, AWS, GCP, Windows, Azure, and Microsoft 365. New rules for Linux include detection for persistence. New rules for AWS include detection for defense evasion, impact, privilege escalation, credential access, and initial access. New rules for GCP include detection for privilege escalation, persistence, credential access, initial access, execution, impact, and discovery. New rules for Windows include detection for execution. New rules for Azure include detection for initial access, persistence, defense evasion, credential access, execution, and lateral movement. New rules for Microsoft 365 include detection for initial access. Additionally, significant tuning for Linux, Windows, macOS, AWS, GCP, Azure, and network rules improves efficacy and performance. @@ -153,3 +157,4 @@ include::downloadable-packages/8-19-25/prebuilt-rules-8-19-25-summary.asciidoc[l include::downloadable-packages/8-19-26/prebuilt-rules-8-19-26-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-27/prebuilt-rules-8-19-27-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-28/prebuilt-rules-8-19-28-summary.asciidoc[leveloffset=+1] +include::downloadable-packages/8-19-29/prebuilt-rules-8-19-29-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 4f9219e82c..45f99b6414 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc @@ -32,6 +32,8 @@ and their rule type is `machine_learning`. |<> |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 + |<> |Identifies an Amazon Bedrock API key phantom user (an IAM user whose name starts with "BedrockAPIKey-") acting as the caller of a non-Bedrock API request, such as IAM, STS, EC2, VPC, or KMS calls. These users are provisioned by AWS to back a Bedrock bearer token and carry the AmazonBedrockLimitedAccess managed policy, which also grants IAM, VPC, and KMS reconnaissance. A phantom user performing activity outside of Bedrock indicates its credentials are being used beyond their intended scope, which is the privilege-escalation path realized: an attacker who created standard IAM access keys for the phantom user is now using them for reconnaissance or lateral movement outside the Bedrock authentication boundary. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 |<> |Identifies an Amazon Bedrock API key (bearer token) being used to perform a destructive or anti-recovery control-plane action, such as deleting a guardrail, deleting a custom or imported model, removing provisioned throughput, or disabling model invocation logging. Bedrock API keys are bearer credentials intended for model invocation (InvokeModel, Converse); using one to delete Bedrock resources or disable logging is inconsistent with that purpose and is characteristic of LLMjacking or sabotage following key theft. Every Bedrock API key call is identifiable in CloudTrail by "additionalEventData.callWithBearerToken" being true. The rule matches regardless of outcome, because a destructive attempt via a bearer token is suspicious even when denied. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Tactic: Impact], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 @@ -62,6 +64,8 @@ and their rule type is `machine_learning`. |<> |Identifies multiple violations of AWS Bedrock guardrails by the same user in the same account over a session. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054] |None |9 +|<> |Detects when a Bedrock model is prompted to invoke high-risk tools associated with shell execution, filesystem operations, or process spawning. Adversaries may use compromised AI agent pipelines or manipulated prompts to instruct the model to execute arbitrary system commands, read or write sensitive files, or spawn subprocesses — extending the blast radius of a credential compromise or prompt injection attack. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS Bedrock], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |2 + |<> |Identifies an AWS principal performing a high volume of Amazon Bedrock inference API calls against a single model within a short window. Membership inference attacks require hundreds to thousands of statistically similar queries whose prompts and responses are intentionally content-benign, making guardrail- and content-based rules ineffective. This rule detects the high-frequency single-model probing pattern that precedes membership inference and related exfiltration via the inference API. It is a behavioral / volumetric precursor: it does not observe model confidence scores and a fixed call-count threshold only catches the loud variant, so paced, low-and-slow, or credential-distributed probing will evade it. Definitive membership inference detection requires ML anomaly analysis over per-entity inference-rate and response-distribution baselines. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Exfiltration], [Mitre Atlas: T0024], [Mitre Atlas: T0024.000], [Resources: Investigation Guide] |None |2 |<> |Identifies multiple AWS Bedrock executions in a one minute time window without guardrails by the same user in the same account over a session. Multiple consecutive executions implies that a user may be intentionally attempting to bypass security controls, by not routing the requests with the desired guardrail configuration in order to access sensitive information, or possibly exploit a vulnerability in the system. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054] |None |6 @@ -152,6 +156,8 @@ and their rule type is `machine_learning`. |<> |Identifies when a single AWS resource is making `DescribeInstances` API calls in more than 10 regions within a 30-second window. This could indicate a potential threat actor attempting to discover the AWS infrastructure across multiple regions using compromised credentials or a compromised instance. Adversaries may use this information to identify potential targets for further exploitation or to gain a better understanding of the target's infrastructure. |[Domain: Cloud], [Data Source: AWS], [Data Source: AWS EC2], [Resources: Investigation Guide], [Rule Type: BBR], [Use Case: Threat Detection], [Tactic: Discovery] |None |9 +|<> |Detects a principal account creating or replacing - or attempts to create or replace - an AWS Network Access Control List (NACL) entry using protocol -1 (all traffic). Both successful and failed outcomes are included. A NACL entry with protocol -1 passes all traffic regardless of port, which would disable network-layer controls for the affected subnets. Monitoring for new identities performing this change helps surface freshly compromised credentials or unauthorized principals removing a defense-in-depth layer to facilitate lateral movement or data exfiltration. This signal only flags if this behavior was not observed historically in a specific time window. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 + |<> |Identifies the creation of an AWS EC2 network access control list (ACL) or an entry in a network ACL with a specified rule number. Adversaries may exploit ACLs to establish persistence or exfiltrate data by creating permissive rules. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Network Security Monitoring], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |213 |<> |Identifies the deletion of an Amazon Elastic Compute Cloud (EC2) network access control list (ACL) or one of its ingress/egress entries. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Network Security Monitoring], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |212 @@ -232,6 +238,8 @@ and their rule type is `machine_learning`. |<> |Detects when an uncommon user or role creates an OpenID Connect (OIDC) Identity Provider in AWS IAM. OIDC providers enable web identity federation, allowing users authenticated by external identity providers (such as Google, GitHub, or custom OIDC-compliant providers) to assume IAM roles and access AWS resources. Adversaries who have gained administrative access may create rogue OIDC providers to establish persistent, federated access that survives credential rotation. This technique allows attackers to assume roles using tokens from an IdP they control. While OIDC provider creation is benign in some environments, it should still be validated against authorized infrastructure changes. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |4 +|<> |Detects the first time an AWS identity successfully deletes an IAM managed policy whose ARN contains guardrail-related keywords (for example Boundary, Deny, Restrict, Guard, SCP, Guardrail). Adversaries who have obtained elevated IAM privileges may delete policies to remove restrictive permissions boundaries, eliminate deny-based guardrails, or clean up after a privilege escalation operation. Infrastructure-as-code tools (Terraform, CloudFormation, Pulumi, and Ansible) are excluded because policy lifecycle management is a routine part of automated deployments. A policy deletion by an identity not seen performing this activity during the prior seven days may indicate newly compromised credentials being used to modify the account's permission structure. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Defense Evasion], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 + |<> |Identifies the modification or removal of an IAM permissions boundary on an IAM user or role. A permissions boundary caps the maximum permissions an identity can have, regardless of its attached identity policies. An adversary who can delete a boundary ("DeleteUserPermissionsBoundary", "DeleteRolePermissionsBoundary") or replace it with a more permissive one ("PutUserPermissionsBoundary", "PutRolePermissionsBoundary") can lift that cap and unlock permissions the identity's policies already grant, enabling privilege escalation. Boundary changes are infrequent and usually performed by a small set of administrators or infrastructure-as-code pipelines, so changes by unexpected principals warrant review. |[Domain: Cloud], [Domain: Identity], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 |<> |Detects repeated failed attempts to update an IAM role’s trust policy in an AWS account, consistent with role and user enumeration techniques. In this technique, an attacker who controls credentials in the current account repeatedly calls UpdateAssumeRolePolicy on a single role, cycling through guessed cross-account role or user ARNs as the principal. When those principals are invalid, IAM returns MalformedPolicyDocumentException, producing a burst of failed UpdateAssumeRolePolicy events. This rule alerts on that brute-force pattern originating from this account, which may indicate that the account is being used as attack infrastructure or that offensive tooling (such as Pacu) is running here. Note: this rule does not detect other accounts enumerating roles, because those API calls are logged in the caller’s account, not the target account. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Discovery], [Tactic: Credential Access] |None |216 @@ -254,6 +262,8 @@ and their rule type is `machine_learning`. |<> |An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to create new programmatic access keys for another IAM user. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |14 +|<> |Detects an AWS IAM user using an existing credential to create a new access key for itself and subsequently using the new key within one hour. This behavior can indicate an adversary converting compromised credentials into an additional long-term credential for persistence. Unlike a standalone self-service key creation alert, requiring subsequent use of the new key reduces noise from unused or abandoned credential-rotation operations. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 + |<> |Detects attempts to create or enable a Virtual MFA device (CreateVirtualMFADevice, EnableMFADevice) using temporary AWS credentials (access keys beginning with ASIA). Session credentials are short-lived and tied to existing authenticated sessions, so using them to register or enable MFA devices is unusual. Adversaries who compromise temporary credentials may abuse this behavior to establish persistence by attaching new MFA devices to maintain access to high-privilege accounts despite key rotation or password resets. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Tactic: Persistence], [Use Case: Identity and Access Audit], [Resources: Investigation Guide] |None |5 |<> |Identifies attempts to disable or schedule the deletion of an AWS customer managed KMS Key. Disabling or scheduling a KMS key for deletion removes the ability to decrypt data encrypted under that key and can permanently destroy access to critical resources. Adversaries may use these operations to cause irreversible data loss, disrupt business operations, impede incident response, or hide evidence of prior activity. Because KMS keys often protect sensitive or regulated data, any modification to their lifecycle should be considered highly sensitive and investigated promptly. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS KMS], [Use Case: Log Auditing], [Tactic: Impact], [Resources: Investigation Guide] |None |113 @@ -322,6 +332,8 @@ and their rule type is `machine_learning`. |<> |Identifies the deletion of an Amazon Route 53 Resolver Query Log Configuration. Resolver query logs provide critical visibility into DNS activity across VPCs, including lookups made by EC2 instances, containers, Lambda functions, and other AWS resources. Deleting a query log configuration immediately stops DNS query and response logging for the associated VPC. Adversaries may delete these configurations to evade detection, suppress forensic evidence, or degrade security monitoring capabilities. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Route 53], [Use Case: Log Auditing], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |8 +|<> |Detects a principal modifying an S3 bucket ACL to grant public read or write access that has not been observed doing so within the history window, using canned ACLs such as public-read or public-read-write. ACL-based public access is a distinct API path (PutBucketAcl) that can bypass some Block Public Access controls. Monitoring for new identities performing this change helps surface freshly compromised credentials being used to stage data for exfiltration or inadvertently expose sensitive content. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon S3], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide] |None |1 + |<> |Identifies the deletion of critical Amazon S3 bucket configurations such as bucket policies, lifecycle configurations or encryption settings. These actions are typically administrative but may also represent adversarial attempts to remove security controls, disable data retention mechanisms, or conceal evidence of malicious activity. Adversaries who gain access to AWS credentials may delete logging, lifecycle, or policy configurations to disrupt forensic visibility and inhibit recovery. For example, deleting a bucket policy can open a bucket to public access or remove protective access restrictions, while deleting lifecycle rules can prevent object archival or automatic backups. Such actions often precede data exfiltration or destructive operations and should be reviewed in context with related S3 or IAM events. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon S3], [Use Case: Asset Visibility], [Tactic: Defense Evasion], [Tactic: Impact], [Resources: Investigation Guide] |None |214 |<> |Identifies a high number of failed S3 operations against a single bucket from a single source address within a short timeframe. This activity can indicate attempts to collect bucket objects or cause an increase in billing to an account via internal "AccessDenied" errors. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Resources: Investigation Guide], [Use Case: Log Auditing], [Tactic: Impact], [Tactic: Discovery], [Tactic: Collection] |None |9 @@ -382,6 +394,8 @@ and their rule type is `machine_learning`. |<> |Identifies role chaining activity. Role chaining is when you use one assumed role to assume a second role through the AWS CLI or API. While this a recognized functionality in AWS, role chaining can be abused for privilege escalation if the subsequent assumed role provides additional privileges. Role chaining can also be used as a persistence mechanism as each AssumeRole action results in a refreshed session token with a 1 hour maximum duration. This is a new terms rule that looks for the first occurance of one role (aws.cloudtrail.user_identity.session_context.session_issuer.arn) assuming another (aws.cloudtrail.resources.arn). |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS STS], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |6 +|<> |Identifies the first time an IAM principal passes a given execution role (`roleArn`) to an Amazon SageMaker resource, via `CreateNotebookInstance`, `CreateTrainingJob`, `CreateProcessingJob`, `CreateAutoMLJob`, or `CreatePipeline`. These actions require `iam:PassRole` and attach an IAM role that the created resource then runs as. An adversary holding both SageMaker create permissions and a broad `iam:PassRole` grant can pass a more privileged role to a resource they control and execute code as that role, escalating privileges. The rule keys on the combination of the calling principal and the passed `roleArn`, so it surfaces a principal using an execution role it has not used before in the last 7 days; a role whose account differs from the caller's, or that is more privileged than the caller, is especially suspicious. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SageMaker], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 + |<> |Identifies an Amazon SageMaker notebook lifecycle configuration whose OnStart or OnCreate script, after base64 decoding, contains patterns associated with malicious activity such as reverse shells, EC2 instance metadata (IMDS) credential access, or download-and-execute commands. A lifecycle configuration runs as root on the notebook instance, so a script with these patterns is a strong indicator of an attempt to backdoor the notebook, steal the execution role's credentials, or establish persistent code execution. This rule decodes the script in the request and matches high-signal indicators; it is a higher-fidelity companion to the rule that alerts on any lifecycle configuration change. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SageMaker], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Resources: Investigation Guide] |None |1 |<> |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 @@ -452,7 +466,7 @@ and their rule type is `machine_learning`. |<> |This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same user.name 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 |3 -|<> |This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered and where the accumulated risk score is higher than a defined threshold. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |6 +|<> |This rule correlates medium-or-higher severity alerts involving the same host from at least two distinct detection rules mapped to three or more ATT&CK tactics. Analysts can use this to prioritize triage and response, as this combination may indicate host compromise. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |7 |<> |Identifies the creation of an Alternate Data Stream (ADS) at a volume root directory, which can indicate the attempt to hide tools and malware, as ADSs created in this directory are not displayed by system utilities. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |206 @@ -564,8 +578,24 @@ and their rule type is `machine_learning`. |<> |Detects an AKS (Azure Kubernetes Service) identity establishing an exec session into a pod. Interactive command execution inside a workload via kubectl exec is a common post-compromise technique used to access secrets, run tooling, and expand access from a foothold container. Node, control-plane, and kube-system service account identities are excluded, so workload service accounts and users, the identities an adversary is most likely to abuse, remain in scope. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Kubernetes], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |1 +|<> |Detects an identity creating a client-authentication CertificateSigningRequest (signer kubernetes.io/kube-apiserver-client) or approving a CSR on AKS (Azure Kubernetes Service), excluding node bootstrap and platform controllers. Adversaries submit and self-approve a CSR against the kube-apiserver-client signer to mint a long-lived client certificate for an arbitrary subject (for example a Common Name in system:masters), giving durable authenticated access that survives token revocation. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token forging a certificate is not excluded. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Kubernetes], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 + +|<> |Detects an identity creating or modifying the CoreDNS or kube-dns ConfigMap in the kube-system namespace on AKS (Azure Kubernetes Service), excluding known AKS control-plane and platform identities. Rewriting cluster DNS (by editing coredns/kube-dns or creating and editing coredns-custom) enables cluster-wide adversary-in-the-middle by redirecting internal service resolution to attacker-controlled IPs, allowing credential capture and traffic interception. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token is not excluded. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Kubernetes], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 + +|<> |Detects an identity injecting an ephemeral (debug) container into a running AKS (Azure Kubernetes Service) pod via the pods/ephemeralcontainers subresource, excluding known AKS control-plane and platform identities. Ephemeral containers share the target pod's namespaces and give stealthy interactive access to its processes and mounted secrets without creating a new pod. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token used to attach a debug container is not excluded. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Kubernetes], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + |<> |Detects use of the AKS (Azure Kubernetes Service) API server nodes/proxy subresource to reach a node's Kubelet command-execution endpoints (run, exec, attach, portforward, cri). Unlike benign monitoring that scrapes /metrics and /stats, a request to these endpoints executes commands inside a pod on the node, the core of the kubeletctl and Peirates lateral-movement technique. Even a GET to /exec is command execution because the Kubelet maps the WebSocket upgrade handshake to the RBAC get verb, so nodes/proxy GET is sufficient for remote code execution. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Kubernetes], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |1 +|<> |Detects an identity deleting Kubernetes events on AKS (Azure Kubernetes Service), excluding known AKS control-plane and platform identities. Adversaries delete events (individually or in bulk via deletecollection) to remove evidence of pod creation, exec, or scheduling activity and impair incident response after operating in the cluster. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token wiping events is not excluded. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Kubernetes], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 + +|<> |Detects a single Kubernetes identity in AKS (Azure Kubernetes Service) that is denied (HTTP 403 Forbidden) across multiple distinct API resource types within a short window. Broad authorization failures spanning many resources are a strong signal of API enumeration (reconnaissance with a stolen service account token), as an actor probes what its credentials can reach before privilege escalation. Detection is based on the breadth of denied resources rather than the raw failure count, so single-resource controller retry loops do not trigger it. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Kubernetes], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 + +|<> |Detects successful AKS (Azure Kubernetes Service) secret get or list operations where the user agent matches scripting runtimes (python, ruby, perl), command-line HTTP clients (curl, wget, HTTPie), or generic HTTP libraries (Go-http-client, okhttp, Apache-HttpClient, Guzzle, axios, undici) rather than typical kubectl or named controller traffic. Reading Kubernetes secrets with a generic client is a common credential-access step after a token or kubeconfig is stolen, and offensive tooling (for example peirates and kdigger) frequently reaches the API with a default Go HTTP client. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Kubernetes], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 + +|<> |Detects an identity minting a service account token via the AKS (Azure Kubernetes Service) TokenRequest API (serviceaccounts/token), excluding known AKS control-plane and platform identities. Adversaries request service account tokens from a compromised identity to impersonate a workload, move laterally, or escalate privileges within the cluster. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token minting a token for another service account is not excluded. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Kubernetes], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 + +|<> |Detects AKS (Azure Kubernetes Service) service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC before privilege escalation. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: Azure], [Data Source: Azure Platform Logs], [Data Source: Kubernetes], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 + |<> |Detects when a service principal or user performs an Azure Arc cluster credential listing operation from a source IP not previously associated with that identity. The `listClusterUserCredential` action retrieves credentials for the Arc Cluster Connect proxy, enabling kubectl access through the Azure ARM API. An adversary using stolen service principal credentials will typically call this operation from infrastructure not previously seen for that SP. By tracking the combination of caller identity and source IP, this rule avoids false positives from backend services and CI/CD pipelines that rotate IPs but maintain consistent identity-to-IP patterns over time. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure Arc], [Data Source: Azure Activity Logs], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |3 |<> |Identifies when an Azure Automation account is created. Azure Automation accounts can be used to automate management tasks and orchestrate actions across systems. An adversary may create an Automation account in order to maintain persistence in their target's environment. |[Domain: Cloud], [Data Source: Azure], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |107 @@ -688,6 +718,8 @@ and their rule type is `machine_learning`. |<> |Identifies User Account Control (UAC) bypass via eventvwr.exe. Attackers bypass UAC to stealthily execute code with elevated permissions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR], [Data Source: Windows Security Event Logs], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |323 +|<> |Identifies Cassandra Query Language statements that create a JavaScript user-defined function. On vulnerable and dangerously configured Cassandra servers, adversaries can abuse scripted UDF creation to escape the JavaScript sandbox and execute operating-system commands, including through CVE-2021-44521. |[Domain: Network], [Use Case: Network Security Monitoring], [Use Case: Threat Detection], [Use Case: Vulnerability], [Tactic: Execution], [Data Source: Network Packet Capture], [Resources: Investigation Guide] |None |1 + |<> |Detects the use of the chkconfig binary to manually add a service for management by chkconfig. Threat actors may utilize this technique to maintain persistence on a system. When a new service is added, chkconfig ensures that the service has either a start or a kill entry in every runlevel and when the system is rebooted the service file added will run providing long-term persistence. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Threat: Lightning Framework], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |219 |<> |Detects chroot execution on Linux when the process appears to run in a container-oriented context: the process title matches runc init, the entry leader is a container workload, or the parent process is runc. Chroot from inside a container can pivot to an alternate root filesystem and is a common step in container breakout attempts when combined with sensitive host mounts. |[Data Source: Auditd Manager], [Data Source: Elastic Defend], [Domain: Container], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |2 @@ -716,7 +748,7 @@ and their rule type is `machine_learning`. |<> |Identifies PowerShell, PowerShell ISE, or Cmd execution spawned from Windows Script Host or MSHTA. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Elastic Endgame], [Data Source: Crowdstrike] |None |211 -|<> |Identifies Component Object Model (COM) hijacking via registry modification. Adversaries may establish persistence by executing malicious content triggered by hijacked references to COM objects. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Tactic: Privilege Escalation], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |120 +|<> |Identifies Component Object Model (COM) hijacking via registry modification. Adversaries may establish persistence by executing malicious content triggered by hijacked references to COM objects. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Tactic: Privilege Escalation], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |121 |<> |Identifies the image load of a compression DLL. Adversaries will often compress and encrypt data in preparation for exfiltration. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Data Source: Elastic Defend], [Rule Type: BBR] |None |6 @@ -726,7 +758,7 @@ and their rule type is `machine_learning`. |<> |Identifies unusual processes connecting to domains using known free SSL certificates. Adversaries may employ a known encryption algorithm to conceal command and control traffic. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |211 -|<> |Adversaries may implement command and control (C2) communications that use common web services to hide their activity. This attack technique is typically targeted at an organization and uses web services common to the victim network, which allows the adversary to blend into legitimate traffic activity. These popular services are typically targeted since they have most likely been used before compromise, which helps malicious traffic blend in. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: SentinelOne] |None |131 +|<> |Adversaries may implement command and control (C2) communications that use common web services to hide their activity. This attack technique is typically targeted at an organization and uses web services common to the victim network, which allows the adversary to blend into legitimate traffic activity. These popular services are typically targeted since they have most likely been used before compromise, which helps malicious traffic blend in. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: SentinelOne] |None |132 |<> |Telnet provides a command line interface for communication with a remote device or server. This rule identifies Telnet network connections to publicly routable IP addresses. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |213 @@ -738,7 +770,7 @@ and their rule type is `machine_learning`. |<> |Identifies unusual instances of Control Panel with suspicious keywords or paths in the process command line value. Adversaries may abuse control.exe to proxy execution of malicious code. |[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 |319 -|<> |This rule correlates alerts from multiple integrations and event categories that involve different user.name values which may represent the same real-world identity. It uses an LLM-based similarity analysis to evaluate whether multiple user identifiers (e.g. naming variations, formats, aliases, or domain differences) likely belong to the same person. |[Domain: Identity], [Domain: LLM], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Rule Type: Higher-Order Rule] |None |3 +|<> |This rule correlates alerts from multiple integrations and event categories that involve different user.name values which may represent the same real-world identity. It uses an LLM-based similarity analysis to evaluate whether multiple user identifiers (e.g. naming variations, formats, aliases, or domain differences) likely belong to the same person. |[Domain: Identity], [Domain: LLM], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Resources: LLM], [Rule Type: Higher-Order Rule] |None |4 |<