From ee300b15c6bee633c3b20cc7ce0767c6f8fbddf4 Mon Sep 17 00:00:00 2001
From: tradebot-elastic <178941316+tradebot-elastic@users.noreply.github.com>
Date: Tue, 19 May 2026 14:48:19 +0000
Subject: [PATCH] Update latest docs

---
 ...le-8-19-24-adminsdholder-backdoor.asciidoc | 150 ++++++++++
 ...insdholder-sdprop-exclusion-added.asciidoc | 164 ++++++++++
 ...ntry-granted-cluster-admin-policy.asciidoc | 128 ++++++++
 ...-24-aws-eks-access-entry-modified.asciidoc | 123 ++++++++
 ...ks-control-plane-logging-disabled.asciidoc | 102 +++++++
 ...n-manager-child-process-execution.asciidoc | 141 +++++++++
 ...19-24-bypass-uac-via-event-viewer.asciidoc | 194 ++++++++++++
 ...strike-command-and-control-beacon.asciidoc | 134 +++++++++
 ...g-interpreter-via-windows-scripts.asciidoc | 211 +++++++++++++
 ...wned-by-suspicious-parent-process.asciidoc | 181 +++++++++++
 ...ecution-with-suspicious-arguments.asciidoc | 140 +++++++++
 ...on-of-a-hidden-local-user-account.asciidoc | 181 +++++++++++
 ...-execution-from-container-context.asciidoc | 148 +++++++++
 ...t-modification-by-an-unusual-user.asciidoc | 145 +++++++++
 ...count-creation-by-an-unusual-user.asciidoc | 156 ++++++++++
 ...ookup-service-via-unsigned-binary.asciidoc | 120 ++++++++
 ...entication-configuration-modified.asciidoc | 120 ++++++++
 ...roker-sign-in-to-unusual-resource.asciidoc | 133 +++++++++
 ...uth-device-code-phishing-via-aitm.asciidoc | 133 +++++++++
 ...-sign-in-via-officehome-tycoon2fa.asciidoc | 121 ++++++++
 ...-unusual-user-agent-azure-ad-join.asciidoc | 106 +++++++
 ...n-or-modified-by-microsoft-office.asciidoc | 176 +++++++++++
 ...execution-via-tsclient-mountpoint.asciidoc | 164 ++++++++++
 ...able-directory-by-unusual-process.asciidoc | 171 +++++++++++
 ...ync-plugin-registered-and-enabled.asciidoc | 150 ++++++++++
 ...ime-fortigate-administrator-login.asciidoc | 145 +++++++++
 ...-private-repository-turned-public.asciidoc | 116 +++++++
 ...n-after-oauth-from-suspicious-asn.asciidoc | 133 +++++++++
 ...licy-abuse-for-privilege-addition.asciidoc | 154 ++++++++++
 ...to-an-unsecure-elasticsearch-node.asciidoc | 126 ++++++++
 ...g-dcom-lateral-movement-via-mshta.asciidoc | 194 ++++++++++++
 ...ng-dcom-lateral-movement-with-mmc.asciidoc | 186 ++++++++++++
 ...ctive-logon-by-an-unusual-process.asciidoc | 156 ++++++++++
 ...-19-24-krbtgt-delegation-backdoor.asciidoc | 147 +++++++++
 ...connection-attempt-to-internal-ip.asciidoc | 172 +++++++++++
 ...ssion-webhook-created-or-modified.asciidoc | 141 +++++++++
 ...path-access-via-process-arguments.asciidoc | 176 +++++++++++
 ...impersonating-privileged-identity.asciidoc | 111 +++++++
 ...erver-proxying-request-to-kubelet.asciidoc | 148 +++++++++
 ...gning-request-created-or-approved.asciidoc | 146 +++++++++
 ...r-kube-dns-configuration-modified.asciidoc | 110 +++++++
 ...-ephemeral-container-added-to-pod.asciidoc | 112 +++++++
 ...bernetes-multi-resource-discovery.asciidoc | 121 ++++++++
 ...ec-cloud-instance-metadata-access.asciidoc | 139 +++++++++
 ...-pod-exec-potential-reverse-shell.asciidoc | 121 ++++++++
 ...ve-file-or-credential-path-access.asciidoc | 149 +++++++++
 ...d-exec-with-curl-or-wget-to-https.asciidoc | 125 ++++++++
 ...activity-against-multiple-objects.asciidoc | 114 +++++++
 ...-from-node-or-pod-service-account.asciidoc | 124 ++++++++
 ...s-cluster-or-sensitive-namespaces.asciidoc | 109 +++++++
 ...oken-created-via-tokenrequest-api.asciidoc | 132 ++++++++
 ...s-static-pod-manifest-file-access.asciidoc | 152 ++++++++++
 ...teral-movement-via-startup-folder.asciidoc | 180 +++++++++++
 ...4-lsass-memory-dump-handle-access.asciidoc | 170 +++++++++++
 ...ss-process-access-via-windows-api.asciidoc | 209 +++++++++++++
 ...entity-login-from-atypical-region.asciidoc | 136 +++++++++
 ...n-from-impossible-travel-location.asciidoc | 131 ++++++++
 ...loggedin-via-office-app-tycoon2fa.asciidoc | 119 ++++++++
 ...ker-spawning-suspicious-processes.asciidoc | 190 ++++++++++++
 ...lti-category-reconnaissance-burst.asciidoc | 213 +++++++++++++
 ...mimikatz-memssp-log-file-detected.asciidoc | 177 +++++++++++
 ...tence-via-hidden-run-key-detected.asciidoc | 195 ++++++++++++
 ...tence-via-microsoft-office-addins.asciidoc | 177 +++++++++++
 ...ycontroller-scheduled-task-hijack.asciidoc | 200 +++++++++++++
 ...pdate-orchestrator-service-hijack.asciidoc | 211 +++++++++++++
 ...ia-wmi-standard-registry-provider.asciidoc | 222 ++++++++++++++
 ...-dga-command-and-control-behavior.asciidoc |  88 ++++++
 ...otential-command-shell-via-netcat.asciidoc | 156 ++++++++++
 ...hentication-bypass-cve-2026-41940.asciidoc | 186 ++++++++++++
 ...ntial-cve-2025-33053-exploitation.asciidoc | 197 ++++++++++++
 ...elet-access-via-process-arguments.asciidoc | 147 +++++++++
 ...alation-via-vulnerable-msi-repair.asciidoc | 170 +++++++++++
 ...ution-via-filefix-phishing-attack.asciidoc | 206 +++++++++++++
 ...tial-fake-captcha-phishing-attack.asciidoc | 212 +++++++++++++
 ...24-potential-foxmail-exploitation.asciidoc | 179 +++++++++++
 ...24-potential-kubeletctl-execution.asciidoc | 132 ++++++++
 ...al-macos-ssh-brute-force-detected.asciidoc | 158 ++++++++++
 ...rshell-based-on-alert-correlation.asciidoc | 155 ++++++++++
 ...ication-of-accessibility-binaries.asciidoc | 204 +++++++++++++
 ...notepad-markdown-rce-exploitation.asciidoc | 179 +++++++++++
 ...ershell-hacktool-script-by-author.asciidoc | 185 ++++++++++++
 ...lation-in-container-via-runc-init.asciidoc | 136 +++++++++
 ...ege-escalation-via-cve-2022-38028.asciidoc | 184 ++++++++++++
 ...alation-via-installerfiletakeover.asciidoc | 163 ++++++++++
 ...rivilege-escalation-via-suid-sgid.asciidoc | 114 +++++++
 ...lation-via-unshare-and-uid-change.asciidoc | 154 ++++++++++
 ...-unshare-followed-by-root-process.asciidoc | 146 +++++++++
 ...ation-via-samaccountname-spoofing.asciidoc | 170 +++++++++++
 ...somware-note-file-dropped-via-smb.asciidoc | 165 ++++++++++
 ...remote-desktop-shadowing-activity.asciidoc | 199 ++++++++++++
 ...-potential-reverse-shell-via-java.asciidoc | 189 ++++++++++++
 ...19-24-potential-sharprdp-behavior.asciidoc | 173 +++++++++++
 ...m-tampering-via-file-modification.asciidoc | 175 +++++++++++
 ...19-24-powershell-psreflect-script.asciidoc | 164 ++++++++++
 ...tion-via-named-pipe-impersonation.asciidoc | 178 +++++++++++
 ...ia-rogue-named-pipe-impersonation.asciidoc | 145 +++++++++
 ...n-via-windir-environment-variable.asciidoc | 179 +++++++++++
 ...n-via-parent-process-pid-spoofing.asciidoc | 200 +++++++++++++
 ...ss-created-with-an-elevated-token.asciidoc | 206 +++++++++++++
 ...mputer-account-dnshostname-update.asciidoc | 158 ++++++++++
 ...ver-spawning-suspicious-processes.asciidoc | 198 ++++++++++++
 ...19-24-sensitive-files-compression.asciidoc | 231 ++++++++++++++
 ...via-local-kerberos-authentication.asciidoc | 161 ++++++++++
 ...-suspicious-cmd-execution-via-wmi.asciidoc | 188 ++++++++++++
 ...ous-execution-from-a-webdav-share.asciidoc | 202 +++++++++++++
 ...picious-execution-from-inet-cache.asciidoc | 212 +++++++++++++
 ...-suspicious-execution-with-nodejs.asciidoc | 193 ++++++++++++
 ...4-suspicious-file-renamed-via-smb.asciidoc | 161 ++++++++++
 ...icious-imagepath-service-creation.asciidoc | 175 +++++++++++
 ...ous-javascript-execution-via-deno.asciidoc | 188 ++++++++++++
 ...ros-authentication-ticket-request.asciidoc | 206 +++++++++++++
 ...ous-macos-ms-office-child-process.asciidoc | 259 ++++++++++++++++
 ...suspicious-module-loaded-by-lsass.asciidoc | 229 ++++++++++++++
 ...print-spooler-point-and-print-dll.asciidoc | 174 +++++++++++
 ...increasebasepriorityprivilege-use.asciidoc | 147 +++++++++
 ...java-module-load-or-child-process.asciidoc | 180 +++++++++++
 ...startup-shell-folder-modification.asciidoc | 200 +++++++++++++
 ...-binary-execution-auditd-sequence.asciidoc | 129 ++++++++
 ...-suspicious-suid-binary-execution.asciidoc | 122 ++++++++
 ...s-windows-command-shell-arguments.asciidoc | 261 ++++++++++++++++
 ...public-ip-discovery-via-dns-query.asciidoc | 235 +++++++++++++++
 ...ia-windows-directory-masquerading.asciidoc | 194 ++++++++++++
 ...ademanager-elevated-com-interface.asciidoc | 187 ++++++++++++
 ...icmluautil-elevated-com-interface.asciidoc | 189 ++++++++++++
 ...e-8-19-24-untrusted-driver-loaded.asciidoc | 164 ++++++++++
 ...-unusual-child-process-of-dns-exe.asciidoc | 185 ++++++++++++
 ...via-microsoft-common-console-file.asciidoc | 213 +++++++++++++
 ...-24-user-added-to-the-admin-group.asciidoc | 125 ++++++++
 ...y-deleted-or-resized-via-vssadmin.asciidoc | 162 ++++++++++
 ...adow-copy-deletion-via-powershell.asciidoc | 186 ++++++++++++
 ...ume-shadow-copy-deletion-via-wmic.asciidoc | 167 +++++++++++
 ...ess-child-of-common-web-processes.asciidoc | 238 +++++++++++++++
 ...ice-spawning-suspicious-processes.asciidoc | 192 ++++++++++++
 ...e-installed-via-an-unusual-client.asciidoc | 168 +++++++++++
 ...ffice-exploitation-via-dll-hijack.asciidoc | 182 +++++++++++
 .../prebuilt-rules-8-19-24-appendix.asciidoc  | 141 +++++++++
 .../prebuilt-rules-8-19-24-summary.asciidoc   | 282 ++++++++++++++++++
 ...ebuilt-rules-downloadable-updates.asciidoc |   5 +
 .../prebuilt-rules-reference.asciidoc         | 256 +++++++++-------
 .../prebuilt-rules/rule-desc-index.asciidoc   |  29 +-
 .../adminsdholder-backdoor.asciidoc           |  76 +++--
 ...insdholder-sdprop-exclusion-added.asciidoc |  71 +++--
 ...ntry-granted-cluster-admin-policy.asciidoc | 128 ++++++++
 .../aws-eks-access-entry-modified.asciidoc    | 123 ++++++++
 ...ks-control-plane-logging-disabled.asciidoc | 102 +++++++
 ...n-manager-child-process-execution.asciidoc |   9 +-
 .../bypass-uac-via-event-viewer.asciidoc      | 102 ++++---
 ...strike-command-and-control-beacon.asciidoc |   4 +-
 ...g-interpreter-via-windows-scripts.asciidoc |  87 ++++--
 ...wned-by-suspicious-parent-process.asciidoc |  95 +++---
 ...ecution-with-suspicious-arguments.asciidoc | 140 +++++++++
 ...on-of-a-hidden-local-user-account.asciidoc |  75 ++++-
 ...-execution-from-container-context.asciidoc |   5 +-
 ...t-modification-by-an-unusual-user.asciidoc |  61 +++-
 ...count-creation-by-an-unusual-user.asciidoc |  59 +++-
 ...ookup-service-via-unsigned-binary.asciidoc |   4 +-
 ...entication-configuration-modified.asciidoc | 120 ++++++++
 ...roker-sign-in-to-unusual-resource.asciidoc | 133 +++++++++
 ...uth-device-code-phishing-via-aitm.asciidoc | 133 +++++++++
 ...-sign-in-via-officehome-tycoon2fa.asciidoc | 121 ++++++++
 ...-unusual-user-agent-azure-ad-join.asciidoc | 106 +++++++
 ...n-or-modified-by-microsoft-office.asciidoc |  98 +++---
 ...execution-via-tsclient-mountpoint.asciidoc |  80 +++--
 ...able-directory-by-unusual-process.asciidoc |  20 +-
 ...ync-plugin-registered-and-enabled.asciidoc |   4 +-
 ...ime-fortigate-administrator-login.asciidoc |  18 +-
 ...-private-repository-turned-public.asciidoc |   4 +-
 ...n-after-oauth-from-suspicious-asn.asciidoc | 133 +++++++++
 ...licy-abuse-for-privilege-addition.asciidoc |  66 ++--
 ...to-an-unsecure-elasticsearch-node.asciidoc |   4 +-
 ...g-dcom-lateral-movement-via-mshta.asciidoc |  94 ++++--
 ...ng-dcom-lateral-movement-with-mmc.asciidoc |  87 ++++--
 ...ctive-logon-by-an-unusual-process.asciidoc |  63 ++--
 .../krbtgt-delegation-backdoor.asciidoc       |  74 ++---
 ...ssion-webhook-created-or-modified.asciidoc | 141 +++++++++
 ...path-access-via-process-arguments.asciidoc | 176 +++++++++++
 ...impersonating-privileged-identity.asciidoc | 111 +++++++
 ...erver-proxying-request-to-kubelet.asciidoc | 148 +++++++++
 ...gning-request-created-or-approved.asciidoc | 146 +++++++++
 ...r-kube-dns-configuration-modified.asciidoc | 110 +++++++
 ...-ephemeral-container-added-to-pod.asciidoc | 112 +++++++
 ...bernetes-multi-resource-discovery.asciidoc |   9 +-
 ...activity-against-multiple-objects.asciidoc |   9 +-
 ...-from-node-or-pod-service-account.asciidoc |  15 +-
 ...s-cluster-or-sensitive-namespaces.asciidoc |   5 +-
 ...oken-created-via-tokenrequest-api.asciidoc | 132 ++++++++
 ...s-static-pod-manifest-file-access.asciidoc | 152 ++++++++++
 ...teral-movement-via-startup-folder.asciidoc |  76 +++--
 .../lsass-memory-dump-handle-access.asciidoc  |  11 +-
 ...ss-process-access-via-windows-api.asciidoc |   6 +-
 ...entity-login-from-atypical-region.asciidoc | 136 +++++++++
 ...n-from-impossible-travel-location.asciidoc |   9 +-
 ...loggedin-via-office-app-tycoon2fa.asciidoc | 119 ++++++++
 ...ker-spawning-suspicious-processes.asciidoc |  85 ++++--
 ...lti-category-reconnaissance-burst.asciidoc | 213 +++++++++++++
 ...mimikatz-memssp-log-file-detected.asciidoc |   6 +-
 ...tence-via-hidden-run-key-detected.asciidoc |  93 ++++--
 ...tence-via-microsoft-office-addins.asciidoc |  90 ++++--
 ...ycontroller-scheduled-task-hijack.asciidoc |  93 ++++--
 ...pdate-orchestrator-service-hijack.asciidoc | 109 ++++---
 ...ia-wmi-standard-registry-provider.asciidoc | 108 +++----
 ...-dga-command-and-control-behavior.asciidoc |   4 +-
 ...otential-command-shell-via-netcat.asciidoc |  70 +++--
 ...hentication-bypass-cve-2026-41940.asciidoc | 186 ++++++++++++
 ...ntial-cve-2025-33053-exploitation.asciidoc |  75 ++++-
 ...alation-via-vulnerable-msi-repair.asciidoc |  82 +++--
 ...ution-via-filefix-phishing-attack.asciidoc |  78 +++--
 ...tial-fake-captcha-phishing-attack.asciidoc |  88 ++++--
 .../potential-foxmail-exploitation.asciidoc   |  98 ++++--
 ...al-macos-ssh-brute-force-detected.asciidoc |  44 +--
 ...rshell-based-on-alert-correlation.asciidoc | 101 +++----
 ...ication-of-accessibility-binaries.asciidoc | 102 ++++---
 ...notepad-markdown-rce-exploitation.asciidoc |  93 ++++--
 ...ershell-hacktool-script-by-author.asciidoc | 103 +++----
 ...ege-escalation-via-cve-2022-38028.asciidoc |  82 +++--
 ...alation-via-installerfiletakeover.asciidoc |  83 ++----
 ...rivilege-escalation-via-suid-sgid.asciidoc | 114 +++++++
 ...lation-via-unshare-and-uid-change.asciidoc | 154 ++++++++++
 ...-unshare-followed-by-root-process.asciidoc | 146 +++++++++
 ...ation-via-samaccountname-spoofing.asciidoc |  72 +++--
 ...somware-note-file-dropped-via-smb.asciidoc |  70 +++--
 ...remote-desktop-shadowing-activity.asciidoc |  91 ++++--
 .../potential-reverse-shell-via-java.asciidoc |   4 +-
 .../potential-sharprdp-behavior.asciidoc      |  69 +++--
 ...m-tampering-via-file-modification.asciidoc |  88 ++++--
 .../powershell-psreflect-script.asciidoc      | 102 +++----
 ...tion-via-named-pipe-impersonation.asciidoc | 108 ++++---
 ...ia-rogue-named-pipe-impersonation.asciidoc |  64 ++--
 ...n-via-windir-environment-variable.asciidoc |  88 ++++--
 ...n-via-parent-process-pid-spoofing.asciidoc |  77 +++--
 ...ss-created-with-an-elevated-token.asciidoc |  74 +++--
 ...mputer-account-dnshostname-update.asciidoc |  78 +++--
 ...ver-spawning-suspicious-processes.asciidoc |  93 ++++--
 .../sensitive-files-compression.asciidoc      |   8 +-
 ...via-local-kerberos-authentication.asciidoc |  67 +++--
 .../suspicious-cmd-execution-via-wmi.asciidoc |  87 ++++--
 ...ous-execution-from-a-webdav-share.asciidoc |  85 +++++-
 ...picious-execution-from-inet-cache.asciidoc |  90 ++++--
 .../suspicious-execution-with-nodejs.asciidoc |  95 ++++--
 .../suspicious-file-renamed-via-smb.asciidoc  |  69 +++--
 ...icious-imagepath-service-creation.asciidoc |  88 ++++--
 ...ous-javascript-execution-via-deno.asciidoc |  73 ++++-
 ...ros-authentication-ticket-request.asciidoc | 114 +++++--
 ...ous-macos-ms-office-child-process.asciidoc |  11 +-
 ...suspicious-module-loaded-by-lsass.asciidoc | 161 +++++-----
 ...print-spooler-point-and-print-dll.asciidoc |  78 +++--
 ...increasebasepriorityprivilege-use.asciidoc |  69 +++--
 ...java-module-load-or-child-process.asciidoc |  82 +++--
 ...startup-shell-folder-modification.asciidoc |  94 +++---
 ...-binary-execution-auditd-sequence.asciidoc | 129 ++++++++
 .../suspicious-suid-binary-execution.asciidoc |  41 ++-
 ...s-windows-command-shell-arguments.asciidoc |  80 +++--
 ...public-ip-discovery-via-dns-query.asciidoc |  96 ++++--
 ...ia-windows-directory-masquerading.asciidoc | 111 ++++---
 ...ademanager-elevated-com-interface.asciidoc |  86 ++++--
 ...icmluautil-elevated-com-interface.asciidoc |  96 ++++--
 .../untrusted-driver-loaded.asciidoc          | 110 ++++---
 .../unusual-child-process-of-dns-exe.asciidoc |  88 ++++--
 ...via-microsoft-common-console-file.asciidoc |  84 ++++--
 .../user-added-to-the-admin-group.asciidoc    |   8 +-
 ...y-deleted-or-resized-via-vssadmin.asciidoc |  95 +++---
 ...adow-copy-deletion-via-powershell.asciidoc |  96 +++---
 ...ume-shadow-copy-deletion-via-wmic.asciidoc |  93 +++---
 ...ess-child-of-common-web-processes.asciidoc |  99 +++---
 ...ice-spawning-suspicious-processes.asciidoc |  69 +++--
 ...e-installed-via-an-unusual-client.asciidoc |  89 +++---
 ...ffice-exploitation-via-dll-hijack.asciidoc |  80 +++--
 docs/index.asciidoc                           |   2 +
 268 files changed, 31125 insertions(+), 2447 deletions(-)
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-adminsdholder-backdoor.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-adminsdholder-sdprop-exclusion-added.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-aws-eks-access-entry-granted-cluster-admin-policy.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-aws-eks-access-entry-modified.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-aws-eks-control-plane-logging-disabled.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-aws-ssm-session-manager-child-process-execution.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-bypass-uac-via-event-viewer.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-cobalt-strike-command-and-control-beacon.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-command-and-scripting-interpreter-via-windows-scripts.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-conhost-spawned-by-suspicious-parent-process.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-container-runtime-cli-execution-with-suspicious-arguments.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-creation-of-a-hidden-local-user-account.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-curl-or-wget-execution-from-container-context.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-dmsa-account-creation-by-an-unusual-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-dns-request-for-ip-lookup-service-via-unsigned-binary.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-eks-authentication-configuration-modified.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-entra-id-oauth-device-code-phishing-via-aitm.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-entra-id-register-device-with-unusual-user-agent-azure-ad-join.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-execution-of-file-written-or-modified-by-microsoft-office.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-execution-via-tsclient-mountpoint.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-file-creation-in-world-writable-directory-by-unusual-process.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-finder-sync-plugin-registered-and-enabled.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-first-time-fortigate-administrator-login.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-github-private-repository-turned-public.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-google-workspace-device-registration-after-oauth-from-suspicious-asn.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-group-policy-abuse-for-privilege-addition.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-incoming-dcom-lateral-movement-via-mshta.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-incoming-dcom-lateral-movement-with-mmc.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-interactive-logon-by-an-unusual-process.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-krbtgt-delegation-backdoor.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubelet-api-connection-attempt-to-internal-ip.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-admission-webhook-created-or-modified.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-api-request-impersonating-privileged-identity.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-api-server-proxying-request-to-kubelet.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-client-certificate-signing-request-created-or-approved.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-coredns-or-kube-dns-configuration-modified.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-ephemeral-container-added-to-pod.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-multi-resource-discovery.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-pod-exec-cloud-instance-metadata-access.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-pod-exec-potential-reverse-shell.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-pod-exec-sensitive-file-or-credential-path-access.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-pod-exec-with-curl-or-wget-to-https.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-rapid-secret-get-activity-against-multiple-objects.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-secret-get-or-list-from-node-or-pod-service-account.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-secrets-list-across-cluster-or-sensitive-namespaces.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-static-pod-manifest-file-access.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-lateral-movement-via-startup-folder.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-lsass-memory-dump-handle-access.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-lsass-process-access-via-windows-api.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-m365-identity-login-from-atypical-region.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-m365-identity-login-from-impossible-travel-location.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-m365-potential-aitm-userloggedin-via-office-app-tycoon2fa.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-microsoft-exchange-worker-spawning-suspicious-processes.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-microsoft-graph-multi-category-reconnaissance-burst.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-mimikatz-memssp-log-file-detected.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-hidden-run-key-detected.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-microsoft-office-addins.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-update-orchestrator-service-hijack.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-wmi-standard-registry-provider.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-possible-fin7-dga-command-and-control-behavior.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-command-shell-via-netcat.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-cve-2025-33053-exploitation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-direct-kubelet-access-via-process-arguments.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-escalation-via-vulnerable-msi-repair.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-execution-via-filefix-phishing-attack.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-fake-captcha-phishing-attack.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-foxmail-exploitation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-kubeletctl-execution.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-macos-ssh-brute-force-detected.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-malicious-powershell-based-on-alert-correlation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-modification-of-accessibility-binaries.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-notepad-markdown-rce-exploitation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-powershell-hacktool-script-by-author.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-in-container-via-runc-init.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-cve-2022-38028.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-installerfiletakeover.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-suid-sgid.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-unshare-and-uid-change.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-unshare-followed-by-root-process.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-ransomware-note-file-dropped-via-smb.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-remote-desktop-shadowing-activity.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-reverse-shell-via-java.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-sharprdp-behavior.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-system-tampering-via-file-modification.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-powershell-psreflect-script.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-privilege-escalation-via-named-pipe-impersonation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-privilege-escalation-via-windir-environment-variable.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-privileges-elevation-via-parent-process-pid-spoofing.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-process-created-with-an-elevated-token.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-remote-computer-account-dnshostname-update.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-screenconnect-server-spawning-suspicious-processes.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-sensitive-files-compression.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-service-creation-via-local-kerberos-authentication.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-cmd-execution-via-wmi.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-execution-from-a-webdav-share.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-execution-from-inet-cache.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-execution-with-nodejs.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-file-renamed-via-smb.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-imagepath-service-creation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-javascript-execution-via-deno.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-kerberos-authentication-ticket-request.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-macos-ms-office-child-process.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-module-loaded-by-lsass.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-print-spooler-point-and-print-dll.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-seincreasebasepriorityprivilege-use.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-startup-shell-folder-modification.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-suid-binary-execution-auditd-sequence.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-suid-binary-execution.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-windows-command-shell-arguments.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-system-public-ip-discovery-via-dns-query.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-uac-bypass-attempt-via-windows-directory-masquerading.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-uac-bypass-via-icmluautil-elevated-com-interface.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-untrusted-driver-loaded.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-unusual-child-process-of-dns-exe.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-unusual-execution-via-microsoft-common-console-file.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-user-added-to-the-admin-group.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-volume-shadow-copy-deletion-via-powershell.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-volume-shadow-copy-deletion-via-wmic.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-web-shell-detection-script-process-child-of-common-web-processes.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-windows-server-update-service-spawning-suspicious-processes.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-windows-service-installed-via-an-unusual-client.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-wps-office-exploitation-via-dll-hijack.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rules-8-19-24-appendix.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rules-8-19-24-summary.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-eks-access-entry-granted-cluster-admin-policy.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-eks-access-entry-modified.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-eks-control-plane-logging-disabled.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/container-runtime-cli-execution-with-suspicious-arguments.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/eks-authentication-configuration-modified.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/entra-id-oauth-device-code-phishing-via-aitm.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/entra-id-register-device-with-unusual-user-agent-azure-ad-join.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/google-workspace-device-registration-after-oauth-from-suspicious-asn.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/kubernetes-admission-webhook-created-or-modified.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/kubernetes-api-request-impersonating-privileged-identity.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/kubernetes-api-server-proxying-request-to-kubelet.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/kubernetes-client-certificate-signing-request-created-or-approved.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/kubernetes-coredns-or-kube-dns-configuration-modified.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/kubernetes-ephemeral-container-added-to-pod.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/kubernetes-static-pod-manifest-file-access.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/m365-identity-login-from-atypical-region.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/m365-potential-aitm-userloggedin-via-office-app-tycoon2fa.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/microsoft-graph-multi-category-reconnaissance-burst.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-suid-sgid.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-unshare-and-uid-change.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-unshare-followed-by-root-process.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/suspicious-suid-binary-execution-auditd-sequence.asciidoc

diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-adminsdholder-backdoor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-adminsdholder-backdoor.asciidoc
new file mode 100644
index 0000000000..ed5dadcef0
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-adminsdholder-backdoor.asciidoc
@@ -0,0 +1,150 @@
+[[prebuilt-rule-8-19-24-adminsdholder-backdoor]]
+=== AdminSDHolder Backdoor
+
+Detects modifications in the AdminSDHolder object. Attackers can abuse the SDProp process to implement a persistent backdoor in Active Directory. SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, regaining their Administrative Privileges.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-system.security*
+* logs-windows.forwarded*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://adsecurity.org/?p=1906
+* https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Use Case: Active Directory Monitoring
+* Data Source: Active Directory
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 216
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating AdminSDHolder Backdoor*
+
+
+
+*Possible investigation steps*
+
+
+- What AdminSDHolder change did the alert preserve?
+  - Focus: confirm `winlog.event_data.ObjectDN` under AdminSDHolder, then read `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.OperationType`, `winlog.event_data.AttributeValue`, and `winlog.event_data.AttributeSyntaxOID`.
+  - Implication: escalate on "nTSecurityDescriptor", ownership data, or any value that can alter control of protected objects; lower concern only for non-security metadata tied to a recognized tier-0 maintenance workflow.
+
+- What did the correlated 5136 operation contain?
+  - Why: one alert document may show only part of a logical directory change; `winlog.event_data.OpCorrelationID` reconstructs the rest of the operation.
+  - Focus: review same-controller `5136` events for the same `host.id`, `winlog.computer_name`, and `winlog.event_data.OpCorrelationID`; compare attribute, value, and operation type. !{investigate{"description":"","label":"All 5136 events in this AdminSDHolder change set","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.OpCorrelationID","queryType":"phrase","value":"{{winlog.event_data.OpCorrelationID}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Implication: escalate when the operation adds multiple ACL changes, touches unrelated sensitive attributes, or suggests a staged AdminSDHolder template rewrite; lower concern only when bounded to one expected non-security update on the same object.
+
+- Does the recovered value grant or preserve access that SDProp can stamp onto protected identities?
+  - Why: AdminSDHolder is the ACL template for protected accounts and groups, so a small template edit can become persistent privileged access after SDProp runs.
+  - Focus: interpret attribute name, value, and syntax for a new trustee, ACE, owner reference, or delegated right rather than non-security metadata.
+  - Implication: escalate when the value adds a SID, DN, ACE, owner path, Full Control, Modify, WriteDacl, WriteOwner, or GenericAll outside the expected tier-0 admin set; truncated or opaque values keep permission impact unresolved and require preserving raw change data.
+
+- Who initiated the modification, and where did the session originate?
+  - Focus: identify the writer and controller with `user.id`, `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectLogonId`, and `winlog.computer_name`.
+  - Hint: on the same `winlog.computer_name`, match `5136` `winlog.event_data.SubjectLogonId` to `4624` `winlog.event_data.TargetLogonId`; search `4648` for the same `winlog.event_data.SubjectLogonId` when explicit credentials matter, then read `source.ip` and `winlog.event_data.AuthenticationPackageName`. Missing linked authentication records or `source.ip` leaves origin unresolved, not benign.
+    - !{investigate{"description":"","label":"Linked logon for the modifying session","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Explicit credential events for the modifying session","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Implication: escalate when the writer is unexpected, source or auth method does not fit tier-0 administration, or origin remains unresolved with a security-relevant change; do not wait on auth pivots when the attribute/value and change set already prove unauthorized rights.
+
+- Did the template change propagate or get forced onto protected objects?
+  - Why: SDProp can apply the AdminSDHolder template to protected accounts and groups, so impact may appear after the initial directory-change event.
+  - Focus: on the same `winlog.event_data.DSName` or `winlog.computer_name`, review later `5136` events for object, attribute, writer, and time on protected users or groups.
+  - Hint: if the logging controller has no follow-on records, search the same `winlog.event_data.DSName` across domain controllers; absence on one controller does not clear propagation. !{investigate{"description":"","label":"Later 5136 changes in the same directory service","providers":[[{"excluded":false,"field":"winlog.event_data.DSName","queryType":"phrase","value":"{{winlog.event_data.DSName}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}}
+  - Implication: escalate when later events show security-descriptor, owner, or trustee changes on protected identities after the AdminSDHolder edit; no follow-on `5136` visibility leaves propagation unresolved, not benign.
+
+- Escalate when object, security-relevant attribute/value, `winlog.event_data.OpCorrelationID`, writer/session origin, or propagation evidence shows unauthorized control; close only when the exact change, bounded `5136` set, actor/session origin, and available change or baseline record all point to one recognized tier-0 workflow; preserve directory-change evidence and escalate mixed or incomplete answers. If local answers stay suspicious or unresolved, review alerts for the modifying `user.id`; use controller `host.id` alert history only when actor evidence is sparse or controller compromise is plausible.
+    - !{investigate{"description":"","label":"Recent alerts tied to this modifying identity","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":"Recent alerts on this domain controller","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"}}
+
+
+*False positive analysis*
+
+
+- AdminSDHolder ACL hardening, delegated-directory cleanup, security-baseline tooling, or migration automation are narrow tier-0 exceptions, not routine administration. Confirm the exact attribute/value/operation for `winlog.event_data.ObjectDN`, expected admin or service-account session, bounded `winlog.event_data.OpCorrelationID`, matching controller/template rollout, and no unrelated actor or controller alerts. If change records, automation inventory, or deployment records exist, require alignment; otherwise prove the current actor/action or service-account/template fit from telemetry first, then use prior recurrence only to support exception stability.
+- Before creating an exception, validate recurrence of the same `user.id` or `winlog.event_data.SubjectUserSid`, specific attribute, object, `winlog.event_data.DSName`, bounded operation shape, and controller pattern across prior alerts from this rule. Build the exception from that minimum confirmed workflow only after the current event is fully explained, and avoid exceptions on AdminSDHolder changes, Windows Security event "5136", or the rule name alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse any temporary containment and record the exact actor, session, AdminSDHolder object, changed attribute, operation-correlation, and controller pattern that proved the recognized workflow. Do not keep a broad exception unless the same workflow recurs.
+- If suspicious but unconfirmed, preserve the triggering `5136` event, the correlated `winlog.event_data.OpCorrelationID` change set, the current AdminSDHolder security descriptor, linked `4624` or `4648` session records, and case exports before containment. Apply reversible containment first, such as temporarily restricting the modifying account's directory-write path or increasing monitoring on the recovered actor and controller. Use broader account disablement or domain-controller isolation only if related alerts or follow-on directory abuse show active compromise and the AD response owner accepts the operational impact.
+- If confirmed malicious, export the current AdminSDHolder security descriptor, recovered `5136` change set, replication context, implicated object identity, actor SID, logon session, and source-origin evidence before rollback or account action. Contain the modifying account and any recovered source endpoint or IP through identity-response or endpoint-response tooling; if direct response is unavailable, escalate that preserved evidence set to the AD or incident-response team that can act.
+- After containment, review protected users and groups for unauthorized ACEs, owner changes, or delegated rights that may have been restamped from the tampered template before removing them. Restore the AdminSDHolder ACL to a known-good state, verify clean replication across domain controllers, then reset or rotate privileged credentials exposed or newly granted through the unauthorized template.
+- Post-incident hardening: restrict AdminSDHolder write access to dedicated tier-0 administration paths, baseline the expected AdminSDHolder security descriptor, keep directory-service change auditing for `5136` and linked authentication logging enabled on domain controllers, and record telemetry gaps that limited the investigation.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Audit Directory Service Changes must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-directory-service-changes
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.code:5136 and host.os.type:"windows" and winlog.event_data.ObjectDN:CN=AdminSDHolder,CN=System*
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* Sub-technique:
+** Name: Domain Accounts
+** ID: T1078.002
+** Reference URL: https://attack.mitre.org/techniques/T1078/002/
+* 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-24/prebuilt-rule-8-19-24-adminsdholder-sdprop-exclusion-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-adminsdholder-sdprop-exclusion-added.asciidoc
new file mode 100644
index 0000000000..1109871e51
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-adminsdholder-sdprop-exclusion-added.asciidoc
@@ -0,0 +1,164 @@
+[[prebuilt-rule-8-19-24-adminsdholder-sdprop-exclusion-added]]
+=== AdminSDHolder SDProp Exclusion Added
+
+Identifies a modification on the dsHeuristics attribute on the bit that holds the configuration of groups excluded from the SDProp process. The SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, meaning that groups excluded will remain unchanged. Attackers can abuse this misconfiguration to maintain long-term access to privileged accounts in these groups.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.cert.ssi.gouv.fr/uploads/guide-ad.html#dsheuristics_bad
+* https://petri.com/active-directory-security-understanding-adminsdholder-object
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Data Source: Active Directory
+* Resources: Investigation Guide
+* Use Case: Active Directory Monitoring
+* Data Source: Windows Security Event Logs
+
+*Version*: 219
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating AdminSDHolder SDProp Exclusion Added*
+
+
+
+*Possible investigation steps*
+
+
+- What did the 5136 record do to the SDProp exclusion mask?
+  - Focus: `winlog.event_data.OperationType` and `winlog.event_data.AttributeValue`; decode position "1" = Account Operators, "2" = Server Operators, "4" = Print Operators, "8" = Backup Operators, with additive hex combinations.
+  - Implication: escalate when an added or replaced value leaves any operator group excluded from SDProp, especially multiple groups; lower concern only when paired 5136 records prove removal and rollback to 0. If the active mask is unproven, treat as unresolved.
+
+- Did the change land on the forest configuration object controlling SDProp behavior?
+  - Focus: `winlog.event_data.ObjectDN`, `winlog.event_data.DSName`, and `host.name`.
+  - Implication: forest-impacting when `winlog.event_data.ObjectDN` is the Directory Service object under "CN=Windows NT,CN=Services,CN=Configuration" and the naming context is in scope; narrow only when `winlog.event_data.DSName` and `host.name` identify a lab or recovery forest.
+
+- Which identity changed "dSHeuristics", and does it fit directory configuration work?
+  - Focus: `user.id`, `user.name`, `user.domain`, and `winlog.event_data.SubjectLogonId`.
+  - Implication: suspicious when the writer is not a dedicated directory-configuration identity for the affected forest; reduce concern only when identity and object match confirmed hardening or recovery.
+
+- What source session produced the directory change?
+  - Why: the 5136 event names the writer, but session origin separates console or jump-host administration from remote or alternate-credential use.
+  - Focus: on the domain controller, find 4624 events where `winlog.event_data.TargetLogonId` equals the 5136 `winlog.event_data.SubjectLogonId`; read `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Linked logon for the modifying session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Hint: search 4648 by `winlog.event_data.SubjectLogonId` when explicit-credential use would change the answer. !{investigate{"description":"","label":"Explicit credential events for the modifying session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Hint: Missing authentication telemetry is unresolved, not benign.
+  - Implication: escalate for unexpected workstation, direct DC logon, remote-interactive path, NTLM where Kerberos is expected, or explicit-credential use; reduce concern when origin, logon type, and authentication package fit the confirmed directory-configuration case.
+
+- Did the same operation or session change other privileged directory state?
+  - Why: SDProp exclusion is most damaging with AdminSDHolder ACL, privileged membership, delegation, or security-descriptor changes that persist because SDProp no longer resets excluded groups.
+  - Focus: 5136 events on the same `host.id` where `winlog.event_data.OpCorrelationID` matches, then the same `winlog.event_data.SubjectLogonId` if needed; read `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeLDAPDisplayName`, and `winlog.event_data.AttributeValue`. !{investigate{"description":"","label":"All 5136 events in this SDProp exclusion change set","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.OpCorrelationID","queryType":"phrase","value":"{{winlog.event_data.OpCorrelationID}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Range: inspect the alert burst first; if the mask stayed non-zero, extend through the weakened interval for follow-on membership, ACL, delegation, or security-descriptor changes on excluded groups.
+  - Implication: escalate when the same burst touches AdminSDHolder, privileged groups, delegation attributes, or security descriptors; lower suspicion only when grouped changes stay limited to one intentional SDProp configuration action.
+
+- If local evidence remains suspicious or unresolved, do related alerts change scope or urgency?
+  - Focus: recent alerts for the same `user.id`. !{investigate{"description":"","label":"Alerts associated with the writer","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: also review domain controller `host.id` when controller compromise or change spread remains unresolved. !{investigate{"description":"","label":"Alerts associated with the domain controller","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 response when the writer or controller has related AD tampering, unusual authentication, privilege abuse, persistence, credential-access, or lateral-movement alerts; keep scope local only when related alerts are quiet and local telemetry supports a bounded explanation.
+
+- Escalate for an active non-zero in-scope mask, abnormal writer or source session, or grouped privileged changes; close only when mask, operation, scope, writer, session, and grouped 5136 prove rollback to 0 or confirmed hardening/testing without contradictions; preserve and escalate mixed or incomplete cases.
+
+
+*False positive analysis*
+
+
+- Treat non-zero SDProp exclusions as suspicious. Directory hardening or delegated-admin redesign is benign only when excluded operator groups were intentionally stripped of privileged rights and a dedicated configuration workflow made the change. Confirm `winlog.event_data.AttributeValue` maps to the planned group set, `winlog.event_data.ObjectDN` and `winlog.event_data.DSName` identify the expected Directory Service object, `user.id` and recovered `source.ip` identify the authorized admin session, and `winlog.event_data.OpCorrelationID` activity stays bounded to maintenance. If evidence is unavailable, the alert remains unresolved; do not close from repetition.
+- Lab-forest or recovery-forest testing may intentionally change "dSHeuristics". Confirm `winlog.event_data.DSName` and `host.name` place the event in that forest, `user.id` and `winlog.event_data.SubjectLogonId` identify the designated test administrator, and related alerts on `host.id` lack unrelated credential-access, persistence, or lateral-movement activity. If records are unavailable, treat as unresolved unless another reliable source confirms forest identity and administrator.
+- Before creating an exception, validate recurrence for the same `user.id`, `host.id`, `winlog.event_data.ObjectDN`, `winlog.event_data.DSName`, `winlog.event_data.AttributeValue`, and bounded `winlog.event_data.OpCorrelationID` pattern. Avoid exceptions on "dSHeuristics", event 5136, or rule name alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and document the mask, object scope, writer, session origin, controller, and confirmation source proving the authorized workflow. Keep exceptions tied to the recurring workflow pattern, not the attribute or event code.
+- If suspicious but unconfirmed, preserve triggering and grouped 5136 records, linked 4624 or 4648 authentication records, and key identifiers: `winlog.event_data.ObjectGUID`, `winlog.event_data.OpCorrelationID`, `user.id`, `host.id`, and recovered `source.ip`. Apply reversible containment tied to those findings: restrict the implicated account from directory-configuration changes, increase DC monitoring, or contain the recovered source host if not a critical controller. Escalate to account disablement or host isolation only when related alerts or session evidence show broader abuse.
+- If confirmed malicious, preserve directory-change and authentication evidence before changing configuration. Restore "dSHeuristics" to the expected value, verify rollback replication on other domain controllers, and review the same `winlog.event_data.OpCorrelationID` or `winlog.event_data.SubjectLogonId` for unauthorized directory changes. Contain the writer account or recovered source host with identity or endpoint response tooling; avoid isolating a domain controller unless broader compromise is confirmed and directory owners can tolerate the action.
+- After containment, check whether excluded operator groups received unauthorized membership, ACL, delegation, or security-descriptor changes while SDProp protection was weakened, and roll back only malicious changes identified.
+- Post-incident hardening: keep Windows Security 5136 directory-service auditing enabled on domain controllers, restrict "dSHeuristics" changes to dedicated directory-configuration workflows, reduce or remove privileged rights from built-in operator groups where possible, and record visibility gaps or adjacent variants for engineering review.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Audit Directory Service Changes must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-directory-service-changes
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+any where host.os.type == "windows" and event.code == "5136" and
+  winlog.event_data.AttributeLDAPDisplayName : "dSHeuristics" and
+  winlog.event_data.OperationType : "%%14674" and
+  length(winlog.event_data.AttributeValue) > 15 and
+  winlog.event_data.AttributeValue regex~ "[0-9]{15}([1-9a-f]).*"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* Sub-technique:
+** Name: Domain Accounts
+** ID: T1078.002
+** Reference URL: https://attack.mitre.org/techniques/T1078/002/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Domain or Tenant Policy Modification
+** ID: T1484
+** Reference URL: https://attack.mitre.org/techniques/T1484/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-aws-eks-access-entry-granted-cluster-admin-policy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-aws-eks-access-entry-granted-cluster-admin-policy.asciidoc
new file mode 100644
index 0000000000..92f00353a5
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-aws-eks-access-entry-granted-cluster-admin-policy.asciidoc
@@ -0,0 +1,128 @@
+[[prebuilt-rule-8-19-24-aws-eks-access-entry-granted-cluster-admin-policy]]
+=== AWS EKS Access Entry Granted Cluster Admin Policy
+
+Detects when the AmazonEKSClusterAdminPolicy or AmazonEKSAdminPolicy is associated with a principal via the EKS Access Entries API. This grants full cluster-admin equivalent access to the specified IAM user or role. Unlike the legacy aws-auth ConfigMap which is only visible in Kubernetes audit logs, Access Entries modifications appear in CloudTrail, providing an additional detection surface. Attackers who have obtained IAM permissions to manage EKS access entries can use this API to backdoor cluster access for persistence, mapping attacker-controlled IAM identities to cluster-admin privileges without modifying any Kubernetes resources.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html
+* https://docs.aws.amazon.com/eks/latest/APIReference/API_AssociateAccessPolicy.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Kubernetes
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS CloudTrail
+* 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 AWS EKS Access Entry Granted Cluster Admin Policy*
+
+
+Successful AssociateAccessPolicy with AmazonEKSClusterAdminPolicy or AmazonEKSAdminPolicy binds highly privileged
+Kubernetes access to an IAM principal. Review who invoked the API (user.name, aws.cloudtrail.user_identity fields),
+source.ip, user_agent.original, cloud.account.id, and cloud.region.
+
+
+*Possible investigation steps*
+
+
+- Parse aws.cloudtrail.request_parameters and response elements for cluster name, access entry ARN, and policy ARN.
+- Confirm whether the IAM principal receiving the policy is expected to have cluster-admin-class access.
+- Correlate with other EKS API calls (CreateAccessEntry, UpdateAccessEntry) and with Kubernetes audit activity from
+  newly authorized principals.
+- Compare against change records for migrations from aws-auth or new administrator onboarding.
+
+
+*Response and remediation*
+
+
+- If unauthorized, disassociate the policy or remove the access entry per AWS guidance; audit who can call eks:*
+  APIs in IAM.
+- Rotate credentials for any suspected compromised IAM principal; review organizational SCPs and cluster auth mode.
+
+
+*Additional information*
+
+
+- https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html[Amazon EKS access entries]
+- https://docs.aws.amazon.com/eks/latest/APIReference/API_AssociateAccessPolicy.html[AssociateAccessPolicy]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"aws.cloudtrail" and
+event.provider:"eks.amazonaws.com" and
+event.action:"AssociateAccessPolicy" and
+event.outcome:"success" and
+aws.cloudtrail.request_parameters:(*AmazonEKSClusterAdminPolicy* or *AmazonEKSAdminPolicy*)
+
+----------------------------------
+
+*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-24/prebuilt-rule-8-19-24-aws-eks-access-entry-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-aws-eks-access-entry-modified.asciidoc
new file mode 100644
index 0000000000..07f4cd3590
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-aws-eks-access-entry-modified.asciidoc
@@ -0,0 +1,123 @@
+[[prebuilt-rule-8-19-24-aws-eks-access-entry-modified]]
+=== AWS EKS Access Entry Modified
+
+Detects successful Amazon EKS Access Entries API operations that create, update, attach, detach, or delete authentication mappings between IAM principals and the cluster. Changes to access entries alter who can authenticate to Kubernetes and what Kubernetes-level permissions they receive, without requiring edits to in-cluster RBAC objects. Unexpected callers or timing may indicate persistence or privilege abuse. Common automation identities (service-linked roles, eksctl, Terraform, CloudFormation role patterns) are excluded to reduce noise; tune further for your deployment pipelines.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Kubernetes
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS CloudTrail
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Privilege Escalation
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating AWS EKS Access Entry Modified*
+
+
+Review aws.cloudtrail.user_identity (ARN, type), user.name, source.ip, user_agent.original, cloud.account.id, and
+cloud.region. Map event.action to intent: new principal (CreateAccessEntry), policy binding changes (AssociateAccessPolicy,
+DisassociateAccessPolicy), metadata updates (UpdateAccessEntry), or removal (DeleteAccessEntry).
+
+
+*Possible investigation steps*
+
+
+- Inspect aws.cloudtrail.request_parameters and response_elements for cluster name, principal ARN, and policy ARNs.
+- Compare against change management and infrastructure-as-code deploy windows.
+- Correlate with Kubernetes audit logs for subsequent API activity from identities tied to the affected access entry.
+- Pair with the higher-fidelity rule EKS Access Entry Granted Cluster Admin Policy when AssociateAccessPolicy fires.
+
+
+*Response and remediation*
+
+
+- If unauthorized, revert access entry changes via AWS APIs or console; restrict eks:* permissions and review SCPs.
+- Rotate credentials for compromised IAM principals as appropriate.
+
+
+*Additional information*
+
+
+- https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html[Amazon EKS access entries]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"aws.cloudtrail" and event.provider:"eks.amazonaws.com" and
+event.action:("CreateAccessEntry" or "AssociateAccessPolicy" or "UpdateAccessEntry" or "DisassociateAccessPolicy" or "DeleteAccessEntry") and
+event.outcome:"success" and
+not aws.cloudtrail.user_identity.arn:(*AWSServiceRoleForAmazonEKS* or *eksctl* or *terraform* or *AWSCloudFormation*)
+
+----------------------------------
+
+*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 Container Cluster Roles
+** ID: T1098.006
+** Reference URL: https://attack.mitre.org/techniques/T1098/006/
+* 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-aws-eks-control-plane-logging-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-aws-eks-control-plane-logging-disabled.asciidoc
new file mode 100644
index 0000000000..0561c6e87e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-aws-eks-control-plane-logging-disabled.asciidoc
@@ -0,0 +1,102 @@
+[[prebuilt-rule-8-19-24-aws-eks-control-plane-logging-disabled]]
+=== AWS EKS Control Plane Logging Disabled
+
+Detects successful Amazon EKS UpdateClusterConfig requests that disable control plane logging. Disabling EKS API server and control plane logs can reduce visibility into cluster activity and may indicate defense evasion following compromised AWS credentials or unauthorized administrative access. EKS control plane logging changes are typically rare and should align with approved maintenance or cost optimization workflows.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-aws.cloudtrail-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html
+* https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Kubernetes
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS CloudTrail
+* 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 EKS Control Plane Logging Disabled*
+
+
+Review the caller (user.name, aws.cloudtrail.user_identity.arn, type), source.ip, user_agent.original, cloud.account.id, and cloud.region. Confirm which log types were disabled and whether the change aligns with a planned change window.
+
+
+*Possible investigation steps*
+
+
+- Inspect aws.cloudtrail.request_parameters and response elements for cluster name and logging settings.
+- Correlate with adjacent EKS and IAM activity from the same principal (access entry changes, iam policy attachments, sts assume events) and with any Kubernetes audit telemetry available.
+- Check whether control plane logs stopped ingesting shortly after the change and scope potential visibility gaps.
+
+
+*Response and remediation*
+
+
+- If unauthorized, re-enable EKS control plane logging and restrict IAM permissions that allow eks:UpdateClusterConfig.
+- Rotate or revoke compromised credentials and review for additional EKS or IAM persistence changes.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"aws.cloudtrail" and
+event.provider:"eks.amazonaws.com" and
+event.action:"UpdateClusterConfig" and
+event.outcome:"success" and
+aws.cloudtrail.request_parameters:*logging*enabled=false*
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
+* Sub-technique:
+** Name: Disable or Modify Cloud Logs
+** ID: T1562.008
+** Reference URL: https://attack.mitre.org/techniques/T1562/008/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-aws-ssm-session-manager-child-process-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-aws-ssm-session-manager-child-process-execution.asciidoc
new file mode 100644
index 0000000000..29d0198311
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-aws-ssm-session-manager-child-process-execution.asciidoc
@@ -0,0 +1,141 @@
+[[prebuilt-rule-8-19-24-aws-ssm-session-manager-child-process-execution]]
+=== AWS SSM Session Manager Child Process Execution
+
+Identifies process start events where the parent process is the AWS Systems Manager (SSM) Session Manager worker. Session Manager provides interactive shell access to EC2 instances and hybrid nodes without bastion hosts or open inbound ports. Adversaries abuse it for remote execution and lateral movement using legitimate AWS credentials and IAM permissions. This rule surfaces endpoint execution occurring under that worker for visibility and hunting. Expect noise from authorized administrative sessions.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-endpoint.events.process*
+* auditbeat-*
+* logs-auditd_manager.auditd-*
+* logs-crowdstrike.fdr*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.mitiga.io/blog/abusing-the-amazon-web-services-ssm-agent-as-a-remote-access-trojan
+* https://hackingthe.cloud/aws/post_exploitation/run_shell_commands_on_ec2/
+* https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html
+
+*Tags*: 
+
+* Domain: Endpoint
+* Domain: Cloud
+* OS: Linux
+* OS: Windows
+* OS: macOS
+* Use Case: Threat Detection
+* Tactic: Execution
+* Data Source: Elastic Defend
+* Data Source: Auditd Manager
+* Data Source: Crowdstrike
+* Data Source: SentinelOne
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating AWS SSM Session Manager Child Process Execution*
+
+
+AWS Systems Manager Session Manager starts a session worker process on the endpoint; commands and shells you run in the
+session appear as child processes of that worker. The same mechanism is used for authorized administration and for
+adversary activity when IAM credentials or instance roles allow `ssm:StartSession` (or related) abuse.
+
+
+*Possible investigation steps*
+
+
+- Confirm whether the host is an EC2 instance or managed node that legitimately uses Session Manager.
+- Review `process.command_line`, `process.executable`, `process.user.name`, and `user.name` for the child process to
+  judge intent (reconnaissance, download, credential access, persistence, etc.).
+- Correlate timing with AWS CloudTrail for `StartSession`, `ResumeSession`, or related SSM API calls and the IAM
+  principal that initiated the session.
+- Pivot on the same `host.id` or instance identifier for other alerts or SSM activity in the same window.
+
+
+*False positive analysis*
+
+
+- Routine interactive or automated administration via Session Manager is expected to match this rule by design.
+- Prefer exclusions tied to stable attributes (approved IAM roles, automation service accounts, known script paths)
+  rather than broad process-name allowlists unless validated.
+
+
+*Response and remediation*
+
+
+- If activity is unauthorized: revoke or rotate exposed IAM credentials, review SSM and VPC endpoints policies, and
+  terminate suspicious sessions from the AWS console or API.
+- Isolate the instance if compromise is suspected and perform endpoint forensics following your incident response
+  playbook.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.category: "process" and event.action : ("exec" or "exec_event" or "start" or "ProcessRollup2" or "executed" or "process_started") and
+(
+ process.parent.name:("ssm-session-worker.exe" or "ssm-session-worker" or "ssm-document-worker.exe" or "ssm-document-worker") or 
+ (process.name : "powershell.exe" and process.args : *awsrunPowerShellScript*) or
+ (process.name : ("dash" or "sh" or "bash") and process.args : *awsrunShellScript*) or 
+ (process.parent.name : "powershell.exe" and process.parent.args : *awsrunPowerShellScript*) or
+ (process.parent.name : ("dash" or "sh" or "bash") and process.parent.args : *awsrunShellScript*)
+ ) and 
+ process.command_line:* and 
+ not (process.name : "powershell.exe" and process.args :("$str.Substring($str.length" or *Convert-GuidToCompressedGuid* or get-wmiobject* or $wmi_proc* or *win32_quickfixengineering*)) and 
+ not process.executable : ("/usr/bin/lscpu" or "/usr/bin/snap" or "/usr/bin/rpm" or "/usr/bin/dpkg-query" or /snap/snapd/*/usr/bin/snap or "/usr/bin/id" or "C:\\Program Files\\Amazon\\SSM\\Plugins\\SessionManagerShell\\winpty-agent.exe") and 
+ not (process.name : (dash or bash or sh or _script.sh) and process.args : /var/lib/amazon/ssm/*/document/orchestration/*/_script.sh)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: Unix Shell
+** ID: T1059.004
+** Reference URL: https://attack.mitre.org/techniques/T1059/004/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
+* Technique:
+** Name: Cloud Administration Command
+** ID: T1651
+** Reference URL: https://attack.mitre.org/techniques/T1651/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-bypass-uac-via-event-viewer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-bypass-uac-via-event-viewer.asciidoc
new file mode 100644
index 0000000000..4cfe75d747
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-bypass-uac-via-event-viewer.asciidoc
@@ -0,0 +1,194 @@
+[[prebuilt-rule-8-19-24-bypass-uac-via-event-viewer]]
+=== Bypass UAC via Event Viewer
+
+Identifies User Account Control (UAC) bypass via eventvwr.exe. Attackers bypass UAC to stealthily execute code with elevated permissions.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Resources: Investigation Guide
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Microsoft Defender XDR
+* Data Source: Windows Security Event Logs
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+
+*Version*: 323
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Bypass UAC via Event Viewer*
+
+
+
+*Possible investigation steps*
+
+
+- What did Event Viewer launch in the alert?
+  - Focus: alert time, host/user scope, `process.parent.executable`, `process.executable`, `process.command_line`, and integrity level.
+  - Implication: escalate when eventvwr.exe launches an unexpected high-integrity child or script/LOLBIN command instead of the normal console or error-reporting helper; lower suspicion only when path normalization proves helper behavior or fields match controlled UAC testing.
+
+- Does the child payload identity and command line fit helper behavior or payload execution?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.command_line`.
+  - Hint: use `process.pe.original_file_name` when path, filename, or signer conflicts suggest masquerading.
+  - Implication: escalate when the child is unsigned, rare, user-writable, signer-mismatched, or runs PowerShell, cmd.exe, rundll32.exe, mshta.exe, wscript.exe, regsvr32.exe, remote retrieval, encoded content, or admin-path writes; lower suspicion only when identity, signer, hash history, and command intent fit controlled testing or helper behavior.
+
+- What started Event Viewer, and did the session fit an interactive admin task?
+  - Focus: recover the Event Viewer start using `host.id` + `process.parent.entity_id`, then review executable, command line, and logon type. !{investigate{"description":"","label":"Event Viewer parent process event","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `process.parent.entity_id` is absent, use `host.id` + `process.parent.pid` in a tight `@timestamp` window; PID-only recovery is weaker. Inspect `process.Ext.ancestry` only when direct lineage is incomplete.
+  - Implication: escalate when Office, browser, archive, scripting, RMM, or remote/noninteractive activity launched Event Viewer; lower suspicion only when launcher and session also support controlled testing or helper behavior. Routine Event Viewer use should open Microsoft Management Console, not an arbitrary child.
+
+- Is there corroborating current-user mscfile hijack evidence when process evidence stays suspicious?
+  - Focus: if registry telemetry exists, review current-user mscfile shell-open command content, creator/deleter process, and timing; HKCU may render as HKEY_USERS\<user SID>\Software\Classes\mscfile\shell\open\command.
+  - Hint: use this as corroboration, not as a prerequisite for escalation. Missing registry telemetry is unresolved, not benign; absence of the key after the alert can mean cleanup.
+  - Implication: escalate or raise confidence when the value points to the alert child, a script interpreter, a temp/user path, or was created or removed around the alert; lower suspicion only when artifact evidence fits the same confirmed test or helper behavior already supported by process evidence.
+
+- What did the elevated child do next?
+  - Focus: child process events where `process.parent.entity_id` matches `process.entity_id`; review executable, command line, and integrity level. !{investigate{"description":"","label":"Process starts from the elevated child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}}
+  - Hint: prefer entity-ID matches; if only PID matches are available, keep them tightly anchored to `@timestamp`.
+  - Implication: escalate when the elevated child spawns shells, discovery, credential tools, droppers, installers, persistence helpers, or network-capable tooling; do not close on absent follow-on children when the original command, lineage, or mscfile evidence remains suspicious.
+
+- Does the same Event Viewer payload pattern recur beyond this host?
+  - Range: run only when local process, command, artifact, or lineage evidence remains suspicious or unresolved.
+  - Focus: `process.hash.sha256`, stable command-line fragments, and `process.executable`, scoped by host and user.
+    - !{investigate{"description":"","label":"Recent process starts with the same child identity","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Alerts associated with the user or host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}],[{"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 the same payload or Event Viewer child pattern appears for unrelated hosts or users; keep locally scoped when recurrence is limited to the same confirmed test cohort and no contradictory local evidence remains.
+
+- Based on the evidence gathered, what disposition is supported?
+  - Escalate on strong local abuse signals across child behavior, payload identity, command intent, launcher/session, mscfile artifacts, follow-on children, or scope; close only when process evidence and recovery prove helper normalization or controlled testing; preserve evidence and escalate when registry corroboration is unavailable or evidence is mixed.
+
+
+*False positive analysis*
+
+
+- This behavior is an operational anti-pattern. Realistic benign paths are controlled UAC testing or a sensor/path-normalization miss for expected Microsoft Management Console (mmc.exe) or Windows Error Reporting (WerFault.exe) child activity. Confirm identity, launcher/session context, command line, and any recovered mscfile artifact support the same benign explanation; if any dimension contradicts it, do not close as benign.
+- Build exceptions from the minimum confirmed pattern: stable child hash or signer, exact Event Viewer parent-child relationship, bounded `user.id` and `host.id`, and test or normalization evidence. Avoid exceptions on `process.parent.name`, `process.name`, or `user.name` alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, document the exact evidence that resolved the alert, reverse temporary containment, and keep any exception scoped to the confirmed child identity, parent-child pattern, and host/user cohort.
+- If suspicious but unconfirmed, preserve the alert, process event exports, Event Viewer parent and child entity IDs, command lines, hashes/signers, recovered mscfile value/history, child process tree, and process-scoped file or network indicators when available.
+- After preservation, apply reversible containment tied to the findings, such as endpoint isolation for non-critical hosts or temporary egress restrictions for confirmed suspicious destinations. Weigh host criticality before isolation.
+- If confirmed malicious, preserve the confirmed hashes/domains/destinations and elevated child process details, then isolate the host as needed, block confirmed malicious indicators, and suspend or terminate malicious processes only after recording their evidence.
+- Eradicate only the artifacts found during triage: remove malicious payloads, restore the current-user mscfile handler to the expected mmc.exe behavior or remove the malicious override, clean related persistence, and remediate the entry vector that launched Event Viewer.
+- Reset credentials or disable accounts only when process/session evidence shows credential exposure, explicit misuse, or attacker use of the affected `user.id`.
+- After eradication, reduce repeat exposure by reviewing local administrator membership, using the highest feasible UAC prompt level, and patching affected Windows builds.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/crowdstrike-integration[CrowdStrike]
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+- https://ela.st/audit-process-creation[Windows Process Creation Logs]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+  process.parent.name : "eventvwr.exe" and
+  not process.executable : (
+        "?:\\Windows\\SysWOW64\\mmc.exe",
+        "?:\\Windows\\System32\\mmc.exe",
+        "?:\\Windows\\SysWOW64\\WerFault.exe",
+        "?:\\Windows\\System32\\WerFault.exe",
+
+        /* Crowdstrike specific exclusion as it uses NT Object paths */
+        "\\Device\\HarddiskVolume*\\Windows\\Sys?????\\mmc.exe",
+        "\\Device\\HarddiskVolume*\\Windows\\Sys?????\\WerFault.exe"
+  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Abuse Elevation Control Mechanism
+** ID: T1548
+** Reference URL: https://attack.mitre.org/techniques/T1548/
+* Sub-technique:
+** Name: Bypass User Account Control
+** ID: T1548.002
+** Reference URL: https://attack.mitre.org/techniques/T1548/002/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Abuse Elevation Control Mechanism
+** ID: T1548
+** Reference URL: https://attack.mitre.org/techniques/T1548/
+* Sub-technique:
+** Name: Bypass User Account Control
+** ID: T1548.002
+** Reference URL: https://attack.mitre.org/techniques/T1548/002/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-cobalt-strike-command-and-control-beacon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-cobalt-strike-command-and-control-beacon.asciidoc
new file mode 100644
index 0000000000..27dcf806cc
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-cobalt-strike-command-and-control-beacon.asciidoc
@@ -0,0 +1,134 @@
+[[prebuilt-rule-8-19-24-cobalt-strike-command-and-control-beacon]]
+=== Cobalt Strike Command and Control Beacon
+
+Cobalt Strike is a threat emulation platform commonly modified and used by adversaries to conduct network attack and exploitation campaigns. This rule detects a network activity algorithm leveraged by Cobalt Strike implant beacons for command and control.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* packetbeat-*
+* auditbeat-*
+* filebeat-*
+* logs-network_traffic.*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://blog.morphisec.com/fin7-attacks-restaurant-industry
+* https://www.fireeye.com/blog/threat-research/2017/04/fin7-phishing-lnk.html
+* https://www.elastic.co/security-labs/collecting-cobalt-strike-beacons-with-the-elastic-stack
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Tactic: Command and Control
+* Domain: Endpoint
+* 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 Cobalt Strike Command and Control Beacon*
+
+
+Cobalt Strike is a penetration testing tool often repurposed by attackers for malicious activities, particularly for establishing command and control (C2) channels. Adversaries exploit its beaconing feature to communicate with compromised systems using common protocols like HTTP or TLS. The detection rule identifies suspicious network patterns, such as specific domain naming conventions, indicative of Cobalt Strike's C2 activity, helping analysts pinpoint potential threats.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific domain that triggered the rule, focusing on the pattern [a-z]{3}.stage.[0-9]{8}\..* to determine if it matches known malicious domains.
+- Analyze the network traffic logs associated with the alert, specifically looking at events categorized under network or network_traffic with types tls or http, to gather more context about the communication.
+- Investigate the source IP address and destination domain involved in the alert to determine if they have been associated with previous malicious activities or are listed in threat intelligence databases.
+- Examine the timeline of the network activity to identify any patterns or anomalies that could indicate a larger campaign or coordinated attack.
+- Check for any related alerts or incidents in the security information and event management (SIEM) system that might provide additional context or indicate a broader compromise.
+- Assess the affected endpoint for any signs of compromise, such as unusual processes or connections, to determine if further containment or remediation actions are necessary.
+
+
+*False positive analysis*
+
+
+- Legitimate software updates or patch management systems may use similar domain naming conventions. Review and whitelist known update servers to prevent false alerts.
+- Internal development or testing environments might mimic Cobalt Strike's domain patterns for legitimate purposes. Identify and exclude these environments from the rule.
+- Automated scripts or tools that generate network traffic with similar domain structures can trigger false positives. Monitor and document these tools, then create exceptions for their activity.
+- Some content delivery networks (CDNs) might use domain patterns that match the rule's criteria. Verify and exclude trusted CDNs to reduce unnecessary alerts.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the rule's effectiveness.
+
+
+*Response and remediation*
+
+
+- Isolate the affected systems immediately to prevent further communication with the Cobalt Strike C2 server. This can be done by disconnecting the network or using network segmentation techniques.
+- Conduct a thorough forensic analysis of the compromised systems to identify the extent of the breach and any additional payloads or backdoors that may have been installed.
+- Remove any identified Cobalt Strike beacons or related malware from the affected systems using updated antivirus or endpoint detection and response (EDR) tools.
+- Change all credentials and access tokens that may have been exposed or used on the compromised systems to prevent unauthorized access.
+- Monitor network traffic for any signs of re-infection or communication attempts with known Cobalt Strike C2 domains, using updated threat intelligence feeds.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data have been compromised.
+- Implement network-level controls, such as blocking known malicious domains and IP addresses associated with Cobalt Strike, to prevent future attacks.
+
+
+*Threat intel*
+
+
+This activity has been observed in FIN7 campaigns.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+((event.category: (network OR network_traffic) AND network.protocol: (tls OR http))
+    OR data_stream.dataset: (network_traffic.tls OR network_traffic.http)
+) AND destination.domain:/[a-z]{3}.stage.[0-9]{8}\..*/
+
+----------------------------------
+
+*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: 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-command-and-scripting-interpreter-via-windows-scripts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-command-and-scripting-interpreter-via-windows-scripts.asciidoc
new file mode 100644
index 0000000000..a9d892b199
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-command-and-scripting-interpreter-via-windows-scripts.asciidoc
@@ -0,0 +1,211 @@
+[[prebuilt-rule-8-19-24-command-and-scripting-interpreter-via-windows-scripts]]
+=== Command and Scripting Interpreter via Windows Scripts
+
+Identifies PowerShell, PowerShell ISE, or Cmd execution spawned from Windows Script Host or MSHTA.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-system.security*
+* logs-windows.forwarded*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+* endgame-*
+* logs-crowdstrike.fdr*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* 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
+
+*Version*: 211
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Command and Scripting Interpreter via Windows Scripts*
+
+
+
+*Possible investigation steps*
+
+
+- What script-host-to-interpreter chain did the alert capture?
+  - Focus: `process.parent.name`, `process.parent.executable`, `process.parent.command_line`, `process.name`, and `process.command_line`.
+  - Implication: escalate when "wscript.exe" or "mshta.exe" launches PowerShell/pwsh/ISE/cmd from user-writable script/HTA, archive, download path, or URL; lower suspicion only when parent source, child command, `user.id`, and `host.id` fit one recognized logon, deployment, or vendor workflow.
+
+- Does the child command express staging, retrieval, persistence, or defense evasion?
+  - Focus: `process.command_line`: "-EncodedCommand"/"-e", "-NoProfile", hidden windows, execution-policy bypass, Invoke-Expression/DownloadString, cmd "/c" chaining, curl/bitsadmin retrieval, or schtasks/sc.exe changes.
+  - Hint: decode or reconstruct encoded or inline PowerShell before deciding intent; use script-block logs as optional corroboration.
+  - Follow-on: inspect child starts from `process.entity_id`; PID-only matches are timestamp-bound candidates. !{investigate{"description":"","label":"Child process events for the script-launched process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the command fetches content, decodes or executes inline script, launches another shell, or changes tasks/services; lower risk only when it runs a local script from the same logon, deployment, or vendor source without staging or unexpected egress.
+
+- Does the child binary identity fit the observed command line and location?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the child is renamed, unsigned or untrusted from a user-writable path, or mismatched to original file name; lower identity risk when signer, path, and hash history fit the expected interpreter, but identity alone never clears suspicious command intent.
+
+- Did the alerting process stage scripts, archives, or follow-on payloads?
+  - Focus: file events scoped by `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` in a tight window, checking `file.path`, `file.Ext.original.path`, `file.Ext.original.extension`, `file.Ext.header_bytes`, and `file.Ext.windows.zone_identifier`. !{investigate{"description":"","label":"File events for the script-launched 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"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: for PID fallback, require file time within the child lifetime.
+  - Implication: escalate when the child writes or renames scriptable or executable content under temp, profile, public, startup, or deceptive paths, especially with internet provenance or type/extension mismatch; absent file telemetry is unresolved, not benign.
+
+- Did same-process network events show retrieval, staging, or callback behavior?
+  - Focus: network events scoped by `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` in a tight window, separating DNS `dns.question.name` and `dns.resolved_ip` from connection `destination.ip`, `destination.port`, and `destination.as.organization.name`. !{investigate{"description":"","label":"Network events for the script-launched 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"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: map DNS `dns.resolved_ip` to later connections before treating a domain as confirmed.
+  - Implication: escalate when the process reaches external script-delivery, paste, storage, or C2 infra unrelated to the workflow; lower network risk when connections stay on recognized internal, proxy, or vendor services. Missing network telemetry is unresolved, not benign.
+
+- If local evidence stays suspicious or unresolved, does the same pattern appear in related alerts?
+  - Focus: related alerts for `user.id`, checking execution, persistence, defense-evasion, or outbound context before comparing preserved `process.parent.executable`, `process.parent.command_line`, or `process.command_line` fragments. !{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: use `host.id` alerts to test whether the chain is isolated, repeats with suspicious activity, or appears as adjacent variants such as "cscript.exe" launchers or delayed descendant shells. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same user or host shows repeated script-host launches, task or service changes, persistence, or outbound staging; keep local only when the pattern is isolated and local evidence supports one recognized workflow.
+
+- Escalate when parent provenance, command intent, identity, artifacts, destinations, or related alerts support proxy execution or second-stage activity; close only when alert-local evidence and recovery bind one recognized workflow, with outside confirmation for telemetry gaps; preserve artifacts and escalate when evidence conflicts or visibility is incomplete.
+
+
+*False positive analysis*
+
+
+- Logon scripts and deployment wrappers can legitimately launch cmd or PowerShell through Windows Script Host. Confirm only when `process.parent.executable`, `process.parent.command_line`, `process.command_line`, `user.id`, `host.id`, and same-process `file.path` or `destination.ip` recovered through `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` in a tight window, align with one recognized workflow. If file or network telemetry is absent, use outside confirmation. Stable recurrence for that parent source, child command, user, and host can support closure when script inventory or change context exists; first-observed workflows need outside confirmation before exceptioning. Any mismatch keeps the case suspicious.
+- Vendor/installer/hardware-diagnostic HTA/VBS launchers can trigger this rule. Confirm only when `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, parent script path, file writes, and destinations match one vendor package. Without package context, recurring signer/hash, parent source, child command, and host cohort can support closure; first-observed packages need outside confirmation.
+- For exceptions, validate: `process.parent.executable`, `process.parent.command_line`, child `process.executable`, stable `process.command_line` fragment, `process.code_signature.subject_name`, `user.id`, and `host.id`. Avoid exceptions on `process.name`, child `process.executable`, or parent process name alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and record the parent script path, child command pattern, signer, `user.id`, and `host.id` proving the workflow. Create exceptions only for exact workflows recurring in prior rule alerts.
+- If suspicious but unconfirmed, preserve the process event, `process.entity_id` or `process.pid` with `host.id` and time, command lines, suspicious `file.path` values, and confirmed `dns.question.name`, `destination.ip`, or `destination.port` before response. Apply reversible containment first: temporary destination blocking, disabling newly created scripts or tasks, or heightened host monitoring. Isolate only when corroborating staging, persistence, or outbound activity is confirmed and interruption is tolerable. Avoid destructive cleanup until scope is clearer.
+- If confirmed malicious, preserve `process.entity_id`, `process.parent.entity_id`, command lines, written `file.path` artifacts, and confirmed destinations, then isolate the host or block destinations based on staging and network evidence. Terminate malicious child or descendant processes after evidence capture; if direct endpoint response is unavailable, hand off artifacts for isolation or destination blocking.
+- Review related hosts and users for the same parent-child command pattern, confirmed destinations, and confirmed staged files only when endpoint file telemetry or related alerts preserve them. Then remove malicious scripts, HTA content, scheduled tasks, or dropped payloads, and remediate the delivery path.
+- Post-incident hardening: restrict unsupported "mshta.exe" and Windows Script Host use on workstations, retain process/file/network telemetry needed for this investigation, and record adjacent variants found during triage.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires telemetry from one of the configured source integrations to be enabled and ingested.
+
+
+*Supported data sources*
+
+
+This rule can use the following 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.command_line != null and
+  (
+    process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe", "cmd.exe") or
+    ?process.pe.original_file_name : ("powershell.exe", "pwsh.dll", "powershell_ise.exe", "Cmd.Exe")
+  ) and
+  process.parent.name : ("wscript.exe", "mshta.exe") and
+  not (
+    process.args : (
+      "C:\\Program Files\\Intel\\SUR\\QUEENCREEK\\x64\\task.bat",
+      "\"C:\\Program Files\\Intel\\SUR\\QUEENCREEK\\x64\\task.bat\""
+    ) or
+    process.command_line : (
+      "\"C:\\Windows\\system32\\cmd.exe\" /c auditpol.exe /set /SUBCATEGORY:*",
+      "\"C:\\Windows\\system32\\cmd.exe\" /c auditpol.exe /get*",
+      "\"C:\\Windows\\system32\\cmd.exe\" /c exit\""
+    ) or
+    (process.args == "-File" and process.args == "-ExecutionPolicy")
+  )
+  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")
+  ) 
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
+* Sub-technique:
+** Name: Windows Command Shell
+** ID: T1059.003
+** Reference URL: https://attack.mitre.org/techniques/T1059/003/
+* Sub-technique:
+** Name: Visual Basic
+** ID: T1059.005
+** Reference URL: https://attack.mitre.org/techniques/T1059/005/
+* 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: System Binary Proxy Execution
+** ID: T1218
+** Reference URL: https://attack.mitre.org/techniques/T1218/
+* Sub-technique:
+** Name: Mshta
+** ID: T1218.005
+** Reference URL: https://attack.mitre.org/techniques/T1218/005/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-conhost-spawned-by-suspicious-parent-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-conhost-spawned-by-suspicious-parent-process.asciidoc
new file mode 100644
index 0000000000..8ba85a1200
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-conhost-spawned-by-suspicious-parent-process.asciidoc
@@ -0,0 +1,181 @@
+[[prebuilt-rule-8-19-24-conhost-spawned-by-suspicious-parent-process]]
+=== Conhost Spawned By Suspicious Parent Process
+
+Detects when the Console Window Host (conhost.exe) process is spawned by a suspicious parent process, which could be indicative of code injection.
+
+*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*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://cloud.google.com/blog/topics/threat-intelligence/monitoring-windows-console-activity-part-one
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Execution
+* Resources: Investigation Guide
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Microsoft Defender XDR
+* Data Source: SentinelOne
+
+*Version*: 314
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Conhost Spawned By Suspicious Parent Process*
+
+
+
+*Possible investigation steps*
+
+
+- Is the alerting "conhost.exe" the native console host, and which parent requested the console?
+  - Why: Windows creates "conhost.exe" for console clients; service, COM, logon, or shell parents rarely need direct console allocation.
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.parent.executable`, and `process.parent.command_line`.
+  - Implication: escalate if "conhost.exe" is renamed, outside the Windows directory, mismatched to its PE name, not Microsoft-signed, or if parent path and command line contradict its name; lower only when native child and parent identity fit one exact MSI, compatibility, or WebDAV helper action explaining direct parentage.
+
+- Does the parent identity, lineage, and session fit a legitimate console allocation path?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.code_signature.subject_name`, `process.Ext.ancestry`, and `process.Ext.session_info.logon_type`.
+  - Implication: escalate when system/logon, COM/LOLBin, or shell/input parents run from unexpected paths, have unfamiliar signers, appear in unexpected ancestry, or allocate a console in a mismatched session; lower when signed parent command line and session fit one bounded MSI custom action, Program Compatibility Assistant, or WebDAV workflow.
+
+- Did the same parent launch a shell, script host, LOLBin, or payload around the alert?
+  - Focus: same-host child process events by `process.parent.entity_id`; if absent, use `host.id`, `process.parent.pid`, and a tight alert-time window, then read child `process.executable`, `process.command_line`, and signer. !{investigate{"description":"","label":"Process starts from the same suspicious parent","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if clean but parent identity remains suspicious, check for pre-existing console or shell processes in the same `host.id` and session before closure.
+  - Implication: escalate when the parent starts shells, script hosts, downloaders, task/service tools, or unsigned payloads; lower only when "conhost.exe" is the lone unusual child and earlier evidence proves an exact bounded parent workflow, but do not close on this alone because attackers can reuse an existing console or shell.
+
+- If file or registry telemetry is available, did the same parent stage artifacts or change configuration?
+  - Focus: match parent `process.parent.entity_id` to actor `process.entity_id` on `host.id`; if absent, match parent/actor PID in a tight alert window, then read `file.path`. !{investigate{"description":"","label":"File events from the same suspicious parent","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: use the same joins for `registry.path`. !{investigate{"description":"","label":"Registry events from the same suspicious parent","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} Missing file or registry telemetry is unresolved, not benign.
+  - Implication: escalate when the parent writes executables or scripts, stages console clients, or changes persistence or security configuration; absent optional artifacts lower corroboration only and do not close.
+
+- If DNS or network telemetry is available, did the same parent contact staging, remote-control, or lateral destinations?
+  - Focus: match parent `process.parent.entity_id` to actor `process.entity_id` on `host.id`; if absent, match parent/actor PID in a tight alert window, then read DNS "lookup_result" events (`dns.question.name`, `dns.resolved_ip`) separately from connections (`destination.ip`). !{investigate{"description":"","label":"Network events from the same suspicious parent","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: missing DNS or network telemetry is unresolved, not benign; correlate `dns.resolved_ip` to `destination.ip` before treating a domain as contacted.
+  - Implication: escalate when the parent reaches public or internal destinations unrelated to the workflow, WebDAV/SMB destinations, or unexpected internal systems; lower only when destinations fit the same MSI, Program Compatibility Assistant, or WebDAV workflow proven by process evidence.
+
+- If the parent path, child execution, artifacts, or destinations remain suspicious or unexplained, do related alerts change scope or urgency?
+  - Focus: recent `host.id` alerts, especially process injection, indirect execution, suspicious shell, credential, or C2 activity. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: review the same `user.id` only when the local evidence suggests the operator or session may have moved to other systems. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same host or user has related injection, shell, credential, or C2 alerts; keep the case local when isolated and earlier process evidence fits one exact recognized workflow.
+
+- Escalate for masqueraded parent, unexpected ancestry, unexplained console allocation, suspicious follow-on execution, staging, or remote-control corroboration; close only when native "conhost.exe" identity, parent identity/lineage, session, child processes, optional artifact or destination evidence, and related alerts align with one recognized installer, compatibility, or WebDAV workflow with no contradictions; if mixed or incomplete, preserve evidence and escalate.
+
+
+*False positive analysis*
+
+
+- Installer repair, MSI custom actions, Program Compatibility Assistant activity, and WebDAV helpers can allocate "conhost.exe" from signed parents. Confirm parent path/command/signer, `process.executable`, `user.id`, and `host.id` describe one exact workflow, same-parent children show no shells, script hosts, LOLBins, or payloads, and optional file, registry, DNS, or network telemetry does not contradict it. Use change records, inventories, or owner confirmation only after telemetry fits.
+- Without organizational context, telemetry-only confirmation must prove the current event fits that workflow. Historical alerts corroborate only when the same parent path, signer, command line, child, user/host, and bounded child pattern recur without contradictions; do not close on recurrence while parentage or follow-on execution remains unexplained.
+- Before an exception, validate the minimum stable pattern: parent executable, command line, signer, child executable, `user.id`, and `host.id`. Avoid exceptions on "conhost.exe", parent name, or broad signers alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment, document native child identity, parent path/signer/command, session, `user.id`, `host.id`, and corroboration, and create exceptions only for the recurring minimum pattern above.
+- If suspicious but unconfirmed, preserve the alert export, parent/child timeline, entity IDs, command lines, artifact/destination indicators, and owner/change evidence before containment. Apply reversible controls first: temporary destination blocking or heightened `host.id` / `user.id` monitoring; disable a task, service, or startup item only after identifying it as malicious. Escalate to isolation or account action only when follow-on execution, persistence, remote control, or credential abuse is confirmed and the asset can tolerate interruption.
+- If confirmed malicious, isolate the host when unauthorized parent execution, payload launch, persistence, or remote control is confirmed, after weighing host role. Record parent/payload process IDs and command lines before suspending or terminating processes, then block confirmed malicious destinations, hashes, or domains.
+- Eradicate only malicious parent/payload artifacts and configuration changes. Review other hosts/users for the same parent path, command line, child executable, artifact, or destination before deleting payloads, removing persistence, restoring settings, or closing the execution vector.
+- Post-incident hardening: tighten the exposed MSI, Program Compatibility Assistant, or WebDAV workflow, and record variants such as existing-console reuse, injected "explorer.exe", or service-host console abuse.
+
+
+==== 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.name : "conhost.exe" and
+  process.parent.name : ("lsass.exe", "services.exe", "smss.exe", "winlogon.exe", "explorer.exe", "dllhost.exe", "rundll32.exe",
+                         "regsvr32.exe", "userinit.exe", "wininit.exe", "spoolsv.exe", "ctfmon.exe") and
+  not (process.parent.name : "rundll32.exe" and
+       process.parent.args : ("?:\\Windows\\Installer\\MSI*.tmp,zzzzInvokeManagedCustomActionOutOfProc",
+                              "?:\\WINDOWS\\system32\\PcaSvc.dll,PcaPatchSdbTask",
+                              "?:\\WINDOWS\\system32\\davclnt.dll,DavSetCookie"))
+
+----------------------------------
+
+*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/
+* 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/
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Process Injection
+** ID: T1055
+** Reference URL: https://attack.mitre.org/techniques/T1055/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-container-runtime-cli-execution-with-suspicious-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-container-runtime-cli-execution-with-suspicious-arguments.asciidoc
new file mode 100644
index 0000000000..1e8dc1cfc4
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-container-runtime-cli-execution-with-suspicious-arguments.asciidoc
@@ -0,0 +1,140 @@
+[[prebuilt-rule-8-19-24-container-runtime-cli-execution-with-suspicious-arguments]]
+=== Container Runtime CLI Execution with Suspicious Arguments
+
+Detects execution of container runtime CLI tools (ctr, crictl, nerdctl) with arguments indicating container creation, command execution inside existing containers, image manipulation, or host filesystem mounting. These tools interact directly with the container runtime socket, bypassing the Kubernetes API server, RBAC authorization, admission webhooks, pod security standards, and Kubernetes audit logging entirely. Attackers with host-level access may use these tools to create privileged ghost containers, exec into other pods to steal service account tokens and secrets, pull attacker-controlled images, and destroy evidence, all while remaining invisible to Kubernetes-level monitoring.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* auditbeat-*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1609/
+* https://book.hacktricks.xyz/linux-hardening/privilege-escalation/containerd-ctr-privilege-escalation
+
+*Tags*: 
+
+* Data Source: Auditd Manager
+* Data Source: Elastic Defend
+* Domain: Container
+* Domain: Endpoint
+* OS: Linux
+* 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 Container Runtime CLI Execution with Suspicious Arguments*
+
+
+Review the full argv list and working directory. Confirm whether the session is interactive, whether the image or bundle
+referenced is trusted, and whether bind mounts or privileged flags target host paths such as `/`, `/etc`, or Docker
+sockets.
+
+
+*Possible investigation steps*
+
+
+- Reconstruct the container ID or snapshot key passed to `tasks`, `snapshots`, or `content` subcommands.
+- Correlate with file, network, and Kubernetes audit activity for pulls from unusual registries or subsequent pod
+  changes.
+- Check whether the parent should legitimately be kubelet, containerd, or systemd on that host class.
+
+
+*Response and remediation*
+
+
+- If unauthorized, isolate the node, revoke credentials available to the session, and hunt for new privileged
+  workloads or image imports.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Requires process execution telemetry with arguments from **Elastic Defend** (`logs-endpoint.events.process*`) and/or
+**Auditd Manager** / Auditbeat (`logs-auditd_manager.auditd-*`, `auditbeat-*`).
+
+Ensure exec-related auditing captures full argv for `ctr`, `crictl`, and `nerdctl`. See
+https://docs.elastic.co/integrations/auditd_manager
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "executed") and
+(
+  (
+    process.name in ("ctr", "crictl", "nerdctl") and
+    (
+      (process.args == "tasks" and process.args == "exec") or
+      (process.args == "run" and process.args in ("--privileged", "--rm", "--mount", "--net-host", "--pid-host")) or
+      (process.args == "snapshots" and process.args == "mount")
+    )
+  ) or
+  (
+    (process.executable like ("/dev/shm/*", "/tmp/*", "/var/tmp/*") or process.name : ".*") and
+    process.args like ("*containerd.sock*", "k8s.io")
+  )
+) and
+not process.parent.executable in (
+  "/usr/bin/kubelet", "/usr/local/bin/kubelet",
+  "/usr/bin/containerd", "/usr/sbin/containerd",
+  "/lib/systemd/systemd", "/usr/lib/systemd/systemd", "/sbin/init"
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Container Administration Command
+** ID: T1609
+** Reference URL: https://attack.mitre.org/techniques/T1609/
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Escape to Host
+** ID: T1611
+** Reference URL: https://attack.mitre.org/techniques/T1611/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-creation-of-a-hidden-local-user-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-creation-of-a-hidden-local-user-account.asciidoc
new file mode 100644
index 0000000000..819a88ce5d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-creation-of-a-hidden-local-user-account.asciidoc
@@ -0,0 +1,181 @@
+[[prebuilt-rule-8-19-24-creation-of-a-hidden-local-user-account]]
+=== Creation of a Hidden Local User Account
+
+Identifies the creation of a hidden local user account by appending the dollar sign to the account name. This is sometimes done by attackers to increase access to a system and avoid appearing in the results of accounts listing using the net users command.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-endpoint.events.registry-*
+* logs-windows.sysmon_operational-*
+* endgame-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-crowdstrike.fdr*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* http://web.archive.org/web/20230329153858/https://blog.menasec.net/2019/02/threat-hunting-6-hiding-in-plain-sights_8.html
+* https://github.com/CyberMonitor/APT_CyberCriminal_Campagin_Collections/tree/master/2020/2020.12.15.Lazarus_Campaign
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Resources: Investigation Guide
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Microsoft Defender XDR
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+
+*Version*: 317
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Creation of a Hidden Local User Account*
+
+
+
+*Possible investigation steps*
+
+
+- What hidden local account did the SAM write create?
+  - Why: a `$` suffix is ambiguous in many logs, but `registry.path` under `SAM\SAM\Domains\Account\Users\Names` is a local account-name entry and can be omitted from casual `net user` review.
+  - Focus: `registry.hive`, `registry.path`, `registry.key`, and `@timestamp` for the exact account name and creation time.
+  - Implication: high concern unless the exact `$`-suffixed account, `host.id`, and time fit one narrowly recognized provisioning or recovery workflow; lower concern only when creator, use, and scope checks do not contradict it.
+
+- Which process and parent caused the SAM entry?
+  - Focus: `process.entity_id`, `process.executable`, `process.command_line`, `process.parent.executable`, and `process.parent.command_line`.
+  - Implication: escalate for shells, script interpreters, remote-service launchers such as sc.exe, service-created cmd/net user chains, PsExec-like tools, user-writable binaries, or mismatched parents; lower concern only when creator path, parent, and arguments match one recognized account-management workflow.
+
+- Did the creator or its children perform other account, privilege, or persistence actions?
+  - Why: remote account creation can surface as a service-launched command, and the decisive `net user`, local-group, or cleanup action may be in the creator's process tree rather than the registry event alone.
+  - Focus: same-host registry and process activity for creator `process.entity_id` and child `process.parent.entity_id`: `process.command_line`, `registry.path`, `registry.value`, and `registry.data.strings`. !{investigate{"description":"","label":"Creator process and child activity on this host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"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"},{"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":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Hint: if the parent is service-control or PsExec-like, keep service-created cmd/net user children in scope even when signed.
+  - Implication: escalate when the tree adds local-group membership, touches extra SAM or LSA paths, deletes staging commands, or creates other persistence; lower concern when activity stays limited to the recovered account inside the same recognized workflow.
+
+- Was the hidden account used by later process activity after creation?
+  - Why: remote or service use of `$`-suffixed accounts may leave little profile evidence, so process and session context carries more weight than profile artifacts.
+  - Focus: extract the account leaf from `registry.path`, then search same-host process starts after `@timestamp` where `user.name` matches it, reading `process.Ext.session_info.logon_type`, `process.executable`, and `process.command_line`.
+  - Hint: this pivot is manual unless the account name is normalized into a standalone alert field; avoid using the full SAM registry path as an account value.
+  - Implication: account use after creation strongly escalates when the account runs processes, appears in remote-interactive, network, service, or batch sessions, or launches administrative tooling; lower concern only when no process use appears and creator evidence fits a recognized provisioning path.
+
+- If local evidence is suspicious or unresolved, do recent same-actor or same-host alerts change scope?
+  - Focus: related alerts for creating `user.id` and `host.id`: account abuse, privilege escalation, remote execution, credential access, or additional persistence.
+  - Hint: use the creating-identity alert pivot. !{investigate{"description":"","label":"Alerts associated with the creating identity","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: use the host alert pivot. !{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 response when the same actor or host has related account, persistence, or privilege alerts; keep local when history is clean and local evidence already fits one recognized workflow.
+
+- What disposition is supported?
+  - Escalate for unexpected account or creator lineage, privilege or cleanup activity, later account use, or wider scope; close only when same-host telemetry proves one exact recognized workflow, using records only as corroboration; preserve evidence and escalate when answers stay mixed or incomplete.
+
+
+*False positive analysis*
+
+
+- A pre-established local support-account provisioning or recovery workflow can create a `$`-suffixed local account, but close only on a complete telemetry match: exact `registry.path`, creator `process.executable`, `process.command_line`, parent process, `user.id`, and `host.id`, with no extra SAM, LSA, privilege-grant, or cleanup activity outside it. Use build, vendor, or maintenance records only to corroborate that match; never close or exception on records alone.
+- Treat one-off interactive creation, remote service-created cmd.exe or net.exe, script-driven creation, and creation on ordinary workstations or servers as suspicious by default. Hidden support accounts elsewhere or a signed creator binary are not enough to close.
+- Build exceptions only from the minimum confirmed workflow: exact hidden-account `registry.path`, stable creator executable and command pattern, parent workflow, `user.id`, and bounded `host.id` cohort. Avoid exceptions on all `$`-suffixed names, the SAM hive, `process.name` alone, or the rule name.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and record the exact account path, creator lineage, user, and host cohort that proved the recurring workflow. Keep any exception as narrow as that confirmed pattern.
+- If suspicious but unconfirmed, export the alert, the triggering registry event, creator process details, current hidden-account state, privilege evidence found in process or registry review, and any process or session use by the hidden account before containment. Apply reversible actions first: disable the account, restrict its logon rights, or increase monitoring on the affected `host.id` and creating `user.id`; avoid deleting the account until evidence is preserved.
+- If confirmed malicious, preserve account state, creator process lineage, and related registry or process artifacts first. Then isolate the host when its role allows, disable the hidden account, and contain the creating identity or remote source when the evidence identifies one. After preservation and containment, remove unauthorized privilege, SAM, LSA, service, or scheduled-task changes introduced around the same time.
+- Post-incident hardening: restrict hidden support-account creation to controlled management tooling, audit the host for other local accounts ending in `$`, retain registry and process telemetry needed to reconstruct future account creation, and document blind spots around preexisting hidden accounts or later privilege grants.
+
+
+==== 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-reg-setup[Sysmon Registry Events]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+registry where host.os.type == "windows" and event.type in ("change", "creation") and
+  registry.path : (
+    "HKLM\\SAM\\SAM\\Domains\\Account\\Users\\Names\\*$\\",
+    "\\REGISTRY\\MACHINE\\SAM\\SAM\\Domains\\Account\\Users\\Names\\*$\\",
+    "MACHINE\\SAM\\SAM\\Domains\\Account\\Users\\Names\\*$\\"
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Create Account
+** ID: T1136
+** Reference URL: https://attack.mitre.org/techniques/T1136/
+* Sub-technique:
+** Name: Local Account
+** ID: T1136.001
+** Reference URL: https://attack.mitre.org/techniques/T1136/001/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Hide Artifacts
+** ID: T1564
+** Reference URL: https://attack.mitre.org/techniques/T1564/
+* Sub-technique:
+** Name: Hidden Users
+** ID: T1564.002
+** Reference URL: https://attack.mitre.org/techniques/T1564/002/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-curl-or-wget-execution-from-container-context.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-curl-or-wget-execution-from-container-context.asciidoc
new file mode 100644
index 0000000000..8444e4ce18
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-curl-or-wget-execution-from-container-context.asciidoc
@@ -0,0 +1,148 @@
+[[prebuilt-rule-8-19-24-curl-or-wget-execution-from-container-context]]
+=== Curl or Wget Execution from Container Context
+
+Detects execution of curl or wget from processes whose title aligns with **`runc init`**, a common fingerprint for workloads running inside **OCI/runc-backed containers** on Linux hosts instrumented with Auditd Manager. After breaking out of an application container or abusing a privileged workload, attackers often pull ingress tooling (stagers, scripts, implants) or stage exfiltration with minimal HTTP clients. Those utilities are also used benignly in images, so context matters; the `runc init` anchor narrows the signal to the container runtime boundary where unexpected download clients are more worthy of review than the same binaries on a bare-metal admin shell.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* 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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1105/
+* https://gtfobins.github.io/gtfobins/curl/
+* https://gtfobins.github.io/gtfobins/wget/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Command and Control
+* Tactic: Execution
+* Domain: Containers
+* Data Source: Auditd Manager
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Curl or Wget Execution from Container Context*
+
+
+The rule matches Auditd-backed process events where `process.title` is `runc init` and the executed program is
+curl/wget (by `process.name`) or the argument vector suggests curl or wget paths. Use it to spot ingress tool 
+transfer or scripted downloads from inside a container as seen at the host audit layer.
+
+
+*Possible investigation steps*
+
+
+- Reconstruct the full command line from `process.args` / `process.command_line` and identify URLs, output paths, and
+  flags such as `-O`, `--post-file`, or TLS bypass (`-k`).
+- Map the event to the container: cgroup, `container.id`, `kubernetes.pod.*`, or runtime metadata if present on the
+  document; identify the image, namespace, and workload owner.
+- Review egress from the host or pod network policy logs for destinations contacted shortly after the execution.
+- Compare against recent image or manifest changes for the workload to rule out intentional startup scripts.
+
+
+*False positive analysis*
+
+
+- Package managers and bootstrap scripts in official images may run curl/wget once at start; document and exclude when
+  verified.
+- Security scanners or health checks running in sidecars could match; validate agent type and schedule.
+
+
+*Response and remediation*
+
+
+- If unauthorized, isolate the node or workload, revoke credentials available to the container, inspect for dropped
+  binaries or cron/systemd additions, and rotate any secrets the container could reach.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data from **Auditd Manager** (or legacy Auditbeat shipping comparable ECS fields).
+
+
+*Auditd Manager Integration Setup*
+
+The Auditd Manager integration receives audit events from the Linux Audit Framework. With `auditd_manager`,
+administrators can define audit rules, track system events, and generate reports.
+
+
+*Steps to deploy Auditd Manager*
+
+- In Kibana, open **Add integrations**, search for **Auditd Manager**, and add it to an agent policy deployed on Linux
+  hosts that should emit syscall audit data.
+- For integration details, see the https://docs.elastic.co/integrations/auditd_manager[Auditd Manager documentation].
+
+
+*Rule-specific notes*
+
+- Ensure syscall coverage includes **execve** (or equivalent) for processes inside containers so `curl`, `wget`, and
+  argument lists are captured on the host.
+- Confirm that **`process.title`** (or the mapped proctitle field) reflects **`runc init`** for your runtime; other
+  runtimes may use different titles—tune the predicate if you standardize on `crun`, `containerd-shim`, etc.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+host.os.type:linux and 
+data_stream.dataset:"auditd_manager.auditd" and
+event.action:("executed" or "exec") and
+process.title:"runc init" and
+(
+  process.name:(curl or wget) or
+  process.args:(* curl* or */bin/curl* or *wget*)
+) and 
+not process.args :(*127.0.0.1* or *localhost* or "wget --no-verbose --tries=1 --spider --no-check-certificate http://${WEB_HOST}:${WEB_PORT}/api/ping || exit 1")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Command and Control
+** ID: TA0011
+** Reference URL: https://attack.mitre.org/tactics/TA0011/
+* Technique:
+** Name: Ingress Tool Transfer
+** ID: T1105
+** Reference URL: https://attack.mitre.org/techniques/T1105/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc
new file mode 100644
index 0000000000..f436b1d1a9
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc
@@ -0,0 +1,145 @@
+[[prebuilt-rule-8-19-24-delegated-managed-service-account-modification-by-an-unusual-user]]
+=== Delegated Managed Service Account Modification by an Unusual User
+
+Detects modifications to the msDS-ManagedAccountPrecededByLink attribute of a delegated managed service account by an unusual subject account. Attackers can abuse this attribute to inherit a target account's permissions and further elevate privileges.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-system.security*
+* logs-windows.forwarded*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Use Case: Active Directory Monitoring
+* Data Source: Active Directory
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 4
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Delegated Managed Service Account Modification by an Unusual User*
+
+
+
+*Possible investigation steps*
+
+
+- What dMSA link did the alert record?
+  - Focus: confirm 5136 with `winlog.event_data.AttributeLDAPDisplayName` "msDS-ManagedAccountPrecededByLink"; read `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectClass`, `winlog.event_data.AttributeValue`, and `winlog.event_data.OperationType` for dMSA, superseded account DN, and change type.
+  - Implication: escalate when the link targets a privileged, sync, backup, or widely trusted service account, or the modified object is unexpected; lower suspicion only when object, link, and change type fit one low-impact migration pair.
+- Did the controller operation look like bounded dMSA migration or direct link write?
+  - Why: real migration should not be a lone sensitive attribute write; BadSuccessor risk rises when the link is isolated or paired with unrelated high-impact changes.
+  - Focus: review same-controller 5136 changes by `winlog.event_data.OpCorrelationID`; compare `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.OperationType`, and `winlog.event_data.AttributeValue`. !{investigate{"description":"","label":"Directory changes for the same operation on this controller","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.OpCorrelationID","queryType":"phrase","value":"{{winlog.event_data.OpCorrelationID}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if the operation ID is incomplete, query 5136 on `host.id` plus `winlog.event_data.SubjectLogonId` for same-session dMSA or privileged-object changes.
+  - Implication: escalate on standalone link write, unexpected value replacement, or unrelated ACL, delegation, SPN, or service-account changes; lower suspicion when same-operation or same-session changes stay bounded to one expected migration pair.
+- Who wrote the link, and does the identity fit dMSA management?
+  - Focus: use `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, `winlog.event_data.SubjectLogonId`, and `winlog.computer_name` to identify writer, controller session, and service vs human.
+  - Implication: escalate when the writer is an unfamiliar human, helpdesk account, or low-privilege service identity for dMSA management; keep unresolved when a recognized writer is not tied to the exact dMSA pair.
+- Did the writer session originate from an expected source and logon type?
+  - Focus: pivot from `winlog.event_data.SubjectLogonId` and `host.id` to authentication where `winlog.event_data.TargetLogonId` matches; review `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Authentication events for the writer session on this controller","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: search 4648 on `winlog.event_data.SubjectLogonId` for explicit-credential use; missing authentication records or `source.ip` are unresolved, not benign.
+  - Implication: escalate when the session starts from an unexpected host, uses unusual interactive/RDP logon, or shows explicit-credential behavior outside the writer's role; expected source and logon type support closure only after link target and operation cohere.
+- Did the linked dMSA or superseded account authenticate from unexpected systems after the change?
+  - Why: risk peaks when the new dMSA relationship is exercised from hosts that should not use the inherited service account.
+  - Focus: derive dMSA and superseded account names from `winlog.event_data.ObjectDN` and `winlog.event_data.AttributeValue`, then review authentication by `winlog.event_data.TargetUserName`, `source.ip`, and `winlog.logon.type`.
+  - Hint: missing authentication telemetry is unresolved, not benign; an unused link still needs disposition from link target, writer, and sequence.
+  - Implication: escalate when either account authenticates from a new host, admin workstation, or service path after the change; unchanged or absent use does not clear suspicion.
+- If still suspicious or unresolved, do recent writer or dMSA alerts show broader abuse?
+  - Focus: review recent alerts for modifying `user.id`, then modified `winlog.event_data.ObjectGUID`. !{investigate{"description":"","label":"Alerts associated with the source account","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}],[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: use object alerts for shadow credentials, delegation abuse, unusual service changes, or other AD tampering tied to the dMSA. !{investigate{"description":"","label":"Alerts associated with the modified dMSA object","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate and widen scope when either alert set shows privilege abuse, directory tampering, or suspicious authentication; keep scope local when both are quiet and local evidence is the only unresolved signal.
+- What disposition fits?
+  - Weigh link target, operation, writer/session, follow-on use, and related alerts: escalate on high-value link, incoherent operation, unexpected writer/session, new use, or AD abuse; close only when all evidence proves one exact migration; mixed/incomplete evidence -> preserve directory-change and session records, then escalate.
+
+
+*False positive analysis*
+
+
+- Planned dMSA migration by identity/service-account admins may set "msDS-ManagedAccountPrecededByLink". Confirm `winlog.event_data.ObjectDN`, planned `winlog.event_data.AttributeValue`, paired `winlog.event_data.OpCorrelationID`, `winlog.event_data.SubjectUserSid`, recovered `source.ip`, and `winlog.logon.type` match migration account/host path. Telemetry-only closure requires anchors proving one bounded migration; otherwise require records, tickets, or identity-admin confirmation for the exact dMSA pair and writer. Do not close from recurrence or role assumptions.
+- Lab validation or staged service-account modernization may trigger. Confirm `winlog.event_data.ObjectDN` and `winlog.event_data.AttributeValue` stay in the authorized test/staging OU, session avoids unrelated privileged objects, and follow-on `winlog.event_data.TargetUserName` or `source.ip` is limited to test hosts. Telemetry-only closure requires test OU, writer, bounded change set, and follow-on hosts proving lab scope; otherwise require test records or lab owner confirmation.
+- Before exception, confirm the exact workflow: `winlog.event_data.SubjectUserSid`, `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeValue`, bounded `winlog.event_data.OpCorrelationID`, and recovered controller or source path. Use exceptions only when that verified workflow should repeat; avoid exceptions on the attribute, 5136, or all dMSA changes.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse containment and record: writer SID, dMSA DN, superseded account DN, bounded sequence, recovered source path, and external confirmation for the change. Create an exception only when that workflow should repeat.
+- If suspicious but unconfirmed, export the triggering 5136 record, same-operation change sequence, writer-session auth records, explicit-credential evidence, and related alerts before destructive changes. Apply reversible containment first: restrict the recovered source host from domain controllers or monitor the writer, modified dMSA, and superseded account. Disable the writer or isolate the source host only if additional privileged changes, unexpected follow-on authentication, or related alerts appear.
+- If confirmed malicious, preserve directory-change and session evidence first, then use endpoint response to isolate the recovered source host and disable/reset the malicious dMSA, compromised writer, and affected superseded service account. If endpoint response is unavailable on the source system, escalate with preserved `source.ip`, `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectLogonId`, `winlog.event_data.ObjectGUID`, and related 5136, 4624, or 4648 evidence to responders. Review hosts/services that used the same superseded account or new dMSA before cleanup, verify rollback replication across domain controllers, and only then remove the unauthorized `winlog.event_data.AttributeValue` link, roll back related migration/SPN/delegation changes in the same `winlog.event_data.OpCorrelationID` sequence, and rotate affected secrets or restore service bindings.
+- Post-incident hardening: restrict dMSA creation/migration rights, verify domain-controller retention for 5136, 4624, and 4648, and record the migration workflow or BadSuccessor evidence for reuse.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Audit Directory Service Changes must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-directory-service-changes
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.code:5136 and host.os.type:"windows" and winlog.event_data.AttributeLDAPDisplayName:"msDS-ManagedAccountPrecededByLink"
+
+----------------------------------
+
+*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: Domain Accounts
+** ID: T1078.002
+** Reference URL: https://attack.mitre.org/techniques/T1078/002/
+* 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-24/prebuilt-rule-8-19-24-dmsa-account-creation-by-an-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-dmsa-account-creation-by-an-unusual-user.asciidoc
new file mode 100644
index 0000000000..d6af726c03
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-dmsa-account-creation-by-an-unusual-user.asciidoc
@@ -0,0 +1,156 @@
+[[prebuilt-rule-8-19-24-dmsa-account-creation-by-an-unusual-user]]
+=== dMSA Account Creation by an Unusual User
+
+Detects creation of a delegated Managed Service Account by an unusual subject account. Attackers can abuse weak child-object or msDS-DelegatedManagedServiceAccount rights during account migration to elevate privileges.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-system.security*
+* logs-windows.forwarded*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Use Case: Active Directory Monitoring
+* Data Source: Active Directory
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 5
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating dMSA Account Creation by an Unusual User*
+
+
+
+*Possible investigation steps*
+
+
+- What dMSA object did the alert show, and where was it created?
+  - Focus: use `winlog.event_data.ObjectClass`, `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.SubjectUserName`, and `winlog.computer_name` to identify the new msDS-DelegatedManagedServiceAccount, new-to-this-rule writer, and controller.
+  - Implication: escalate when the object is in a privileged service, sync, backup, DC, or identity-infrastructure path, or when name or writer lacks a narrow service-account purpose; lower only when DN, writer, and controller match one exact planned dMSA rollout or lab path.
+- Did the same dMSA receive migration or privilege-enabling attributes?
+  - Why: BadSuccessor-style abuse elevates creation with `5136` changes such as msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState, SPNs, delegation attributes, or gMSA membership.
+  - Focus: review same-object `5136` and `5137` records on this controller with `winlog.event_data.ObjectGUID`, comparing `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.AttributeValue`, and `winlog.event_data.ObjectDN`. !{investigate{"description":"","label":"Directory changes for the same dMSA object on this controller","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5137","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if same-controller results have gaps, repeat the `winlog.event_data.ObjectGUID` search across DC Windows Security logs before treating missing follow-on changes as lower risk.
+  - Implication: escalate when values link the dMSA to a privileged predecessor, advance migration state, or add SPN/delegation material; lower suspicion only when attributes form one bounded migration to the intended legacy service account.
+- Who created the dMSA, and what session reached the domain controller?
+  - Focus: identify writer and session with `winlog.event_data.SubjectUserSid` and `winlog.event_data.SubjectLogonId`, then recover `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Authentication events for the writer session on this controller","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: this pivot uses `winlog.event_data.TargetLogonId` for `4624` or `4634`; search `4648` separately with `winlog.event_data.SubjectLogonId` when explicit-credential use matters. Missing authentication telemetry is unresolved, not benign.
+  - Implication: escalate for an unexpected human, helpdesk account, low-privilege service identity, unusual source, interactive/RDP session, or explicit-credential path; lower suspicion only when actor and source match the narrow identity-management path for this object.
+- Did the same session touch other directory objects?
+  - Focus: compare surrounding `5137` and `5136` records on the same `host.id` for `winlog.event_data.SubjectLogonId`, reading `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectClass`, and `winlog.event_data.AttributeLDAPDisplayName`.
+  - Implication: escalate when the session creates multiple dMSAs, edits ACLs, changes delegation, or touches unrelated privileged users, computers, groups, or service accounts; lower when every change stays tied to one bounded dMSA rollout.
+- Did the new dMSA get used from systems that should not touch it?
+  - Focus: derive the dMSA from the CN in `winlog.event_data.ObjectDN`, confirm it in `winlog.event_data.TargetUserName`, then review `4624` records for `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`; search `4648` separately for explicit credential use.
+  - Hint: absent dMSA authentication is a timing or visibility gap, not proof creation is harmless.
+  - Implication: escalate when the dMSA authenticates from unexpected servers, workstations, jump hosts, or non-service logon types; lower suspicion only when use stays inside the exact service host set for the confirmed rollout.
+- If local evidence is suspicious or incomplete, do related Windows Security events show broader AD abuse?
+  - Focus: review events for writer `user.id`, then compare records referencing the new `winlog.event_data.ObjectGUID`. !{investigate{"description":"","label":"Windows Security events associated with the modifying account","providers":[[{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}],[{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: use the object-event view for shadow credentials, delegation abuse, unusual service changes, or other AD tampering tied to the same dMSA. !{investigate{"description":"","label":"Windows Security events associated with the new dMSA object","providers":[[{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate and expand scope when either entity is tied to privilege abuse, directory tampering, or suspicious authentication; keep scope to this object when related events are quiet, but do not close solely because no other event exists.
+- Escalate for sensitive placement, privileged migration links, unexpected writer/session context, broader directory edits, unexpected dMSA authentication, or related AD-abuse events; close only when telemetry and outside confirmation prove one exact planned migration or lab activity; if mixed or incomplete, preserve directory-change and session evidence and escalate.
+
+
+*False positive analysis*
+
+
+- Planned dMSA rollout or service-account migration can legitimately create msDS-DelegatedManagedServiceAccount objects. Confirm expected `winlog.event_data.ObjectDN`, same-object `5136` attributes limited to the intended legacy service account, and `winlog.event_data.SubjectUserSid`, recovered `source.ip`, and `winlog.logon.type` matching the narrow migration account and host path. If change records, migration tickets, or owner confirmation are unavailable, leave unresolved unless telemetry proves the exact authorized workflow.
+- Lab validation or staged service-account modernization can also trigger this rule. Confirm `winlog.event_data.ObjectDN` stays in the test/staging OU, the same `winlog.event_data.SubjectLogonId` avoids unrelated privileged objects, and any `winlog.event_data.TargetUserName`, `source.ip`, or `winlog.logon.type` activity stays limited to designated test systems. If test scope lacks outside confirmation, treat the alert as unresolved.
+- Before creating an exception, validate exact writer `winlog.event_data.SubjectUserSid`, dMSA path pattern, bounded same-object `5136` attributes, controller path, and recovered source. Use a temporary or tightly scoped exception for one-time migrations, and avoid exceptions on event `5137`, all msDS-DelegatedManagedServiceAccount objects, or all dMSA creation activity.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse any temporary containment and document the evidence that proved the authorized workflow: `winlog.event_data.SubjectUserSid`, `winlog.event_data.ObjectDN`, same-object `5136` sequence, recovered `source.ip`, `winlog.logon.type`, and exact rollout or lab scope.
+- If suspicious but unconfirmed, preserve a case export with the triggering `5137`, related same-object `5136` records, recovered `4624` or `4648` records, and key object/session identifiers before containment. Apply reversible containment first, such as temporary DC access restrictions for the recovered source or heightened monitoring on the writer and dMSA. Disable the writer or isolate the source host only if privileged follow-on changes, unexpected authentication, or related events appear.
+- If confirmed malicious, preserve the same directory-change and session evidence first, then remove the unauthorized dMSA and roll back related msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState, SPN, delegation, or membership changes found in the same-object sequence. Isolate the recovered source host when endpoint response is available and host criticality permits, then disable or reset the compromised writer and any linked service accounts.
+- Before deleting objects or closing the case, review hosts and services that used the new dMSA, verify rollback replication across domain controllers, then rotate affected secrets or restore service bindings.
+- Post-incident hardening: restrict who can create dMSAs or start service-account migration, review CreateChild and delegated managed service account rights on service-account OUs, retain `5136`, `5137`, `4624`, and `4648` coverage on domain controllers, and record the confirmed workflow or BadSuccessor evidence pattern for future triage.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Audit Directory Service Changes must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-directory-service-changes
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.code:5137 and host.os.type:"windows" and winlog.event_data.ObjectClass:"msDS-DelegatedManagedServiceAccount"
+
+----------------------------------
+
+*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: Domain Accounts
+** ID: T1078.002
+** Reference URL: https://attack.mitre.org/techniques/T1078/002/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Create Account
+** ID: T1136
+** Reference URL: https://attack.mitre.org/techniques/T1136/
+* Sub-technique:
+** Name: Domain Account
+** ID: T1136.002
+** Reference URL: https://attack.mitre.org/techniques/T1136/002/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-dns-request-for-ip-lookup-service-via-unsigned-binary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-dns-request-for-ip-lookup-service-via-unsigned-binary.asciidoc
new file mode 100644
index 0000000000..2cb96673c8
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-dns-request-for-ip-lookup-service-via-unsigned-binary.asciidoc
@@ -0,0 +1,120 @@
+[[prebuilt-rule-8-19-24-dns-request-for-ip-lookup-service-via-unsigned-binary]]
+=== DNS Request for IP Lookup Service via Unsigned Binary
+
+Detects when a DNS request is made for an IP lookup service to determine the external IP address of the system via an unsigned or untrusted binary. This is commonly used by malware for reconnaissance before establishing C2 connections.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.network-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*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
+
+*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 DNS Request for IP Lookup Service via Unsigned Binary*
+
+
+This detects an unsigned or untrusted process on macOS performing DNS lookups for common “what is my public IP” and geolocation services, a frequent reconnaissance step before external communications. It matters because malware uses the host’s external IP and region to choose C2 infrastructure, gate payload delivery, or evade sandboxing. A typical pattern is a dropped, unsigned Mach-O or script resolving api.ipify.org or ipinfo.io immediately after execution, then initiating outbound beacons.
+
+
+*Possible investigation steps*
+
+
+- Identify the initiating process and parent chain, then validate whether the binary is expected for the host/user and whether it is actually unsigned versus a transient signature collection issue.  
+- Review the same process’s near-term network activity for follow-on HTTP(S) requests to the resolved service and any subsequent connections to rare/new domains or IPs that could indicate C2 staging.  
+- Pivot from the resolved domain to other endpoints to determine prevalence and timing, then prioritize isolated single-host hits with recent first-seen binaries.  
+- Examine how the binary was introduced by correlating with recent downloads, archive mounts, installer executions, or quarantine/Gatekeeper events around the process start time.  
+- Acquire and analyze the binary (hash reputation, static strings, entitlements, persistence mechanisms, and launch agents/daemons) to confirm intent and scope of compromise.
+
+
+*False positive analysis*
+
+
+- A developer-built or locally compiled macOS utility/script (run from a user directory) performs a “what is my public IP” DNS lookup for telemetry, diagnostics, or environment detection, and is flagged because it lacks a trusted code signature.  
+- An unsigned helper binary dropped by a legitimate installer/updater workflow briefly runs during setup to validate external connectivity or geolocation by resolving an IP-lookup domain, and is detected before the binary is signed or placed in its final trusted location.
+
+
+*Response and remediation*
+
+
+- Isolate the affected macOS host from the network if the unsigned process continues to resolve IP-lookup domains (e.g., api.ipify.org, ipinfo.io) or initiates new outbound connections immediately after the lookup.  
+- Quarantine the unsigned executable and any associated scripts from disk (preserving path, hashes, and a copy for analysis) and remove its persistence artifacts such as newly created LaunchAgents/LaunchDaemons, login items, or cron entries tied to the same binary.  
+- Block the observed IP-lookup domains used by the unsigned process at DNS/web egress and add temporary deny rules for any follow-on suspicious destinations the process contacted after resolution.  
+- Reset compromised credentials and invalidate active sessions for the logged-in user if the process originated from user-writable locations (Downloads, Desktop, /tmp) or if additional discovery/collection behavior is found on the host.  
+- Reimage or restore the endpoint from a known-good state when persistence or tampering is confirmed, then verify Gatekeeper/XProtect status, re-enable security tooling, and monitor for recurrence of the same binary hash or domain pattern.  
+- Escalate to the incident response team if the unsigned binary is newly seen in the environment, appears on multiple hosts, or is followed by connections to rare domains/IPs indicative of staging or command-and-control.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+network where host.os.type == "macos" and event.action == "lookup_result" and 
+  (process.code_signature.trusted == false or process.code_signature.exists == false) and
+  dns.question.name like~ ("*ip-api.com*", "*ipwho.is*", "*checkip.dyndns.org*", "*api.ipify.org*",
+                           "*api.npoint.io*", "*whatismyip.akamai.com*", "*bot.whatismyipaddress.com*",
+                           "*ifcfg.me*", "*ifconfig.me*", "*ident.me*", "*ipof.in*", "*ip.tyk.nu*",
+                           "*ipwhois.app*", "*freeipapi.com*", "*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*", "*myip.ipip.net*", "*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*", "*inet-ip.info*", "*httpbin.org*", "*myip.opendns.com*") and
+  not process.executable like "/Users/*/Library/Developer/CoreSimulator/*"
+
+----------------------------------
+
+*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-24/prebuilt-rule-8-19-24-eks-authentication-configuration-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-eks-authentication-configuration-modified.asciidoc
new file mode 100644
index 0000000000..9be023115a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-eks-authentication-configuration-modified.asciidoc
@@ -0,0 +1,120 @@
+[[prebuilt-rule-8-19-24-eks-authentication-configuration-modified]]
+=== EKS Authentication Configuration Modified
+
+Detects modifications to the aws-auth ConfigMap in Amazon EKS clusters. The aws-auth ConfigMap maps AWS IAM roles and users to Kubernetes RBAC groups, an attacker who modifies it can grant any IAM role cluster-admin access by adding a mapping to the system:masters group. This is a well-documented persistence technique that survives pod restarts, node replacements, and RBAC changes because the authentication mapping exists outside of normal Kubernetes Role objects. Modifications to aws-auth are rare in normal operations, the ConfigMap is typically set during cluster provisioning and updated only during node group or access configuration changes.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/eks/latest/userguide/auth-configmap.html
+* https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Privilege Escalation
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating EKS Authentication Configuration Modified*
+
+
+Confirm who changed the mapping (user.name, groups, source.ip, user_agent.original) and whether the change aligns with
+approved cluster or node-group operations. Compare the new aws-auth mapRoles/mapUsers content to the prior revision if
+request/response capture is available in audit.
+
+
+*Possible investigation steps*
+
+
+- Identify any new IAM role ARNs or users bound to system:masters or other privileged Kubernetes groups.
+- Correlate the timestamp with AWS CloudTrail for related EKS or IAM API activity and with GitOps or pipeline commits.
+- Review subsequent API activity from newly mapped IAM principals for secret access, RBAC changes, or workload deployment.
+- If Access Entries are enabled, also review CloudTrail for eks:CreateAccessEntry, eks:AssociateAccessPolicy, and similar
+  API calls around the same window.
+
+
+*Response and remediation*
+
+
+- If unauthorized, revert aws-auth from a known-good backup, remove rogue map entries, and rotate or restrict IAM that
+  could have performed the change.
+- Audit IAM policies that allow eks:UpdateClusterConfig or broad ConfigMap write access to kube-system.
+- Escalate per incident policy when system:masters mappings appear from unexpected IAM identities.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"kubernetes.audit_logs" and 
+kubernetes.audit.objectRef.resource:"configmaps" and 
+kubernetes.audit.objectRef.name:"aws-auth" and 
+kubernetes.audit.verb:("update" or "patch" or "delete") and 
+kubernetes.audit.objectRef.namespace:"kube-system" and 
+kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and
+not user.name:"eks:kms-storage-migrator"
+
+----------------------------------
+
+*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 Container Cluster Roles
+** ID: T1098.006
+** Reference URL: https://attack.mitre.org/techniques/T1098/006/
+* 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc
new file mode 100644
index 0000000000..055d219fe4
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc
@@ -0,0 +1,133 @@
+[[prebuilt-rule-8-19-24-entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource]]
+=== Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource
+
+Detects successful Microsoft Entra ID sign-ins where the client application is the Microsoft Authentication Broker (MAB) and the requested resource identifier is outside a short list of commonly observed first-party targets. Attackers abuse the broker in phishing and token broker flows to obtain tokens for unexpected APIs or enterprise applications. The exclusion list covers legacy Azure Active Directory, Microsoft Graph, Device Registration Service, Microsoft Intune Enrollment, extend or tune exclusions for your tenant after baselining broker traffic.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-azure.signinlogs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://learn.microsoft.com/en-us/troubleshoot/azure/entra/entra-id/governance/verify-first-party-apps-sign-in
+* https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs
+* https://any.run/malware-trends/tycoon/
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Sign-in Logs
+* Use Case: Threat Detection
+* Tactic: Initial Access
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource*
+
+
+Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.resource_id`,
+`azure.signinlogs.properties.resource_display_name`, `azure.signinlogs.properties.session_id`, `source.ip`, and
+`user_agent.original`.
+
+Determine whether the resource is a known line-of-business application, partner integration, or Microsoft service not
+represented in the rule exclusion list.
+
+
+*Possible investigation steps*
+
+
+- Resolve `resource_id` in Entra ID enterprise applications and compare with change records or app governance inventory.
+- Correlate with `azure.signinlogs` and `azure.graphactivitylogs` for follow-on API calls from the same session.
+- Review conditional access results and risk detections for the same user and time window.
+
+
+*Response and remediation*
+
+
+- If unauthorized, revoke refresh tokens for the user, review consent and app permissions, and reset credentials per policy.
+- Escalate per incident procedures when the resource corresponds to sensitive APIs or high-privilege applications.
+
+
+==== Setup
+
+
+Microsoft Entra ID sign-in logs (`logs-azure.signinlogs-*`) must include `azure.signinlogs.properties.app_id` and
+`azure.signinlogs.properties.resource_id`. Tune the exclusion list for first-party resource identifiers your tenant
+expects from the Microsoft Authentication Broker.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"azure.signinlogs" and event.category:"authentication" and event.action:"Sign-in activity" and
+event.outcome:success and azure.signinlogs.properties.app_id:"29d9ed98-a469-4536-ade2-f981bc1d605e" and
+azure.signinlogs.properties.resource_id:(* and not 
+    ("00000002-0000-0000-c000-000000000000" or
+    "90a2e5d2-fd7a-4a2e-bc90-3dc50ae8e3ee" or
+    "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9" or
+    "d4ebce55-015a-49b5-a083-c84d1797ae8c" or
+    "00000003-0000-0000-c000-000000000000" or 
+    "0a5f63c0-b750-4f38-a71c-4fc0d58b89e2")
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* Sub-technique:
+** Name: Cloud Accounts
+** ID: T1078.004
+** Reference URL: https://attack.mitre.org/techniques/T1078/004/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Use Alternate Authentication Material
+** ID: T1550
+** Reference URL: https://attack.mitre.org/techniques/T1550/
+* Sub-technique:
+** Name: Application Access Token
+** ID: T1550.001
+** Reference URL: https://attack.mitre.org/techniques/T1550/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-entra-id-oauth-device-code-phishing-via-aitm.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-entra-id-oauth-device-code-phishing-via-aitm.asciidoc
new file mode 100644
index 0000000000..c8344c77ad
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-entra-id-oauth-device-code-phishing-via-aitm.asciidoc
@@ -0,0 +1,133 @@
+[[prebuilt-rule-8-19-24-entra-id-oauth-device-code-phishing-via-aitm]]
+=== Entra ID OAuth Device Code Phishing via AiTM
+
+Detects successful Microsoft Entra ID sign-ins that use the OAuth device code authentication protocol with the Microsoft Authentication Broker client requesting first-party Office API resources (Exchange Online, Microsoft Graph, or SharePoint) while flagged as interactive. This pattern is associated with adversary-in-the-middle (AiTM) phishing kits such as Tycoon 2FA, where victims complete device code flows that ultimately broker tokens for mail and collaboration APIs.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-azure.signinlogs-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://any.run/malware-trends/tycoon/
+* https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows
+* https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Sign-in Logs
+* Use Case: Threat Detection
+* Threat: Tycoon2FA
+* Tactic: Initial Access
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Entra ID OAuth Device Code Phishing via AiTM*
+
+
+Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.session_id`, `source.ip`,
+`user_agent.original`, and `azure.signinlogs.properties.resource_display_name` for context around the device code
+completion.
+
+Confirm whether the user knowingly entered a device code (for example on a shared or headless device) and whether
+broker-mediated access to Exchange, Graph, or Yammer is expected for that account.
+
+
+*Possible investigation steps*
+
+
+- Interview the user about recent links, QR codes, or prompts to approve a device code.
+- Correlate with `azure.signinlogs` and Microsoft 365 audit logs for mailbox, Teams, or file access from the same
+  session or IP shortly after the event.
+- Review conditional access and MFA satisfaction details for the same `session_id`.
+
+
+*Response and remediation*
+
+
+- If malicious, revoke refresh tokens for the user, reset credentials per policy, and review application consent.
+- Block or monitor the source IP and escalate per incident procedures.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"azure.signinlogs" and event.category:"authentication" and event.action:"Sign-in activity" and
+event.outcome:success and azure.signinlogs.properties.app_id:"29d9ed98-a469-4536-ade2-f981bc1d605e" and
+azure.signinlogs.properties.authentication_protocol:deviceCode and
+azure.signinlogs.properties.resource_id:(
+    "00000002-0000-0ff1-ce00-000000000000" or
+    "00000003-0000-0ff1-ce00-000000000000" or
+    "00000005-0000-0ff1-ce00-000000000000"
+) and azure.signinlogs.properties.is_interactive:true
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Phishing
+** ID: T1566
+** Reference URL: https://attack.mitre.org/techniques/T1566/
+* Sub-technique:
+** Name: Spearphishing Link
+** ID: T1566.002
+** Reference URL: https://attack.mitre.org/techniques/T1566/002/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* Sub-technique:
+** Name: Cloud Accounts
+** ID: T1078.004
+** Reference URL: https://attack.mitre.org/techniques/T1078/004/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Use Alternate Authentication Material
+** ID: T1550
+** Reference URL: https://attack.mitre.org/techniques/T1550/
+* Sub-technique:
+** Name: Application Access Token
+** ID: T1550.001
+** Reference URL: https://attack.mitre.org/techniques/T1550/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa.asciidoc
new file mode 100644
index 0000000000..318128f57a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa.asciidoc
@@ -0,0 +1,121 @@
+[[prebuilt-rule-8-19-24-entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa]]
+=== Entra ID Potential AiTM Sign-In via OfficeHome (Tycoon2FA)
+
+Detects Microsoft Entra ID sign-ins consistent with Tycoon2FA phishing-as-a-service (PhaaS) adversary-in-the-middle (AiTM) activity: the Microsoft Authentication Broker requesting tokens for Microsoft Graph or Exchange Online, or the Office web client application authenticating to itself, combined with Node.js-style user agents (node, axios, undici). Tycoon 2FA bypasses MFA by relaying authentication and capturing session material, often targeting Microsoft 365 and Gmail. Baseline legitimate automation and developer tooling before tuning.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-azure.signinlogs-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://any.run/malware-trends/tycoon/
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Sign-in Logs
+* Use Case: Threat Detection
+* Threat: Tycoon2FA
+* Tactic: Initial Access
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Entra ID Potential AiTM Sign-In via OfficeHome (Tycoon2FA)*
+
+
+Review user.name, azure.signinlogs.properties.user_principal_name, azure.signinlogs.properties.app_id,
+azure.signinlogs.properties.resource_id, user_agent.original, source.ip, source.geo fields, and
+azure.signinlogs.properties.session_id.
+
+Confirm whether the user intentionally signed in and whether Node.js-style user agents (node, axios, undici) are
+expected for Microsoft Authentication Broker or Office web client flows in your environment.
+
+
+*Possible investigation steps*
+
+
+- Correlate the session with Microsoft Graph activity logs and mailbox audit for follow-on data access.
+- Review conditional access outcomes and MFA detail for the same session.
+- Hunt for other sign-ins from the same source IP with unusual user agents or rapid OAuth patterns.
+
+
+*Response and remediation*
+
+
+- If malicious, revoke refresh tokens for the user, reset credentials per policy, and review application consent.
+- Block or monitor the source IP and escalate per incident procedures.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"azure.signinlogs" and event.category:"authentication" and
+event.action:"Sign-in activity" and
+(
+    (
+        azure.signinlogs.properties.app_id:"29d9ed98-a469-4536-ade2-f981bc1d605e" and
+        azure.signinlogs.properties.resource_id:(
+            "00000002-0000-0ff1-ce00-000000000000" or "00000003-0000-0000-c000-000000000000"
+        )
+    ) or
+    (
+        azure.signinlogs.properties.app_id:"4765445b-32c6-49b0-83e6-1d93765276ca" and
+        azure.signinlogs.properties.resource_id:"4765445b-32c6-49b0-83e6-1d93765276ca"
+    )
+) and user_agent.original:(node or axios* or undici)
+
+----------------------------------
+
+*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/
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Steal Web Session Cookie
+** ID: T1539
+** Reference URL: https://attack.mitre.org/techniques/T1539/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-entra-id-register-device-with-unusual-user-agent-azure-ad-join.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-entra-id-register-device-with-unusual-user-agent-azure-ad-join.asciidoc
new file mode 100644
index 0000000000..7a4cbfc59f
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-entra-id-register-device-with-unusual-user-agent-azure-ad-join.asciidoc
@@ -0,0 +1,106 @@
+[[prebuilt-rule-8-19-24-entra-id-register-device-with-unusual-user-agent-azure-ad-join]]
+=== Entra ID Register Device with Unusual User Agent (Azure AD Join)
+
+Detects successful Microsoft Entra ID audit events for Register device where additional details indicate an Azure AD join and the recorded user agent is not one of the common native registration clients (Dsreg, DeviceRegistrationClient, or Dalvik-based Android enrollment). Legitimate Windows and standard mobile enrollment flows often present predictable user-agent strings; unexpected clients may reflect scripted registration, third-party tooling, or adversary-driven device registration used for persistence or token abuse. Baseline approved provisioning tools and MDM integrations before tuning.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-azure.auditlogs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://learn.microsoft.com/en-us/entra/identity/devices/concept-directory-join
+* https://github.com/dirkjanm/ROADtools
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Audit Logs
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Entra ID Register Device with Unusual User Agent (Azure AD Join)*
+
+
+Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName`, source IP fields on the audit event,
+`azure.auditlogs.properties.target_resources.0.display_name` for the device name, and
+`azure.correlation_id` for related audit entries.
+
+Compare `azure.auditlogs.properties.userAgent` to your organization's standard Autopilot, Intune, and Windows enrollment
+clients.
+
+
+*Possible investigation steps*
+
+
+- Confirm whether the user intentionally joined a device and whether the user agent matches a known provisioning package.
+- Pivot to `azure.signinlogs` for the same principal and timeframe for risky sign-ins or token broker activity.
+- Search for other `Register device` events from the same IP or user agent across the tenant.
+
+
+*Response and remediation*
+
+
+- If malicious, remove the device in Entra ID, revoke refresh and primary refresh tokens for the user, and reset credentials per policy.
+- Tighten device registration and join controls via Conditional Access and device compliance policies.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"azure.auditlogs" and event.action:"Register device" and
+event.outcome:(success or Success) and
+azure.auditlogs.properties.userAgent:(* and not (Dsreg* or DeviceRegistrationClient or Dalvik*)) and
+azure.auditlogs.properties.additional_details.value:"Azure AD join"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Sub-technique:
+** Name: Device Registration
+** ID: T1098.005
+** Reference URL: https://attack.mitre.org/techniques/T1098/005/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-execution-of-file-written-or-modified-by-microsoft-office.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-execution-of-file-written-or-modified-by-microsoft-office.asciidoc
new file mode 100644
index 0000000000..04259c33f4
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-execution-of-file-written-or-modified-by-microsoft-office.asciidoc
@@ -0,0 +1,176 @@
+[[prebuilt-rule-8-19-24-execution-of-file-written-or-modified-by-microsoft-office]]
+=== Execution of File Written or Modified by Microsoft Office
+
+Identifies an executable created by a Microsoft Office application and subsequently executed. These processes are often launched via scripts inside documents or during exploitation of Microsoft Office applications.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process-*
+* logs-endpoint.events.file-*
+* endgame-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 60m
+
+*Searches indices from*: now-120m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Execution
+* Resources: Investigation Guide
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+
+*Version*: 115
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Execution of File Written or Modified by Microsoft Office*
+
+
+
+*Possible investigation steps*
+
+
+- Which source events matched the Office write-to-execute sequence?
+  - Why: this sequence can merge fields from different file and process events, so source events are the evidence for writer and executed-process identity.
+  - Focus: open Investigate in Timeline for the alert window on the same host; compare written `file.path` with executed `process.executable`, then record source `process.name`, `process.entity_id`, and stable `user.id`.
+  - Implication: escalate when Office creates an executable that later starts from the same path; lower suspicion when the recovered sequence resolves to a recognized signed add-in or helper updater in a controlled product tree. Signed Microsoft NewOutlookInstaller.exe and Citrix ShareFileForOutlook helpers are excluded, so a generic updater label is not closure.
+
+- Is the Office writer the expected Office component and parent context?
+  - Focus: writer `process.executable`, signer/trust, `process.parent.executable`, and `process.parent.command_line`.
+  - Implication: escalate when WINWORD.EXE, EXCEL.EXE, OUTLOOK.EXE, POWERPNT.EXE, MSPUB.EXE, MSACCESS.EXE, eqnedt32.exe, or fltldr.exe is renamed, untrusted, user-writable, or launched by an unusual parent; lower suspicion when writer path, signer, and parent chain match the user's recognized Office integration. Writer identity never clears the executed file by itself.
+
+- Does the written executable look staged for payload delivery?
+  - Focus: `file.path`, original path/extension, `file.Ext.header_bytes`, `file.Ext.windows.zone_identifier`, and same-host file activity on the written path. !{investigate{"description":"","label":"File events for the written executable path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-2h","relativeTo":"now"}}
+  - Implication: escalate for Temp, Downloads, AppData, mail cache, startup, unrelated product paths, Internet Zone evidence, or executable content after rename; lower suspicion when the artifact stays in a recognized add-in or update tree and path history fits that workflow.
+
+- Does the executed file's identity and command line fit the same workflow?
+  - Focus: executed `process.executable`, `process.hash.sha256`, signer, `process.command_line`, and `process.Ext.relative_file_creation_time`.
+  - Hint: use prior endpoint process starts or related alerts for `process.hash.sha256` only after identity and command line fit the suspected workflow. !{investigate{"description":"","label":"Alerts associated with the executed file hash","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate when the executable is newly created, unsigned, user-writable, mismatched to signer or path, or launched with script, LOLBin, unpacking, or self-extracting arguments; lower suspicion only when signer, hash history, path, age, and arguments all fit the same recognized helper workflow.
+
+- What document, email, archive, or integration source caused Office to write the executable?
+  - Focus: file events from writer `process.entity_id`; review `file.path`, `file.origin_url`, `file.origin_referrer_url`, and `file.Ext.windows.zone_identifier`.
+  - Hint: if records are incomplete or the entity pivot returns none, use the same host, writer `process.pid`, and tight write-time window.
+  - Implication: escalate when the write follows a downloaded document, email attachment, archive extraction, or web referrer outside the same recognized workflow; lower suspicion when provenance points to a recognized deployment package or Office integration source. Missing provenance is inconclusive, not benign.
+
+- Did the executed file produce malicious follow-on process or file activity?
+  - Focus: process and file events scoped to executed `process.entity_id`: child `process.parent.entity_id`, child `process.command_line`, and new `file.path` values.
+  - Hint: if records are incomplete or the entity pivot returns none, use the same host, executed `process.pid`, and post-start window.
+  - Implication: escalate when the payload launches script interpreters, LOLBins, unpackers, or additional binaries, or stages files outside the recognized product tree; lower urgency when follow-on activity stays limited to expected local install or update actions. Preserve Office-written DLLs, scripts, or shortcut launchers in the same scope as adjacent payload variants.
+
+- If local findings remain suspicious or unresolved, do related alerts show the same delivery chain or spread?
+  - Focus: related alerts for `host.id`, then pivot on recovered stable `user.id`; prioritize document delivery, script execution, persistence, and outbound connection alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when related alerts connect the same host or user to delivery, scripting, persistence, or beaconing; keep scope local when the sequence is isolated and local evidence supports one recognized workflow.
+
+- Escalate when sequence, artifact, identity, delivery, behavior, or related-alert evidence supports suspicious Office write-to-execute activity; close only when all categories align with one recognized add-in, updater, or integration workflow and no contradictory artifacts remain; if evidence is mixed or incomplete, preserve artifacts and escalate.
+
+
+*False positive analysis*
+
+
+- Office add-in, repair, updater, document-management, e-signature, DLP, or collaboration integrations can write and launch helper executables. Confirm that writer identity, written path, executed hash or signer, parent context, provenance, command line, and follow-on activity all point to the same product or integration workflow. If records are unavailable, require telemetry-only recurrence of the same writer, path tree, signer/hash pattern, and `host.id` or `user.id` cohort across prior alerts.
+- Before creating an exception, validate that the same Office writer, path tree, executed signer or `process.hash.sha256`, provenance pattern, and `host.id`/`user.id` cohort recur across prior alerts from this rule. Build the exception from that minimum workflow pattern; avoid exceptions on Office process names, `process.name`, or `file.extension` alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and document the writer identity, written path tree, executed hash and signer, parent/delivery context, and recurrence evidence. Create an exception only for the same stable workflow pattern.
+- If suspicious but unconfirmed, preserve Timeline source events, copies of the written executable and source document/archive, process tree details, recovered entity IDs, command line, hash, path, and provenance URLs before containment. Apply reversible containment first: quarantine the lure or executable, block the confirmed hash/path temporarily where controls support it, or increase monitoring on the affected `host.id` and `user.id`. Isolate the host only if follow-on process/file evidence shows malicious staging or execution and the host can tolerate interruption.
+- If confirmed malicious, isolate the host and terminate the executed payload after preserving the source events, process tree, written executable, lure document or archive, hash, signer, and provenance evidence. Block the confirmed hash or path where controls support it, then remove the malicious executable, lure, archive, and staged files identified during the investigation.
+- Review related hosts and users for the same written path pattern, executed hash, signer, and provenance evidence before deleting artifacts. Then remediate the delivery path, such as the phishing message, archive, or malicious Office document, that led to the write-execute sequence.
+- Post-incident hardening: restrict Office-driven writes and launches of executable content in user-writable paths, retain endpoint file-provenance and process-start telemetry, and record confirmed adjacent variants, such as Office-written DLLs, scripts, or shortcut launchers, in the case history 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
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence with maxspan=2h
+  [file where host.os.type == "windows" and event.type != "deletion" and file.extension : "exe" and
+    process.name : (
+      "WINWORD.EXE", "EXCEL.EXE", "OUTLOOK.EXE", "POWERPNT.EXE",
+      "eqnedt32.exe", "fltldr.exe", "MSPUB.EXE", "MSACCESS.EXE"
+    )
+  ] by host.id, file.path
+  [process where host.os.type == "windows" and event.type == "start" and 
+   not (process.name : "NewOutlookInstaller.exe" and process.code_signature.subject_name : "Microsoft Corporation" and process.code_signature.trusted == true) and 
+   not (process.name : "ShareFileForOutlook-v*.exe" and process.code_signature.subject_name : "Citrix Systems, Inc." and process.code_signature.trusted == true)
+  ] by host.id, process.executable
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Exploitation for Client Execution
+** ID: T1203
+** Reference URL: https://attack.mitre.org/techniques/T1203/
+* Technique:
+** Name: User Execution
+** ID: T1204
+** Reference URL: https://attack.mitre.org/techniques/T1204/
+* Sub-technique:
+** Name: Malicious File
+** ID: T1204.002
+** Reference URL: https://attack.mitre.org/techniques/T1204/002/
+* Tactic:
+** Name: 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-execution-via-tsclient-mountpoint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-execution-via-tsclient-mountpoint.asciidoc
new file mode 100644
index 0000000000..f1e4c75d0a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-execution-via-tsclient-mountpoint.asciidoc
@@ -0,0 +1,164 @@
+[[prebuilt-rule-8-19-24-execution-via-tsclient-mountpoint]]
+=== Execution via TSClient Mountpoint
+
+Identifies execution from the Remote Desktop Protocol (RDP) shared mountpoint tsclient on the target host. This may indicate a lateral movement attempt.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://specterops.io/blog/2020/01/22/revisiting-remote-desktop-lateral-movement/
+* 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
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Windows Security Event Logs
+* Data Source: Microsoft Defender XDR
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 320
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Execution via TSClient Mountpoint*
+
+
+
+*Possible investigation steps*
+
+
+- What exact TSClient launch did the alert capture?
+  - Focus: `process.executable`, `process.command_line`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`.
+  - Implication: escalate when the redirected-drive executable is unsigned, untrusted, renamed, script-capable, or launched with command intent outside a recognized RDP support or deployment workflow; lower concern only when a vendor-signed installer or utility from the RDP client drive matches that exact session purpose.
+- What launcher and Windows session produced the TSClient process?
+  - Focus: `process.parent.name`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, `user.id`.
+  - Implication: escalate when the parent is "cmd.exe", "powershell.exe", "taskmgr.exe", or another remote-session launcher, when the session is remote-interactive for an unusual user, or when children show another TSClient-launched payload; lower concern when parent and session match a recognized support launcher or deployment tool.
+- Which RDP source created the session, when authentication telemetry is available?
+  - Focus: bridge `process.Ext.authentication_id` to same-host authentication events through `winlog.event_data.TargetLogonId`; read `source.ip`, `winlog.logon.type`, `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Authentication events for the linked session","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{process.Ext.authentication_id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate when the recovered source or authentication package conflicts with recognized jump hosts, support workstations, or deployment sources. Missing authentication telemetry is unresolved, not benign.
+- Did the TSClient process spawn shells, tools, or persistence helpers on the target?
+  - Focus: child starts from `process.entity_id` on `host.id`, especially `process.executable`, `process.command_line`, `process.parent.entity_id`. !{investigate{"description":"","label":"Child processes spawned by the TSClient launch","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `process.entity_id` is absent, recover descendants with `host.id` + `process.pid` + a tight alert-time window and confirm the parent command line before interpreting results.
+  - Implication: escalate when descendants include shells, script hosts, remote-access tools, credential utilities, or persistence helpers; an isolated installer-like launch lowers urgency only if session and identity evidence also align.
+- If local evidence remains suspicious or incomplete, do related alerts show the same user or host attempting RDP or remote execution elsewhere?
+  - Focus: same-user `user.id` and same-host `host.id` alerts sharing RDP, credential, remote-service, or execution patterns.
+  - Hint: user alert pivot. !{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: host alert pivot. !{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 only when related alerts reuse the same user, host, session pattern, or command family; unrelated alert noise does not change disposition.
+- Escalate when suspicious identity, lineage, source, descendants, or related alerts support unauthorized redirected-drive execution; close only when process identity, parent/session, source when available, and descendants all match one recognized RDP support or deployment activity; preserve artifacts and escalate when authentication visibility is missing or evidence remains mixed.
+
+
+*False positive analysis*
+
+
+- RDP helpdesk, break-fix, or software deployment workflows can legitimately run installers or utilities from a client drive redirected into the target session. Confirm all evidence converges on one exact activity: identity and intent (`process.executable`, `process.command_line`, signature), launch/session (`process.parent.name`, `user.id`, `host.id`, recovered `source.ip` when available), and outcome (no suspicious descendants or related alerts). Contradictory evidence keeps the case open.
+- Use recurrence only to support a narrow exception candidate, not to close the current case by itself. Require the same stable executable path or signer, parent/session pattern, `user.id`, `host.id`, recovered source when available, and descendant-clean outcome across prior alerts from this rule; keep the case open when current telemetry is incomplete or contradictory.
+- Before creating an exception, anchor it on the minimum confirmed pattern: specific `process.executable`, stable `process.command_line` or signer, `process.parent.name`, `user.id`, `host.id`, and recovered `source.ip` only when it was part of the confirmation. Avoid exceptions on the TSClient path wildcard or `process.name` alone.
+
+
+*Response and remediation*
+
+
+- Preserve evidence before changing state: case export of the alert, process tree, command line, binary hash or sample when available, child-process events, and authentication-bridge records.
+- If confirmed benign after preservation, reverse temporary containment and document the exact process identity, parent/session context, `user.id`, `host.id`, and recovered `source.ip` that established the redirected-drive workflow. Create an exception only after the same narrowly scoped pattern is stable across prior alerts.
+- If suspicious but unconfirmed after preservation, use reversible containment only: terminate the active RDP session, restrict new RDP connections from the recovered source when available, disable drive redirection for the affected access path, or heighten monitoring on the affected `host.id`. Do not isolate the host, terminate processes, or suspend accounts unless follow-on execution or related alerts confirm broader abuse.
+- If confirmed malicious, isolate the target host when feasible, terminate the TSClient-launched process and malicious descendants after evidence capture, and disable or suspend the account or RDP access path used for the session.
+- Scope before cleanup by reviewing other hosts and users tied to the same recovered source, `user.id`, distinctive `process.command_line`, signer, or hash.
+- Eradicate only the staged payloads, persistence artifacts, or tooling identified during the investigation, then review whether credentials exposed in the RDP session need reset or reissue.
+- Post-incident hardening: limit RDP drive redirection, restrict RDP access to managed jump hosts, retain endpoint process and Windows Security telemetry for session bridging, and document any TSClient execution patterns that should become narrow exceptions.
+
+==== 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.executable : "\\Device\\Mup\\tsclient\\*.exe"
+
+----------------------------------
+
+*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: Remote Desktop Protocol
+** ID: T1021.001
+** Reference URL: https://attack.mitre.org/techniques/T1021/001/
+* 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-24/prebuilt-rule-8-19-24-file-creation-in-world-writable-directory-by-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-file-creation-in-world-writable-directory-by-unusual-process.asciidoc
new file mode 100644
index 0000000000..9f511f39b4
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-file-creation-in-world-writable-directory-by-unusual-process.asciidoc
@@ -0,0 +1,171 @@
+[[prebuilt-rule-8-19-24-file-creation-in-world-writable-directory-by-unusual-process]]
+=== File Creation in World-Writable Directory by Unusual Process
+
+This rule detects the creation of files in world-writable directories by an unusual process. Attackers may attempt to hide their activities by creating files in world-writable directories, which are commonly used for temporary file storage. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* endgame-*
+* logs-endpoint.events.file*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.rapid7.com/blog/post/tr-new-whitepaper-stealthy-bpfdoor-variants/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: Elastic Defend
+* Data Source: Elastic Endgame
+* Data Source: SentinelOne
+* 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 File Creation in World-Writable Directory by Unusual Process*
+
+
+This alert flags a Linux process that normally should not stage content in shared writable locations such as /tmp, /var/tmp, /run, or /dev/shm. Attackers abuse these directories because many users and services can write there, which makes payloads and helper scripts easier to hide; for example, a compromised shell may use curl or python to drop an ELF backdoor into /dev/shm and execute it from that transient path.
+
+
+*Possible investigation steps*
+
+
+- Reconstruct the full process lineage and execution context around the file creation to determine whether it originated from an interactive session, scheduled task, container, service account, or a parent process already running from an unusual location.
+- Inspect the dropped file’s type, permissions, ownership, hash, and contents to assess whether it is a script, ELF, archive, or disguised payload, and determine if it was later executed, renamed, or moved to a more persistent path.
+- Correlate the alert with nearby authentication, privilege escalation, and network activity on the same host to identify signs of compromise such as recent SSH access, sudo use, remote command execution, or outbound connections to untrusted infrastructure.
+- Validate whether the activity aligns with known administrative or software deployment behavior by checking package ownership, change records, automation tooling, and host or user prevalence, since one-off staging in shared writable paths is more suspicious than common fleetwide behavior.
+
+
+*False positive analysis*
+
+
+- Legitimate package installation, OS update, or local maintenance script activity can use interpreters or utilities such as cp, mv, chmod, curl, or python to stage temporary files in /tmp or /var/tmp before moving them into place, so verify whether the process tree, user, and event time align with expected system change or package management activity on the host.
+- Normal service startup or deployment automation may create transient files in /run or /dev/shm for configuration generation, caching, or runtime state, so confirm the file owner, contents, and parent process match a known application or boot-time workflow and that the same behavior is regularly seen on comparable systems.
+
+
+*Response and remediation*
+
+- Isolate the affected Linux host from the network while preserving forensic access, stop the malicious process and any spawned tools, and collect copies of the dropped file before cleanup.
+- Remove attacker footholds by deleting the dropped file.
+- Restore the system to a known-good state by rebuilding from a trusted image or validated backup and verifying core packages, shell configuration files, scheduled tasks, and remote access settings match the approved baseline before reconnecting it.
+- Escalate to incident response immediately if the file creation was followed by privilege escalation, credential access, outbound tool downloads, lateral movement over SSH, or the same behavior is identified on multiple hosts, and expand scoping to related accounts and systems.
+
+
+==== 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:file and event.type:creation and (
+  process.name:("cp" or "mv") or
+  process.executable:(
+    ./* or /tmp/* or /var/tmp/* or /dev/shm/* or /run/user/* or /var/run/user/* or /boot/* or /sys/* or
+    /lost+found/* or /proc/* or /var/mail/* or /var/www/*
+  )
+) and
+file.path:(/run/* or /var/run/* or /dev/shm/* or /tmp/* or /var/tmp/*) and
+not (
+  file.path:(
+    /var/tmp/dracut.* or /var/tmp/mkinitramfs_* or /tmp/.*-00000000.so or /run/udev/rules.d/* or
+    /tmp/new_root/* or /tmp/newroot/* or /run/user/*/.bubblewrap/newroot/* or /tmp/tmp.*/docker-scout_* or
+    /var/tmp/portage/* or /tmp/yarn--* or /run/k3s/containerd/* or /var/tmp/pamac-build-* or
+    /tmp/mkinitcpio* or /run/user/*/netns/netns-* or /tmp/apt-key* or /tmp/tmp.*/pubring.orig.gpg or
+    /tmp/CVU_19_* or /tmp/ut-backup-files.* or /tmp/tmp.*/terraform/*
+  ) or
+  file.extension:("json" or "txt") or
+  process.executable:(
+    /tmp/par-* or /tmp/snap.rootfs_* or /tmp/CVU_*/exectask or /tmp/.mount_*/usr/bin/QGroundControl or
+    ./snap/snapd/*/usr/lib/snapd/snap-update-ns or "./usr/lib/snapd/snap-update-ns" or
+    "/tmp/newroot/snap/snapd/current/usr/bin/snap" or /tmp/newroot/snap/snapd/*/usr/lib/snapd/snap-confine or
+    "./usr/bin/podman" or "/tmp/newroot/usr/lib/systemd/systemd"
+  )
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: File and Directory Permissions Modification
+** ID: T1222
+** Reference URL: https://attack.mitre.org/techniques/T1222/
+* Sub-technique:
+** Name: Linux and Mac File and Directory Permissions Modification
+** ID: T1222.002
+** Reference URL: https://attack.mitre.org/techniques/T1222/002/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-finder-sync-plugin-registered-and-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-finder-sync-plugin-registered-and-enabled.asciidoc
new file mode 100644
index 0000000000..b92a9a6c39
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-finder-sync-plugin-registered-and-enabled.asciidoc
@@ -0,0 +1,150 @@
+[[prebuilt-rule-8-19-24-finder-sync-plugin-registered-and-enabled]]
+=== Finder Sync Plugin Registered and Enabled
+
+Finder Sync plugins enable users to extend Finder’s functionality by modifying the user interface. Adversaries may abuse this feature by adding a rogue Finder Plugin to repeatedly execute malicious payloads for persistence.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/specterops/presentations/raw/master/Leo%20Pitt/Hey_Im_Still_in_Here_Modern_macOS_Persistence_SO-CON2020.pdf
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: macOS
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 212
+
+*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 Finder Sync Plugin Registered and Enabled*
+
+
+Finder Sync plugins enhance macOS Finder by allowing third-party applications to integrate and modify its interface. While beneficial for legitimate software, adversaries can exploit this feature to maintain persistence by registering malicious plugins. The detection rule identifies suspicious plugin registrations by monitoring the `pluginkit` process, filtering out known safe applications, and flagging unusual activity, thus helping analysts spot potential threats.
+
+
+*Possible investigation steps*
+
+
+- Review the process details to confirm the execution of the `pluginkit` process with the specific arguments `-e`, `use`, and `-i`, which indicate the registration of a Finder Sync plugin.
+- Cross-reference the plugin identifier found in the process arguments against the list of known safe applications to determine if it is potentially malicious.
+- Investigate the parent process of the `pluginkit` execution to identify any unusual or unauthorized parent processes that might suggest malicious activity.
+- Check the system for any recent installations or updates of applications that might have introduced the suspicious Finder Sync plugin.
+- Analyze the behavior and origin of the executable associated with the suspicious plugin to assess its legitimacy and potential threat level.
+- Review system logs and other security alerts around the time of the plugin registration to identify any correlated suspicious activities or anomalies.
+
+
+*False positive analysis*
+
+
+- Known safe applications like Google Drive, Boxcryptor, Adobe, Microsoft OneDrive, Insync, and Box are already excluded from triggering false positives. Ensure these applications are up-to-date to maintain their exclusion status.
+- If a legitimate application not listed in the exclusions is causing false positives, consider adding its specific Finder Sync plugin identifier to the exclusion list after verifying its safety.
+- Monitor the parent process paths of legitimate applications. If a trusted application frequently triggers alerts, add its executable path to the exclusion list to prevent unnecessary alerts.
+- Regularly review and update the exclusion list to accommodate new versions or additional legitimate applications that may introduce Finder Sync plugins.
+- Educate users on the importance of installing applications from trusted sources to minimize the risk of false positives and ensure that only legitimate plugins are registered.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration by the malicious Finder Sync plugin.
+- Terminate the suspicious `pluginkit` process to stop the execution of the rogue Finder Sync plugin and prevent further persistence.
+- Remove the malicious Finder Sync plugin by unregistering it using the `pluginkit` command with appropriate flags to ensure it cannot be re-enabled.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious payloads or artifacts.
+- Review system logs and the Finder Sync plugin registration history to identify any unauthorized changes or additional compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign.
+- Implement enhanced monitoring for `pluginkit` activity and similar persistence mechanisms to detect and respond to future attempts promptly.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from Elastic Defend.
+
+
+*Elastic Defend Integration Setup*
+
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+
+
+*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide].
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide].
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "pluginkit" and
+  process.args == "-e" and process.args like~ "use" and process.args == "-i" and
+  (process.parent.name like~ ("python*", "node", "osascript", "bash", "sh", "zsh") or (process.parent.code_signature.exists == false or process.parent.code_signature.trusted == false))
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-first-time-fortigate-administrator-login.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-first-time-fortigate-administrator-login.asciidoc
new file mode 100644
index 0000000000..73087b1ff9
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-first-time-fortigate-administrator-login.asciidoc
@@ -0,0 +1,145 @@
+[[prebuilt-rule-8-19-24-first-time-fortigate-administrator-login]]
+=== First-Time FortiGate Administrator Login
+
+This rule detects the first observed successful login of a user with the Administrator role to the FortiGate management interface within the last 5 days. First-time administrator logins can indicate newly provisioned accounts, misconfigurations, or unauthorized access using valid credentials and should be reviewed promptly.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate
+* https://www.cisa.gov/news-events/alerts/2026/01/28/fortinet-releases-guidance-address-ongoing-exploitation-authentication-bypass-vulnerability-cve-2026
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Tactic: Initial Access
+* Resources: Investigation Guide
+* Domain: Network
+* Domain: Identity
+* Data Source: Fortinet
+* Data Source: Fortinet FortiGate
+
+*Version*: 5
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and Analysis*
+
+
+
+*Investigating First-Time FortiGate Administrator Login*
+
+
+This alert indicates that a user with the **Administrator** role has successfully logged in to the FortiGate management interface for the first time within the last 5 days of observed data.
+
+Because administrator access provides full control over network security devices, any newly observed admin login should be validated to confirm it is expected and authorized.
+
+
+*Investigation Steps*
+
+
+- **Identify the account**
+  - Review `source.user.name` and confirm whether the account is known and officially provisioned.
+  - Determine whether this is a newly created administrator or an existing account logging in for the first time.
+
+- **Validate the source**
+  - Review `source.ip` and confirm whether it originates from a trusted management network, VPN, or jump host.
+  - Investigate geolocation or ASN if the source IP is external or unusual.
+
+- **Review login context**
+  - Examine associated FortiGate log messages for details such as login method, interface, or authentication source.
+  - Check for additional administrative actions following the login (policy changes, user creation, configuration exports).
+  - Review  `fortinet.firewall.profile` to identify the FortiGate Admin Profile the identity logged in under.
+
+- **Correlate with recent changes**
+  - Verify whether there were recent change requests, onboarding activities, or maintenance windows that explain the login.
+  - Look for other authentication attempts (failed or successful) from the same source or user.
+
+
+*False Positive Considerations*
+
+
+- Newly onboarded administrators or service accounts.
+- First-time logins after log retention changes or data source onboarding.
+- Automation, backup, or monitoring tools introduced recently.
+- Lab, development, or test FortiGate devices.
+
+
+*Response and Remediation*
+
+
+- **If authorized**
+  - Document the activity and consider adding an exception if the behavior is expected.
+  - Ensure the account follows least-privilege and MFA best practices.
+
+- **If suspicious or unauthorized**
+  - Disable or restrict the administrator account immediately.
+  - Rotate credentials and review authentication sources.
+  - Audit recent FortiGate configuration changes.
+  - Review surrounding network activity for lateral movement or persistence attempts.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM logs-fortinet_fortigate.*, filebeat-* metadata _id
+
+| WHERE data_stream.dataset == "fortinet_fortigate.log" and
+        event.category == "authentication" and event.action == "login" and
+        event.outcome == "success" and source.user.roles == "Administrator" and source.user.name is not null
+| stats Esql.logon_count = count(*),
+       Esql.first_time_seen = MIN(@timestamp),
+       Esql.source_ip_values = VALUES(source.ip),
+       Esql.message_values = VALUES(message) by source.user.name, fortinet.firewall.profile
+
+// first time seen is within 6m of the rule execution time and for the last 5d of events history
+| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now())
+| where Esql.recent <= 6 and Esql.logon_count == 1
+
+// move dynamic fields to ECS equivalent for rule exceptions
+| eval source.ip = MV_FIRST(Esql.source_ip_values)
+
+| keep source.ip,
+       source.user.name,
+       fortinet.firewall.profile,
+       Esql.logon_count,
+       Esql.first_time_seen,
+       Esql.source_ip_values,
+       Esql.message_values,
+       Esql.recent
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-github-private-repository-turned-public.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-github-private-repository-turned-public.asciidoc
new file mode 100644
index 0000000000..a25446f0ef
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-github-private-repository-turned-public.asciidoc
@@ -0,0 +1,116 @@
+[[prebuilt-rule-8-19-24-github-private-repository-turned-public]]
+=== GitHub Private Repository Turned Public
+
+Detects when a private GitHub repository is changed to public visibility. Adversaries may change repository visibility to public in order to exfiltrate sensitive code or data, potentially indicating a compromise or unauthorized access.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-github.audit-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Cloud
+* Use Case: Threat Detection
+* Tactic: Exfiltration
+* Tactic: Impact
+* Data Source: Github
+* 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 GitHub Private Repository Turned Public*
+
+
+This rule flags when a previously private repository is made public, a high-risk change that can expose proprietary code, credentials, and internal documentation. Attackers who hijack a maintainer’s account often flip visibility via the UI or API, then immediately fork or mirror the repo to an external account to retain access and harvest embedded secrets even if the org reverts the change.
+
+
+*Possible investigation steps*
+
+
+- Identify the actor and authentication method used for the visibility change, verify their repository role, and confirm the action against an approved change request or ticket.
+- Pull a time-bounded audit trail around the event for the actor and repository to surface related risky operations such as forking, transfers, collaborator additions, webhook edits, branch protection changes, or archive downloads.
+- Enumerate forks, mirrors, stars, and watchers added after the change via the repository network graph and correlate with external accounts or suspicious clusters.
+- Inspect GitHub Actions runs, deployments, and webhooks triggered post-change for workflows that export code or secrets to external destinations.
+- Perform rapid secret scanning across the repository history and HEAD, triage any exposed credentials, and initiate rotation while mapping impacted services and environments.
+
+
+*False positive analysis*
+
+
+- A planned, approved open-source release where a maintainer intentionally flips a sanitized repository from private to public as part of a documented change.
+- Bulk visibility changes during an organization-wide cleanup or migration that publishes templates, sample repos, or empty scaffolds, executed by an authorized service account.
+
+
+*Response and remediation*
+
+
+- Immediately revert the repository to private, remove outside collaborators, lock access to the core maintainers team, disable GitHub Actions and webhooks, and delete any release assets or packages published during the exposure window.
+- Enumerate new forks, mirrors, stars, and watchers created after the visibility change and file takedown requests with GitHub Trust & Safety for unauthorized public copies while removing any deploy keys and uninstalling suspicious GitHub App installations added around the event.
+- Run a rapid secret scan across the repository history and HEAD, rotate exposed credentials (cloud keys, API tokens, SSH keys), invalidate compromised service accounts, and purge cached artifacts or container images built from the public commit range.
+- Restore secure settings from baseline by re-applying branch protection rules, CODEOWNERS, required reviews, signed commits, and protected environments, then re-enable workflows only after reviewing job steps and outputs for any export of code or secrets.
+- Escalate to Security IR and Legal if the actor denies making the change, the repo network graph shows new public forks under unknown accounts, regulated data is present, or external users downloaded source zips or release archives during the public period.
+- Restrict who can change repository visibility to organization owners, enforce SSO and 2FA for maintainers, disable forking of private repositories, limit Actions to trusted runners and verified actions, and enable secret scanning with push protection across the organization.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+configuration where data_stream.dataset == "github.audit" and github.operation_type == "modify" and github.category == "repo" and
+event.action == "repo.access" and github.visibility == "public"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Exfiltration
+** ID: TA0010
+** Reference URL: https://attack.mitre.org/tactics/TA0010/
+* Technique:
+** Name: Automated Exfiltration
+** ID: T1020
+** Reference URL: https://attack.mitre.org/techniques/T1020/
+* Technique:
+** Name: Exfiltration Over Web Service
+** ID: T1567
+** Reference URL: https://attack.mitre.org/techniques/T1567/
+* Sub-technique:
+** Name: Exfiltration to Code Repository
+** ID: T1567.001
+** Reference URL: https://attack.mitre.org/techniques/T1567/001/
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-google-workspace-device-registration-after-oauth-from-suspicious-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-google-workspace-device-registration-after-oauth-from-suspicious-asn.asciidoc
new file mode 100644
index 0000000000..5247152293
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-google-workspace-device-registration-after-oauth-from-suspicious-asn.asciidoc
@@ -0,0 +1,133 @@
+[[prebuilt-rule-8-19-24-google-workspace-device-registration-after-oauth-from-suspicious-asn]]
+=== Google Workspace Device Registration After OAuth from Suspicious ASN
+
+Detects when a Google Workspace account completes OAuth authorization for a specific Google OAuth client from a high-risk autonomous system number (ASN), followed within 30 seconds by a device registration event with account state REGISTERED. This sequence can indicate device enrollment or join flows initiated from attacker-controlled or residential-proxy infrastructure after a user authorizes a sensitive client.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-google_workspace*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one
+* https://support.google.com/a/answer/7061566
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: Google Workspace
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Initial Access
+* Threat: Tycoon2FA
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Google Workspace Device Registration After OAuth from Suspicious ASN*
+
+
+Review `user.name`, `user.email`, `source.ip`, `source.as.organization.name`, `google_workspace.token.client.id`,
+`google_workspace.token.app_name`, and device fields on the second event (for example device display name or ID if
+present in your schema).
+
+Confirm whether the user intentionally registered a device and whether the OAuth client and ASN are expected for your
+mobile device management or enrollment program.
+
+
+*Possible investigation steps*
+
+
+- Correlate both events on `user.name` and timestamps to confirm the sequence is a single enrollment story.
+- Revoke or audit OAuth grants for the client if the authorization was not expected.
+- Search for additional `google_workspace.device` registrations from the same ASN in the same period.
+
+
+*Response and remediation*
+
+
+- If malicious, remove the unauthorized device from the Google Admin console, reset the user password, and revoke
+  active sessions and tokens per incident policy.
+- Restrict device registration and review OAuth app access policies.
+
+
+
+
+*Event lag*
+
+
+Google Workspace audit data can lag minutes to days behind real time. If sequences are missed, increase `from` and
+lower the integration poll interval per Google and Elastic documentation.
+
+==== Setup
+
+
+The Google Workspace Fleet integration or Filebeat Google Workspace module must ingest `google_workspace.token` and
+`google_workspace.device` audit streams.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by user.name with maxspan=30s
+  [iam where data_stream.dataset == "google_workspace.token" and event.action == "authorize" and
+      google_workspace.token.client.id == "77185425430.apps.googleusercontent.com" and
+      source.as.number in (9009, 45102, 215540, 29802, 62240, 204957, 395092)]
+  [any where data_stream.dataset == "google_workspace.device" and google_workspace.device.account_state == "REGISTERED"]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Sub-technique:
+** Name: Device Registration
+** ID: T1098.005
+** Reference URL: https://attack.mitre.org/techniques/T1098/005/
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Phishing
+** ID: T1566
+** Reference URL: https://attack.mitre.org/techniques/T1566/
+* Sub-technique:
+** Name: Spearphishing Link
+** ID: T1566.002
+** Reference URL: https://attack.mitre.org/techniques/T1566/002/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-group-policy-abuse-for-privilege-addition.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-group-policy-abuse-for-privilege-addition.asciidoc
new file mode 100644
index 0000000000..9f1e38ac41
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-group-policy-abuse-for-privilege-addition.asciidoc
@@ -0,0 +1,154 @@
+[[prebuilt-rule-8-19-24-group-policy-abuse-for-privilege-addition]]
+=== Group Policy Abuse for Privilege Addition
+
+Detects the first occurrence of a modification to Group Policy Object Attributes to add privileges to user accounts or use them to add users as local admins.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0025_windows_audit_directory_service_changes.md
+* https://labs.withsecure.com/tools/sharpgpoabuse
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Data Source: Active Directory
+* Resources: Investigation Guide
+* Use Case: Active Directory Monitoring
+* Data Source: Windows Security Event Logs
+
+*Version*: 215
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Group Policy Abuse for Privilege Addition*
+
+
+*Possible investigation steps*
+
+
+- What GPO extension change was preserved?
+  - Focus: `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.AttributeValue`, `winlog.event_data.OperationType`, `winlog.event_data.ObjectDN`, and `winlog.event_data.ObjectGUID` confirm the 5136 "gPCMachineExtensionNames" GPO change.
+  - Implication: escalate when the value enables Security CSE GUID "827D319E-6EAC-11D2-A4EA-00C04F79F83A" plus Computer Restricted Groups GUID "803E14A0-B4FB-11D0-A0D0-00A0C90F574B" on an unexpected GPO; lower concern only when artifacts/scope confirm a recognized hardening refresh.
+- Who changed the GPO, and from where?
+  - Focus: identify the writer: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectLogonId`, and `winlog.computer_name`.
+  - Hint: on `winlog.computer_name`, find "4624" where `winlog.event_data.TargetLogonId` equals the 5136 `winlog.event_data.SubjectLogonId`; search "4648" on `winlog.event_data.SubjectLogonId` for explicit credentials, then check `source.ip`, `winlog.logon.type`, `winlog.event_data.TargetUserName`, and `winlog.event_data.TargetServerName`. Missing logon telemetry is unresolved, not benign.
+    - !{investigate{"description":"","label":"Linked logon for the GPO writer","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Explicit-credential events for the GPO writer","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Implication: escalate when the writer is outside GPO admin cohort, uses an unusual source or direct domain-controller session, or shows alternate-credential use; lower concern when account/session match a recognized GPO administration path.
+- Do surrounding directory changes show a coordinated GPO update?
+  - Why: "5136" can record related object modifications; `winlog.event_data.OpCorrelationID` separates one GPO edit from directory noise.
+  - Focus: reconstruct surrounding "5136" records from the same domain controller with `winlog.event_data.OpCorrelationID`, `winlog.event_data.SubjectLogonId`, `winlog.event_data.ObjectGUID`, changed attribute, and operation type.
+  - Hint: prefer one `winlog.event_data.OpCorrelationID`; if absent, use the same `winlog.event_data.SubjectLogonId` plus tight `@timestamp` and `winlog.record_id` ordering. !{investigate{"description":"","label":"5136 events in this GPO change operation","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.OpCorrelationID","queryType":"phrase","value":"{{winlog.event_data.OpCorrelationID}}","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the operation touches other sensitive GPO attributes or combines this privilege path with GPO execution or persistence; lower concern when the 5136 set stays narrow and artifact/scope checks confirm one recognized security-template task.
+- What grants and recipients does the SYSVOL template define?
+  - Why: the alert proves machine security extensions were enabled; rights or local group membership live in "GptTmpl.inf" under the SYSVOL policy folder.
+  - Focus: use the policy GUID from the CN portion of `winlog.event_data.ObjectDN` with `winlog.event_data.DSName` to inspect "Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf"; map SIDs/groups to admin tier, service-account role, and whether `winlog.event_data.SubjectUserSid` benefits. Treat `winlog.event_data.ObjectGUID` as the AD object pivot, not the SYSVOL folder name, unless it matches the CN.
+  - Hint: if SYSVOL is unavailable, preserve `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.DSName`, and expected policy path; suspicious writer/session or companion 5136 evidence makes the missing grant an evidence gap.
+  - Implication: escalate when "[Privilege Rights]" grants high-impact rights ("SeDebugPrivilege", "SeTakeOwnershipPrivilege", "SeEnableDelegationPrivilege", or "SeImpersonatePrivilege"), when "[Group Membership]" adds broad/unexpected identities to local Administrators ("S-1-5-32-544"), or when the writer benefits; lower concern when entries and recipients match the recognized baseline for that GPO.
+- Which computers consume the changed GPO?
+  - Why: GPO privilege abuse scales with link scope, security filtering, WMI filters, and reach to admin workstations, servers, or domain controllers.
+  - Focus: use `winlog.event_data.ObjectDN` and the recovered policy-folder GUID to review GPO links, security filtering, WMI filters, and roles.
+  - Hint: if scope data is unavailable, preserve `winlog.event_data.ObjectDN` and `winlog.event_data.ObjectGUID`; do not assume narrow scope, and escalate if writer/session, companion-change, or grant evidence is suspicious.
+  - Implication: prioritize escalation when the GPO reaches domain controllers, admin workstations, servers, or broad workstations; lower urgency only when scope matches the recognized maintenance/test population established by the grant evidence.
+- If evidence remains suspicious or unresolved, do related events show broader abuse?
+  - Focus: after confirming `user.id` is the writer, review recent modifying-account activity. !{investigate{"description":"","label":"Recent events associated with the source account","providers":[[{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: compare with activity scoped to the same `winlog.event_data.ObjectGUID`. !{investigate{"description":"","label":"Events associated with the modified GPO","providers":[[{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate scope when the writer or same GPO appears in other GPO abuse, credential access, privilege escalation, or lateral movement; quiet history only narrows scope and cannot close unresolved grant or blast-radius questions.
+- Escalate for unexpected writer/session, companion change, high-impact grant, sensitive scope, or related abuse; close only when the same GPO, writer/session, recovered grants, and scope prove one recognized hardening or restricted-groups workflow; if evidence stays mixed or incomplete, preserve GPO artifacts and escalate.
+
+
+*False positive analysis*
+
+
+- Authorized GPO hardening, restricted-groups maintenance, red-team, or detection-validation can update "gPCMachineExtensionNames" and "GptTmpl.inf". Confirm only when writer/session, GPO object, `winlog.event_data.OpCorrelationID`, recovered template entries, and linked scope match the admin tier, change window, template, or test plan. Quiet history supports but cannot replace that proof; if any anchor diverges, do not close as benign.
+- For exceptions, validate one authorized workflow matching writer SID, GPO object, grant pattern, and linked OU/host scope. Build the exception from that pattern, not broad `event.code`, "gPCMachineExtensionNames", or GPO modification activity.
+
+
+*Related rules*
+
+
+- Scheduled Task Execution at Scale via GPO - 15a8ba77-1c13-4274-88fe-6bd14133861e
+- Startup/Logon Script added to Group Policy Object - 16fac1a1-21ee-4ca6-b720-458e3855d046
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and document writer SID, GPO object, logon/correlation IDs, recovered "GptTmpl.inf", and OU/host scope matching the workflow. Keep exceptions narrow and tied to that stable pattern.
+- If suspicious but unconfirmed, preserve the "5136" event, object and writer/session IDs, `winlog.event_data.OpCorrelationID`, `winlog.computer_name`, exported "GptTmpl.inf", available SYSVOL metadata, linked "4624"/"4648" events, and related activity before containment. Use reversible controls first: restrict affected-GPO edits, limit the writer's GPO admin path, or monitor linked systems during scoping. Disable accounts or roll back GPOs only if follow-on abuse or malicious grants are confirmed.
+- If confirmed malicious, preserve evidence first, remove unauthorized "[Privilege Rights]" or "[Group Membership]" entries, roll the GPO back to known-good state, and verify exported SYSVOL metadata before forcing policy refresh. Use identity/endpoint response to contain the writer account and admin workstation identified by `source.ip` or `winlog.logon.type`; if unavailable, escalate with writer/session, GPO, correlation, and SYSVOL artifacts.
+- Review linked OUs and affected computers before deleting artifacts or forcing "gpupdate"; complete scoping before evidence changes.
+- Harden: restrict GPO edit rights to dedicated admin tiers, retain "5136" auditing, keep security-template baselines, and document abuse variants or visibility gaps for detection engineering.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Audit Directory Service Changes must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-directory-service-changes
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+any where host.os.type == "windows" and event.code: "5136" and
+  winlog.event_data.AttributeLDAPDisplayName: "gPCMachineExtensionNames" and
+  winlog.event_data.AttributeValue: "*827D319E-6EAC-11D2-A4EA-00C04F79F83A*" and
+  winlog.event_data.AttributeValue: "*803E14A0-B4FB-11D0-A0D0-00A0C90F574B*"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Domain or Tenant Policy Modification
+** ID: T1484
+** Reference URL: https://attack.mitre.org/techniques/T1484/
+* Sub-technique:
+** Name: Group Policy Modification
+** ID: T1484.001
+** Reference URL: https://attack.mitre.org/techniques/T1484/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc
new file mode 100644
index 0000000000..214ec54fac
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc
@@ -0,0 +1,126 @@
+[[prebuilt-rule-8-19-24-inbound-connection-to-an-unsecure-elasticsearch-node]]
+=== Inbound Connection to an Unsecure Elasticsearch Node
+
+Identifies Elasticsearch nodes that do not have Transport Layer Security (TLS), and/or lack authentication, and are accepting inbound network connections over the default Elasticsearch port.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* packetbeat-*
+* logs-network_traffic.*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-security.html
+* https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-http-options.html#_send_all_headers
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Tactic: Initial Access
+* Tactic: Reconnaissance
+* Domain: Endpoint
+* Resources: Investigation Guide
+
+*Version*: 108
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Inbound Connection to an Unsecure Elasticsearch Node*
+
+
+Elasticsearch is a powerful search and analytics engine often used for log and data analysis. When improperly configured without TLS or authentication, it becomes vulnerable to unauthorized access. Adversaries can exploit these weaknesses to gain initial access, exfiltrate data, or disrupt services. The detection rule identifies unsecured nodes by monitoring inbound HTTP traffic on the default port, flagging connections lacking authentication headers, thus highlighting potential exploitation attempts.
+
+
+*Possible investigation steps*
+
+
+- Review the source IP address of the inbound connection to determine if it is from a known or trusted entity. Cross-reference with internal asset inventories or threat intelligence sources.
+- Examine the network traffic logs for any unusual patterns or repeated access attempts from the same source IP, which might indicate a brute force or scanning activity.
+- Check for any data exfiltration attempts by analyzing outbound traffic from the Elasticsearch node, focusing on large data transfers or connections to unfamiliar external IPs.
+- Investigate the absence of authentication headers in the HTTP requests to confirm if the Elasticsearch node is indeed misconfigured and lacks proper security controls.
+- Assess the configuration of the Elasticsearch node to ensure that TLS is enabled and authentication mechanisms are properly implemented to prevent unauthorized access.
+- Look for any other alerts or logs related to the same Elasticsearch node or source IP to identify potential coordinated attack activities or previous incidents.
+
+
+*False positive analysis*
+
+
+- Internal monitoring tools or scripts that regularly check Elasticsearch node status without authentication can trigger false positives. Exclude these specific IP addresses or user agents from the rule to reduce noise.
+- Automated backup systems that interact with Elasticsearch nodes without using authentication headers might be flagged. Identify these systems and create exceptions based on their IP addresses or network segments.
+- Development or testing environments where Elasticsearch nodes are intentionally left unsecured for testing purposes can generate alerts. Use network segmentation or specific tags to differentiate these environments and exclude them from the rule.
+- Security scans or vulnerability assessments conducted by internal teams may access Elasticsearch nodes without authentication, leading to false positives. Whitelist the IP ranges used by these security tools to prevent unnecessary alerts.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected Elasticsearch node from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough review of access logs to identify any unauthorized access or data exfiltration attempts, focusing on connections lacking authentication headers.
+- Implement Transport Layer Security (TLS) and enable authentication mechanisms on the Elasticsearch node to secure communications and restrict access to authorized users only.
+- Reset credentials and API keys associated with the Elasticsearch node to prevent further unauthorized access using potentially compromised credentials.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and steps taken to contain the threat.
+- Monitor the network for any signs of continued unauthorized access attempts or related suspicious activity, adjusting detection rules as necessary to capture similar threats.
+- Document the incident, including the response actions taken, and conduct a post-incident review to identify any gaps in security controls and improve future response efforts.
+
+==== Setup
+
+
+This rule requires the addition of port `9200` and `send_all_headers` to the `HTTP` protocol configuration in `packetbeat.yml`. See the References section for additional configuration documentation.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+(data_stream.dataset: network_traffic.http OR (event.category: network_traffic AND network.protocol: http)) AND
+     http.response.status_code:200 AND destination.port:9200 AND network.direction:inbound AND NOT http.response.headers.content-type:"image/x-icon" AND NOT
+    _exists_:http.request.headers.authorization
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Exploit Public-Facing Application
+** ID: T1190
+** Reference URL: https://attack.mitre.org/techniques/T1190/
+* Tactic:
+** Name: 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-incoming-dcom-lateral-movement-via-mshta.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-incoming-dcom-lateral-movement-via-mshta.asciidoc
new file mode 100644
index 0000000000..e9485cd269
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-incoming-dcom-lateral-movement-via-mshta.asciidoc
@@ -0,0 +1,194 @@
+[[prebuilt-rule-8-19-24-incoming-dcom-lateral-movement-via-mshta]]
+=== Incoming DCOM Lateral Movement via MSHTA
+
+Identifies the use of Distributed Component Object Model (DCOM) to execute commands from a remote host, which are launched via the HTA Application COM Object. This behavior may indicate an attacker abusing a DCOM application to move laterally while attempting to evade detection.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-endpoint.events.process-*
+* logs-endpoint.events.network-*
+* logs-windows.sysmon_operational-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://code-white.com/blog/2018-07-lethalhta/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Lateral Movement
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Resources: Investigation Guide
+
+*Version*: 212
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Incoming DCOM Lateral Movement via MSHTA*
+
+
+
+*Investigation steps*
+
+
+- Do recovered source events show remote COM activation of mshta on this host?
+  - Focus: alert `host.id` and `process.entity_id`; recover `process.command_line` plus matching network `source.ip`, `source.port`, `destination.port`, and `network.direction`.
+  - Implication: escalate when the COM-server process receives incoming non-loopback RPC-style TCP from an unconfirmed source; lower only when telemetry and exact confirmation tie source, target, and COM-server launch to recurring distribution or helpdesk activity. Missing source events leave the alert unresolved.
+
+- Is mshta the expected Windows COM server, not a staged or masqueraded copy?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.parent.executable`.
+  - Implication: escalate when mshta runs from a user-writable or non-Windows path, has an unexpected signer, or lacks a service/DCOM-style parent such as "svchost.exe"; Microsoft identity lowers only masquerade risk because source and retrieval still decide the case.
+
+- Do source, account, and logon context support the same confirmed workflow?
+  - Focus: recovered `source.ip`, target-side `user.id`, and session bridge `process.Ext.authentication_id`, `winlog.event_data.TargetLogonId`, and `winlog.event_data.AuthenticationPackageName`.
+  - Implication: escalate when source, account, session type, or auth package conflict with the source-event workflow; lower only when telemetry and exact confirmation identify a legitimate source-to-host relationship. Missing Windows Security telemetry leaves origin and auth method unresolved, not benign.
+
+- Does same-process DNS/connection data show remote script retrieval?
+  - Why: HTA COM can load remote script content into "mshta.exe"; same-process retrieval is direct corroboration.
+  - Focus: same-process DNS `dns.question.name` and `dns.resolved_ip`, then connection `destination.ip` and `destination.port`. !{investigate{"description":"","label":"Network events for the mshta process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: map `dns.question.name` to `dns.resolved_ip` before tying later `destination.ip` to retrieval.
+  - Implication: escalate when mshta resolves or connects to public, rare, or mismatched content hosts; lower only when the destination maps to the same recognized internal or vendor workflow as the source. Missing DNS or connection telemetry leaves retrieval unresolved, not benign.
+
+- Do file artifacts show cached HTA content or staged payloads?
+  - Focus: same-host file events tied to `host.id` and mshta or follow-on `process.entity_id`, especially `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and `file.Ext.original.path`. !{investigate{"description":"","label":"File events for the mshta process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Range: start with the alert window; expand after the first suspicious write to confirm later execution.
+  - Implication: escalate when the chain writes HTA/script/payload content to temp, downloads, ADS-like, systemprofile "INetCache", or extensionless paths, or when the artifact later executes; lower when artifacts stay in one recurring deployment path. Missing file telemetry is unresolved, not benign.
+
+- Does mshta stay in-process or hand off execution?
+  - Why: LethalHTA can run JScript/VBScript, DotNetToJScript, CLR, or beacon code inside "mshta.exe"; absence of child processes does not clear the alert.
+  - Focus: child process starts from recovered mshta `process.entity_id`. !{investigate{"description":"","label":"Child process starts from the mshta process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Library: same-process `dll.path`, `dll.code_signature.subject_name`, `dll.code_signature.trusted`, and `dll.Ext.relative_file_creation_time`. !{investigate{"description":"","label":"Library events for the mshta process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when mshta spawns shells, downloaders, proxy-execution utilities, or loads recent/untrusted libraries from writable or nonstandard paths; narrow only when no follow-on execution appears and earlier source, session, and retrieval fit one recognized workflow. Missing library telemetry leaves in-process payload review unresolved, not benign.
+
+- Do related alerts change scope?
+  - Focus: related lateral-movement, proxy-execution, or follow-on delivery alerts for `host.id` in the prior 48h. !{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"}}
+  - Hint: use the host-scoped transform first; search recovered `source.ip`, `dns.question.name`, or `destination.ip` across other targets only if local evidence remains suspicious or unresolved.
+  - Implication: escalate scope when the host shows adjacent lateral-movement, proxy-execution, or follow-on delivery alerts, or when the source touches additional targets; keep the case local when the alert is isolated and earlier evidence fits one stable workflow.
+
+- Escalate unauthorized DCOM HTA execution when source-event chain, source/session fit, retrieval, artifacts/libraries, child execution, or related-alert scope remain suspicious; close only when pivots bind one recognized host workflow without contradictory retrieval, artifact, or follow-on activity; if answers stay mixed or incomplete, preserve evidence and escalate.
+
+
+*False positive analysis*
+
+
+- Management tooling (software distribution, enrollment, or helpdesk launchers) can legitimately activate the HTA COM object. Confirm `source.ip` is the management host, mshta identity and `process.parent.executable` match that tool, DNS/destination pattern serves it, and artifacts, children, or libraries do not contradict it. Telemetry that cannot prove legitimacy needs change, distribution, asset, or owner confirmation.
+- Do not close on partial context: known admin subnet, Microsoft-signed "mshta.exe", or familiar user alone. If any evidence dimension contradicts the expected workflow, or neither telemetry nor exact confirmation proves it, treat the alert as suspicious or unresolved.
+- Anchor exceptions on the minimum confirmed workflow: recognized `source.ip`, stable `process.parent.executable`, recovered `process.command_line`, specific benign `dns.question.name` or `destination.ip`, and relevant `host.id`. Avoid exceptions on `process.name` of "mshta.exe", incoming high ports, or `user.name` alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and document source, target host, mshta identity, parent context, destination pattern, and artifact evidence confirming the recognized workflow. Create an exception only for the exact pattern confirmed by telemetry and supporting records or owner confirmation.
+- If suspicious but unconfirmed, preserve Timeline source events, mshta identity and command line, remote source and high-port pair, DNS and destination evidence, cached/staged files, child processes, suspicious libraries, and relevant case exports before containment or cleanup.
+- Apply reversible containment first: restrict DCOM or web retrieval between the target and recovered source/destination, increase monitoring on `host.id` and `user.id`, or isolate the endpoint only when retrieval, child execution, or library evidence indicates active payload execution and the host role permits isolation.
+- If confirmed malicious, isolate the target endpoint and contain the recovered source system or account when in scope. Block malicious domains, destinations, and hashes; record process and artifact IDs before killing processes or deleting files.
+- Scope other hosts reached by the same recovered `source.ip`, `dns.question.name`, `destination.ip`, or `process.command_line` pattern before destructive eradication, credential removal, or broad DCOM changes.
+- Eradicate only identified HTA, HTML, script, DLL, cached content, or staged payloads, then remediate the DCOM exposure, application workflow, or credentials that enabled remote execution.
+- Post-incident hardening: restrict DCOM exposure to recognized management paths, keep Windows Firewall or equivalent RPC controls enabled for the host class, limit HTA use to recognized workflows, retain process/network/file/library telemetry, and record SMB/named-pipe delivery if found during scoping.
+
+
+==== 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]
+- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence with maxspan=1m
+  [process where host.os.type == "windows" and event.type == "start" and
+     process.name : "mshta.exe" and process.args : "-Embedding"
+  ] by host.id, process.entity_id
+  [network where host.os.type == "windows" and event.type == "start" and process.name : "mshta.exe" and
+     network.direction : ("incoming", "ingress") and network.transport == "tcp" and
+     source.port > 49151 and destination.port > 49151 and source.ip != "127.0.0.1" and source.ip != "::1"
+  ] by host.id, 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: Distributed Component Object Model
+** ID: T1021.003
+** Reference URL: https://attack.mitre.org/techniques/T1021/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: Mshta
+** ID: T1218.005
+** Reference URL: https://attack.mitre.org/techniques/T1218/005/
+* 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-24/prebuilt-rule-8-19-24-incoming-dcom-lateral-movement-with-mmc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-incoming-dcom-lateral-movement-with-mmc.asciidoc
new file mode 100644
index 0000000000..167453b105
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-incoming-dcom-lateral-movement-with-mmc.asciidoc
@@ -0,0 +1,186 @@
+[[prebuilt-rule-8-19-24-incoming-dcom-lateral-movement-with-mmc]]
+=== Incoming DCOM Lateral Movement with MMC
+
+Identifies the use of Distributed Component Object Model (DCOM) to run commands from a remote host, which are launched via the MMC20 Application COM Object. This behavior may indicate an attacker abusing a DCOM application to move laterally.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-endpoint.events.process-*
+* logs-endpoint.events.network-*
+* logs-windows.sysmon_operational-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://enigma0x3.net/2017/01/05/lateral-movement-using-the-mmc20-application-com-object/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Lateral Movement
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Resources: Investigation Guide
+
+*Version*: 213
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Incoming DCOM Lateral Movement with MMC*
+
+
+
+*Possible investigation steps*
+
+
+- Which Timeline source events define the target MMC instance, spawned child, and remote source?
+  - Why: this asymmetric sequence links incoming "mmc.exe" network activity to a child process, and the alert may not preserve one reliable process identity.
+  - Focus: recover the target MMC network event and child process event, recording target MMC and child `process.entity_id`, `source.ip`, and child `process.command_line`.
+  - Implication: escalate if the chain does not resolve to one incoming MMC process spawning one child; lower suspicion only when it fits a recognized MMC administration source and child, then continue to command and network interpretation.
+- Does the network event fit remote DCOM or RPC traffic into MMC?
+  - Focus: the recovered "mmc.exe" network event: `source.ip`, `source.port`, `destination.port`, `network.direction`, and `network.transport`.
+  - Implication: DCOM-style remote execution is supported by incoming TCP from a non-loopback `source.ip` with both ports in the high RPC range; concern rises when the source is a peer workstation, unrelated server, or unknown management origin.
+- What did MMC execute through MMC20.Application COM automation?
+  - Focus: recovered child `process.executable` and `process.command_line`.
+  - Implication: escalate when MMC launches cmd.exe, PowerShell, script hosts, LOLBins, loaders, or download cradles; lower suspicion only when the exact child command is a recognized MMC snap-in helper or management binary and the source context also fits.
+- Is the child binary identity consistent with the behavior, without treating signer trust as clearance?
+  - Focus: child `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and entity context.
+  - Implication: mismatched PE metadata, user-writable paths, unexpected publishers, or quick follow-on LOLBin execution increases concern; a trusted signer confirms identity only and does not clear remote command execution.
+- Does the target-side user and session fit remote administration from the recovered source?
+  - Focus: child `user.id`, `user.name`, and `user.domain`, compared with the recovered source and target host.
+  - Implication: escalate when the user, service context, or session is unexpected for that target or cannot explain administrative access from the source; lower suspicion when source, identity, and session match a recognized admin or jump-host path.
+- Did the MMC-spawned child launch descendants after execution?
+  - Focus: same-host process events from the child, checking child-of-child `process.parent.entity_id`. !{investigate{"description":"","label":"Processes spawned by MMC on this host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.name","queryType":"phrase","value":"mmc.exe","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the child launches more execution chains; absent descendants keeps the case centered on the recovered remote command, not benign.
+- Did the child make DNS or connection activity?
+  - Focus: same-host network events, checking DNS `dns.question.name` and connection `destination.ip`. !{investigate{"description":"","label":"Network events for MMC on this host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"mmc.exe","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: separate DNS events from connection events and keep the pivot bounded to the alert window. Missing network telemetry is unresolved, not benign.
+  - Implication: escalate when the child resolves rare domains or connects to staging or command infrastructure.
+- Does the recovered source or child command appear on other hosts after local triage stays suspicious?
+  - Focus: same-host alerts for `host.id`. !{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"}}
+  - Hint: if the same account is suspicious, compare same-`user.id` alerts for lateral-movement or credential-access patterns across other hosts. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: broaden only after local evidence remains suspicious or unresolved; use `source.ip` for spread and a distinctive child `process.command_line` fragment for tool reuse.
+  - Implication: expand scope when the same source touches more targets, the same child command appears elsewhere, or same-host alerts show lateral movement or defense evasion; keep the case local when the pattern stays confined and the workflow is otherwise explained.
+
+- Escalate when source identity, incoming high-RPC network shape, child intent, identity/session, or descendant/DNS/destination evidence supports unauthorized MMC20.Application execution; close only when recovered evidence, with external confirmation when telemetry cannot prove intent, binds one exact recognized MMC administration workflow with no contradictory follow-on evidence; mixed or incomplete evidence means preserve and escalate.
+
+
+*False positive analysis*
+
+
+- Remote MMC, server-management automation, or vendor/internal tooling can legitimately trigger this rule when a management host uses DCOM to drive MMC snap-ins or support commands. Confirm the recovered `source.ip` is a recognized admin, jump, or tooling host; child `process.executable` and `process.command_line` show the exact console/helper action; `user.id` or `user.name` fits that path; child `process.hash.sha256` or `process.code_signature.subject_name` is stable when tooling is involved; and descendant, DNS, and connection evidence stays quiet. If inventory or change records are unavailable, telemetry-only closure still requires current evidence to prove the exact workflow; prior recurrence of the same `source.ip`, child command, and `host.id` pattern is corroboration, not closure by itself.
+- Before creating an exception, anchor it on the minimum confirmed workflow pattern: recognized `source.ip`, child `process.executable`, stable `process.command_line`, expected `user.id` or `user.name`, and the relevant `host.id` scope. Avoid exceptions on `process.parent.name` of "mmc.exe" or high RPC ports alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, record the recovered `source.ip`, child `process.executable`, child `process.command_line`, `user.id` or `user.name`, and target `host.id` that established the management workflow, then reverse any temporary containment. Create an exception only if the same pattern recurs consistently across prior alerts.
+- If suspicious but unconfirmed, preserve a case export of the Timeline source events, the target MMC and child process instance IDs, child command line, source socket, and DNS/destination indicators before containment or cleanup.
+- If suspicious but unconfirmed, apply reversible containment tied to the evidence, such as temporary DCOM/RPC restrictions from the recovered `source.ip` to the target `host.id`; isolate the host only when the child command or follow-on activity indicates payload execution and the host role can tolerate it.
+- If confirmed malicious, first preserve the target MMC instance, child command, recovered source, descendant processes, and malicious DNS or destination indicators. Then isolate the target host and contain the recovered source system if it is in response scope; terminate processes or delete artifacts only after preservation and scoping.
+- Review other hosts touched by the same recovered `source.ip` or child `process.command_line` pattern before terminating additional processes or removing artifacts so scoping completes before evidence is destroyed.
+- Eradicate only scripts, binaries, persistence, or configuration changes identified during the investigation, then remediate the account, source host, or remote administration path that allowed the DCOM execution.
+- Post-incident hardening: keep Windows Firewall enabled, disable unnecessary Microsoft Management Console inbound access, restrict DCOM/RPC between workstations, limit remote administrative rights to recognized jump hosts, and record the evidence and control changes 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/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by host.id with maxspan=1m
+ [network where host.os.type == "windows" and event.type == "start" and process.name : "mmc.exe" and source.port >= 49152 and
+  destination.port >= 49152 and source.ip != "127.0.0.1" and source.ip != "::1" and
+  network.direction : ("incoming", "ingress") and network.transport == "tcp"
+ ] by process.entity_id
+ [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "mmc.exe"
+ ] by process.parent.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: Distributed Component Object Model
+** ID: T1021.003
+** Reference URL: https://attack.mitre.org/techniques/T1021/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: MMC
+** ID: T1218.014
+** Reference URL: https://attack.mitre.org/techniques/T1218/014/
+* 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-24/prebuilt-rule-8-19-24-interactive-logon-by-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-interactive-logon-by-an-unusual-process.asciidoc
new file mode 100644
index 0000000000..d76083a65e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-interactive-logon-by-an-unusual-process.asciidoc
@@ -0,0 +1,156 @@
+[[prebuilt-rule-8-19-24-interactive-logon-by-an-unusual-process]]
+=== Interactive Logon by an Unusual Process
+
+Identifies interactive logon attempt with alternate credentials and by an unusual process. Adversaries may create a new token to escalate privileges and bypass access controls.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1134/002/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 109
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Interactive Logon by an Unusual Process*
+
+
+*Possible investigation steps*
+
+
+- Did Advapi create an interactive logon for a different target identity?
+  - Focus: `winlog.logon.type`, `winlog.event_data.LogonProcessName`, `winlog.event_data.SubjectUserSid`, `winlog.event_data.TargetUserSid`, and `host.id`.
+  - Implication: escalate when Advapi creates a different Target session without recognized credential-switch use; lower suspicion only for bounded runas or helper use on this host. Subject initiated the action; Target received the session or token.
+- Which process requested the alternate-credential session?
+  - Focus: `process.executable`, `process.name`, `process.pid`, `winlog.event_data.SubjectUserName`, and `winlog.event_data.SubjectDomainName`.
+  - Implication: escalate when the requester is user-writable, temporary, renamed, or unrelated to credential switching; lower suspicion only for System32 runas.exe or a recognized helper tied to the same Subject. Process identity alone does not clear token creation.
+- Did the Target session create privileged or linked-token access?
+  - Focus: `winlog.event_data.TargetUserSid`, `winlog.event_data.TargetLogonId`, `winlog.event_data.TargetLinkedLogonId`, `winlog.event_data.ElevatedToken`, and `winlog.event_data.ImpersonationLevel`.
+  - Implication: escalate on a privileged or unusual Target account, elevated token, linked session, or impersonation-capable token. Keep unresolved when the Target cannot be tied to the requesting Subject and process; a recognized requester does not clear elevated Target token state.
+- Did explicit-credential records show who supplied Target credentials?
+  - Focus: same-host 4648 records using `winlog.event_data.SubjectLogonId`; read `winlog.event_data.TargetUserName`, `winlog.event_data.TargetDomainName`, `winlog.event_data.TargetServerName`, and `source.ip`.
+  - Hint: make-token tooling may leave only Advapi, different Subject/Target SIDs, and Target session fields; do not require endpoint command-line evidence before escalation. !{investigate{"description":"","label":"Explicit-credential events from the subject session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when 4648 shows the same Subject session presenting Target credentials to an unexpected server or non-local origin. Local or absent `source.ip` can occur in make-token cases and must be weighed with requester, identity pair, and token state; missing Security telemetry is unresolved, not benign.
+- Did the created Target session show follow-on success or authentication-method signals?
+  - Focus: same-host 4624 and 4634 records using `winlog.event_data.TargetLogonId`; read `winlog.event_data.TargetUserSid`, `winlog.event_data.AuthenticationPackageName`, and `source.ip`.
+  - Implication: escalate on unexpected authentication package use, repeated successful session activity, or a non-local origin that contradicts local workflow; absent or local source details should be weighed with Target-token evidence. Missing 4624/4634 telemetry is unresolved, not benign.
+    - !{investigate{"description":"","label":"Target logon records for the created session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.TargetLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Target logoff records for the created session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4634","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.TargetLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+- What activity is tied to the created Target logon session?
+  - Focus: same-host events carrying `winlog.event_data.TargetLogonId`, especially process, privilege, or authentication records tied to the Target identity. !{investigate{"description":"","label":"Events for the created target logon session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.TargetLogonId}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.logon.id","queryType":"phrase","value":"{{winlog.event_data.TargetLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the Target session performs privileged operations, starts unexpected processes, or chains authentication; no follow-on telemetry narrows activity only when the requester, identity pair, and token state are otherwise explained.
+- If local evidence remains suspicious or unresolved, do related alerts change scope?
+  - Focus: recent alerts for the same `host.id`, Subject SID, and Target SID.
+    - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Alerts associated with the subject identity","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}],[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Alerts associated with the target identity","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetUserSid","queryType":"phrase","value":"{{winlog.event_data.TargetUserSid}}","valueType":"string"}],[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{winlog.event_data.TargetUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when related alerts show credential access, privilege escalation, persistence, or lateral movement tied to the host or either identity; quiet alert history cannot close unresolved token/session evidence.
+- Escalate on unauthorized Subject-to-Target token creation; close only when the identity pair, requester, Target token, and Security records all bind to one recognized workflow; if mixed, preserve records and use related alerts plus recent session activity to scope the case.
+
+
+*False positive analysis*
+
+
+- Recognized runas, enterprise PAM or credential-broker helpers, and authorized assessment can trigger this rule from monitored admin hosts. Confirm `process.executable`, Subject and Target identities, `host.id`, and explicit-credential or session records bind to the same workflow or validation scope; contradictory Target token details block benign closure.
+- Build exceptions only from the minimum confirmed pattern, such as `process.executable` plus `winlog.event_data.SubjectUserSid`, `winlog.event_data.TargetUserSid`, and a bounded `host.id` or host group. Avoid exceptions on `process.name`, `user.name`, or the Target account alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, document the evidence categories, reverse temporary containment, and create only the narrow exception described above.
+- If suspicious but unconfirmed, export the alert and surrounding Windows Security records, preserve the requesting process image and Subject-to-Target session context, and collect the referenced executable before containment.
+- Apply reversible containment first: restrict the affected account or host session, increase monitoring on the involved `host.id` and identities, and weigh host criticality before isolation.
+- If confirmed malicious, preserve the executable referenced by `process.executable`, session records, and Subject/Target identifiers, then contain involved hosts or accounts and invalidate active sessions.
+- Reset or rotate Target credentials only when compromise or unauthorized use is supported; treat Subject as the operator or requesting context before disabling it.
+- Eradicate only confirmed token-abuse tooling or credential material, review local privilege assignments that allowed the session, and retain Windows Security events needed to reconstruct Subject-to-Target token creation.
+
+==== 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 winlog.event_data.LogonProcessName : "Advapi*" and
+ winlog.logon.type == "Interactive" and winlog.event_data.SubjectUserSid : ("S-1-5-21*", "S-1-12-*") and
+ winlog.event_data.TargetUserSid : ("S-1-5-21*", "S-1-12-*")  and process.executable : "C:\\*" and
+ not startswith~(winlog.event_data.SubjectUserSid, winlog.event_data.TargetUserSid) and
+ not process.executable :
+            ("?:\\Windows\\System32\\winlogon.exe",
+             "?:\\Windows\\System32\\wininit.exe",
+             "?:\\Program Files\\*.exe",
+             "?:\\Program Files (x86)\\*.exe",
+             "?:\\Windows\\SysWOW64\\inetsrv\\w3wp.exe",
+             "?:\\Windows\\System32\\inetsrv\\w3wp.exe",
+             "?:\\Windows\\SysWOW64\\msiexec.exe")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Access Token Manipulation
+** ID: T1134
+** Reference URL: https://attack.mitre.org/techniques/T1134/
+* Sub-technique:
+** Name: Create Process with Token
+** ID: T1134.002
+** Reference URL: https://attack.mitre.org/techniques/T1134/002/
+* Sub-technique:
+** Name: Make and Impersonate Token
+** ID: T1134.003
+** Reference URL: https://attack.mitre.org/techniques/T1134/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-krbtgt-delegation-backdoor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-krbtgt-delegation-backdoor.asciidoc
new file mode 100644
index 0000000000..ab16c735fc
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-krbtgt-delegation-backdoor.asciidoc
@@ -0,0 +1,147 @@
+[[prebuilt-rule-8-19-24-krbtgt-delegation-backdoor]]
+=== KRBTGT Delegation Backdoor
+
+Identifies the modification of the msDS-AllowedToDelegateTo attribute to KRBTGT. Attackers can use this technique to maintain persistence to the domain by having the ability to request tickets for the KRBTGT service.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://skyblue.team/posts/delegate-krbtgt
+* https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0026_windows_audit_user_account_management.md
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Use Case: Active Directory Monitoring
+* Data Source: Active Directory
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 214
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating KRBTGT Delegation Backdoor*
+
+
+
+*Possible investigation steps*
+
+
+- What account was changed, and what krbtgt delegation value did the alert preserve?
+  - Focus: alert 4738 evidence in `winlog.event_data.TargetSid`, `winlog.event_data.TargetUserName`, `winlog.event_data.TargetDomainName`, `winlog.event_data.AllowedToDelegateTo`, and `winlog.computer_name`.
+  - Implication: Escalate when the target now lists a krbtgt service target such as "krbtgt/DOMAIN"; lower suspicion only when the target, value, and controller match a time-boxed security validation or emergency delegation repair explicitly naming krbtgt, which is not routine delegation.
+
+- Who initiated the account change?
+  - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, and `winlog.event_data.SubjectLogonId`.
+  - Implication: Escalate when a human admin, newly introduced service identity, or unexpected controller-local context made the change; lower suspicion only when the same stable tier-0 identity owns this exact delegation-maintenance path.
+
+- What source and authentication method created the modifying session?
+  - Focus: authentication events on the same `host.id` where `winlog.event_data.TargetLogonId` equals alert `winlog.event_data.SubjectLogonId`; review `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Authentication events for the modifying session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: missing authentication telemetry, or absent `source.ip` on local/service sessions, is unresolved, not benign; review same-session 4648 records when credential-source context matters. !{investigate{"description":"","label":"Explicit-credential events from the modifying session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: Escalate for an unusual source, remote-interactive access, unexpected NTLM, or explicit credentials; lower suspicion when the session maps to the expected tier-0 admin path for this controller.
+
+- Did surrounding directory changes prepare, repeat, or roll back the krbtgt delegation?
+  - Focus: surrounding 4738 records for the same `winlog.event_data.TargetSid`, plus 5136 records on the same `winlog.computer_name` and modifying subject/session; use `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeLDAPDisplayName`, and `winlog.event_data.AttributeValue` to identify the affected object and value.
+  - Hint: reconstruct the burst from same-target 4738 and same-controller directory-service changes; if 5136 grouping is thin, use `winlog.record_id` order on the same controller plus subject/session and object DN. Absent 5136 evidence leaves prerequisite and rollback context unresolved, not benign.
+    - !{investigate{"description":"","label":"4738 changes for this delegation target","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4738","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetSid","queryType":"phrase","value":"{{winlog.event_data.TargetSid}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4738","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"5136 directory changes by this modifying session","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Implication: Escalate when `winlog.event_data.AttributeLDAPDisplayName` and `winlog.event_data.AttributeValue` show delegation-enabling changes, repeated msDS-AllowedToDelegateTo writes, or no rollback; prompt removal narrows the persistence window but does not clear actor or session intent.
+
+- Does the same actor or target touch other delegation-relevant accounts in the case window?
+  - Focus: run this only if earlier answers are suspicious or unresolved; search 4738 and 5136 records for the same modifying subject/session or `winlog.event_data.TargetSid`, then compare `winlog.event_data.TargetUserName`, `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeLDAPDisplayName`, and `winlog.event_data.AttributeValue`.
+  - Implication: Broaden scope when the same actor or target appears in additional delegation writes across objects or controllers; keep it narrow when changes stay confined to one exact target and resolved maintenance path. !{investigate{"description":"","label":"Delegation-sensitive changes by this actor","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4738","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+
+- Escalate when a non-routine actor/session adds krbtgt delegation, supporting directory changes show setup, the value remains, or same-actor/target scope expands; close only when the modified account, krbtgt value, actor/session, source/authentication context, surrounding changes, rollback, and scope all align with one tightly controlled authorized workflow; preserve raw 4738, authentication, and directory-change evidence and escalate when findings stay mixed or incomplete.
+
+
+*False positive analysis*
+
+
+- Authorized security validation or emergency delegation repair can trigger this rule only when krbtgt delegation is the explicit planned action. Confirm the target (`winlog.event_data.TargetSid` plus `winlog.event_data.AllowedToDelegateTo`), actor/session (`winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectLogonId`, and recovered authentication context), controller, and surrounding attribute evidence all align. If change records are unavailable, telemetry-only closure must still bind one exact workflow with no contradictions; prior benign recurrence strengthens confidence but is not required.
+- Do not close generic service onboarding, migration, or constrained-delegation cutover as benign unless outside confirmation explicitly names krbtgt delegation and telemetry matches that exact target, actor, session, and controller path. A normal service-delegation explanation that does not account for the krbtgt value is incomplete.
+- Before creating an exception, validate that the same `winlog.event_data.SubjectUserSid`, `winlog.event_data.TargetSid`, exact `winlog.event_data.AllowedToDelegateTo`, `winlog.computer_name`, and recovered session pattern identify the authorized workflow across prior benign cases or a tightly controlled test plan. Build the exception from that minimum confirmed pattern, and avoid exceptions on "krbtgt", event 4738, or "msDS-AllowedToDelegateTo" alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, document the actor, target account, krbtgt value, controller, recovered session context, and surrounding delegation-change pattern before reversing temporary containment. Create an exception only if that same pattern is stable across prior benign cases.
+- If suspicious but unconfirmed, first export the alert, raw 4738 record, matching authentication events, and surrounding 4738 or 5136 records. Preserve the modified account, krbtgt value, actor/session, source/auth context, and rollback evidence before reversible containment such as heightened monitoring or temporary delegation-administration restrictions.
+- If confirmed malicious, preserve the same identity, session, and directory-change evidence first, then restrict or disable the modifying account. Restrict the modified target only when it was intentionally backdoored or used for follow-on Kerberos abuse. Contain the recovered source host when session evidence identifies one, or hand off the preserved evidence set to Active Directory or incident response.
+- After containment, review recent 4738 and 5136 records for the same actor, target, and controller before cleanup. Remove the unauthorized krbtgt value from the `msDS-AllowedToDelegateTo` attribute, roll back related delegation-prerequisite changes identified in the same change set, and verify clean replication across domain controllers.
+- If ticket abuse or broader Active Directory compromise is confirmed, activate the domain-compromise plan, including the required double reset of krbtgt after scoping and coordination with directory owners.
+- Post-incident hardening: restrict delegation administration and SeEnableDelegationPrivilege to dedicated tier-0 identities, keep Audit User Account Management plus supporting 5136, 4624, and 4648 visibility on domain controllers, and document any recurring benign validation pattern for future triage.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Audit User Account Management must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-user-account-management
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+iam where host.os.type == "windows" and event.code == "4738" and winlog.event_data.AllowedToDelegateTo : "*krbtgt*"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Steal or Forge Kerberos Tickets
+** ID: T1558
+** Reference URL: https://attack.mitre.org/techniques/T1558/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubelet-api-connection-attempt-to-internal-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubelet-api-connection-attempt-to-internal-ip.asciidoc
new file mode 100644
index 0000000000..5fd03891da
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubelet-api-connection-attempt-to-internal-ip.asciidoc
@@ -0,0 +1,172 @@
+[[prebuilt-rule-8-19-24-kubelet-api-connection-attempt-to-internal-ip]]
+=== Kubelet API Connection Attempt to Internal IP
+
+Detects network connection attempts to the Kubernetes Kubelet API port (10250/10255) on internal IP ranges from Linux hosts. This rule focuses on common request and scripting utilities (curl, wget, python, node, etc.) and executions from world-writable or ephemeral paths (/tmp, /var/tmp, /dev/shm, /var/run), which are frequently abused during container and cluster lateral movement.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* auditbeat-*
+* logs-auditd_manager.auditd-*
+* 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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1021/
+* https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/
+
+*Tags*: 
+
+* Domain: Endpoint
+* Domain: Container
+* Domain: Kubernetes
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Lateral Movement
+* Tactic: Discovery
+* Data Source: Elastic Defend
+* Data Source: Auditd Manager
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubelet API Connection Attempt to Internal IP*
+
+
+This alert indicates a process on a Linux host attempted to connect to port 10250 (Kubelet API) on an internal or
+loopback IP address, including IPv4 private ranges and IPv6 localhost. Kubelet access is commonly abused to enumerate
+pods, retrieve logs, or execute commands on nodes when authentication or network controls are weak.
+
+
+*Possible investigation steps*
+
+
+- Review the initiating process (`process.*`) and its executable path; prioritize processes running from `/tmp`,
+  `/var/tmp`, `/dev/shm`, or `/var/run`, and suspicious interpreters or downloaders.
+- Determine whether the destination IP is the local node, another node, or a management host, and whether connectivity to
+  10250 is expected for this workload/user.
+- Correlate with process argument telemetry for HTTP URLs, kubelet endpoints (e.g., `/pods`, `/runningpods`, `/exec`), and
+  subsequent Kubernetes API audit activity or credential access.
+
+
+*False positive analysis*
+
+
+- Approved troubleshooting (SRE/cluster operator) sessions that validate Kubelet reachability on the node.
+- In-cluster agents that legitimately scrape or query the Kubelet (confirm vendor, image, and deployment).
+
+
+*Response and remediation*
+
+
+- Restrict pod-to-node access to 10250 using network policies/security groups where possible.
+- Rotate and revoke any exposed Kubernetes credentials and investigate for follow-on cluster discovery or execution.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+
+*Auditd Manager: emitting network connection telemetry*
+
+
+This rule is written against `event.category:network` events. Elastic Defend provides this natively. For Auditd Manager,
+you typically need to audit network-related syscalls (for example `connect`) and rely on the integration/pipeline to map
+those syscall events into ECS-like network events.
+
+If you are not seeing `event.category:network` for Auditd Manager data, add syscall audit rules for network connections.
+The example below is a starting point and may need to be adjusted for your environment and noise tolerance:
+
+```
+
+*64-bit*
+
+-a always,exit -F arch=b64 -S connect -S accept -S accept4 -S sendto -S recvfrom -k netconn
+
+
+*32-bit (if applicable)*
+
+-a always,exit -F arch=b32 -S connect -S accept -S accept4 -S sendto -S recvfrom -k netconn
+```
+
+After enabling, validate that events include `destination.ip`, `destination.port`, and a populated `process.*` context.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+network where host.os.type == "linux" and event.type == "start" and event.category == "network" and network.direction == "egress" and 
+  event.action in ("connected-to", "connection_attempted") and (destination.port == 10250 or destination.port == 10255) and
+  cidrmatch(
+    destination.ip,
+    "127.0.0.0/8",
+    "10.0.0.0/8",
+    "172.16.0.0/12",
+    "192.168.0.0/16",
+    "169.254.0.0/16",
+    "100.64.0.0/10",
+    "::1/128",
+    "fc00::/7",
+    "fe80::/10"
+  ) and
+  (
+    process.name in ("curl", "wget", "nc", "ncat", "netcat", "socat", "openssl", "perl", "busybox") or 
+    process.name like ".*" or process.executable like "/*/.*" or 
+    process.name like ("python*", "ruby*", "node*", "java*", "lua*", "apache*", "php*", "nginx", "httpd*", "lighttpd", "caddy", "mongrel_rails", "gunicorn", 
+                       "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn", 
+                       "daphne", "twistd", "yaws", "webfsd", "flask", "rails", "mongrel", "catalina.sh", "hiawatha", "lswsctrl") or
+    process.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/var/run/*", "/home/*", "/run/user/*", "/busybox/*")
+  )
+
+----------------------------------
+
+*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/
+* 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-24/prebuilt-rule-8-19-24-kubernetes-admission-webhook-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-admission-webhook-created-or-modified.asciidoc
new file mode 100644
index 0000000000..48e585002d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-admission-webhook-created-or-modified.asciidoc
@@ -0,0 +1,141 @@
+[[prebuilt-rule-8-19-24-kubernetes-admission-webhook-created-or-modified]]
+=== Kubernetes Admission Webhook Created or Modified
+
+Detects creation, modification, or deletion of Kubernetes MutatingWebhookConfigurations or ValidatingWebhookConfigurations by non-system identities. Admission webhooks intercept every API request matching their rules before persistence, giving an attacker powerful capabilities: injecting malicious sidecars into every new pod via a mutating webhook, blocking security tooling deployments via a validating webhook, or silently exfiltrating pod specifications to an external server. Webhook manipulation is a stealthy persistence and defense evasion technique because the webhook configuration itself looks benign in kubectl output while actively modifying or intercepting all matching Kubernetes API traffic.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes Admission Webhook Created or Modified*
+
+
+Admission webhooks can mutate or validate resources before they are persisted. A malicious webhook can inject sidecars,
+alter securityContext, block defensive workloads, or exfiltrate pod specs. This rule alerts on allowed changes to
+MutatingWebhookConfiguration and ValidatingWebhookConfiguration objects by identities outside common system patterns.
+
+
+*Possible investigation steps*
+
+
+- Confirm the webhook resource and operation:
+  - kubernetes.audit.objectRef.resource and kubernetes.audit.verb
+  - kubernetes.audit.objectRef.name (the webhook configuration name)
+- Attribute the actor and access path:
+  - user.name (human vs service account vs node identity)
+  - source.ip and user_agent.original
+  - In cloud-managed clusters, map the identity to IAM/Entra principal data present in kubernetes.audit.user.extra.*.
+- Extract the webhook destination and review for external exfiltration:
+  - kubernetes.audit.requestObject.webhooks.clientConfig.url (suspicious when pointing to the public internet)
+  - kubernetes.audit.requestObject.webhooks.clientConfig.service.* (in-cluster service; still validate namespace/name)
+- Review impact-driving webhook settings:
+  - failurePolicy (e.g., Ignore can make malicious webhooks stealthier by avoiding obvious outages)
+  - namespaceSelector / objectSelector targeting (e.g., excluding kube-system while targeting everything else)
+  - rules.operations and rules.resources (e.g., CREATE pods is consistent with broad sidecar injection)
+  - sideEffects, timeoutSeconds, matchPolicy, reinvocationPolicy
+- Scope blast radius and follow-on activity:
+  - Hunt for pods created/updated after the webhook change that include unexpected containers, initContainers, env vars,
+    volume mounts, or securityContext changes.
+  - Check for concurrent RBAC changes, token creation, or secret access from the same identity and source IP.
+
+
+*False positive analysis*
+
+
+- GitOps upgrades or controller installs can legitimately change admission webhooks. Validate the change against:
+  - approved Helm/Git commits, change tickets, and expected controller namespaces
+  - known controller identities (cert-manager, Gatekeeper, Kyverno, service mesh controllers)
+
+
+*Response and remediation*
+
+
+- If unauthorized, revert or delete the webhook configuration from a known-good source (GitOps/Helm), then block the
+  actor identity and rotate any credentials it used.
+- If the webhook targeted pod creation, assume workload impact: identify affected namespaces/workloads, redeploy from
+  trusted manifests/images, and validate that new pods are no longer being mutated.
+- If an external clientConfig.url was used, treat it as potential data exfiltration and review egress/DNS logs for the
+  destination around the alert window.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+kubernetes.audit.objectRef.resource:("mutatingwebhookconfigurations" or "validatingwebhookconfigurations") and
+kubernetes.audit.verb:("create" or "update" or "patch" or "delete") and
+kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and 
+user.name:(* and not 
+  (system\:kube-controller-manager or
+  system\:kube-scheduler or
+  system\:serviceaccount\:kube-system\:* or
+  eks\:* or aksService or masterclient or nodeclient or
+  system\:serviceaccount\:gke-managed-system\:* or
+  system\:serviceaccount\:cert-manager\:* or
+  system\:serviceaccount\:gatekeeper-system\:* or
+  system\:serviceaccount\:kyverno\:* or
+  system\:serviceaccount\:*\:*-operator)
+) and
+kubernetes.audit.objectRef.name:(* and not (pod-identity-webhook or vpc-resource-mutating-webhook or eks-* or gke-*))
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Event Triggered Execution
+** ID: T1546
+** Reference URL: https://attack.mitre.org/techniques/T1546/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc
new file mode 100644
index 0000000000..1d29f697ee
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc
@@ -0,0 +1,176 @@
+[[prebuilt-rule-8-19-24-kubernetes-and-cloud-credential-path-access-via-process-arguments]]
+=== Kubernetes and Cloud Credential Path Access via Process Arguments
+
+Flags Linux process executions whose arguments reference high-value Kubernetes service-account material, kubeconfig or node PKI paths, or common cloud and SSH credential files, when invoked via typical file-reading utilities or from ephemeral directories. Useful for spotting in-cluster and hybrid credential theft early.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* auditbeat-*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1552/
+* https://kubernetes.io/docs/concepts/security/service-accounts/
+
+*Tags*: 
+
+* Data Source: Auditd Manager
+* Data Source: Elastic Defend
+* Domain: Endpoint
+* Domain: Kubernetes
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes and Cloud Credential Path Access via Process Arguments*
+
+
+Confirm whether the process user and parent chain are expected to read the matched path (for example a CI job,
+bootstrap script, or kubelet). Reconstruct the full command line and check for piping, encoding, or exfiltration
+patterns immediately after the read.
+
+
+*Possible investigation steps*
+
+
+- Map the workload or login session to an identity; prioritize events from nodes, jump hosts, or pods with mounted
+  service account tokens.
+- Correlate with file, network, and Kubernetes audit telemetry for secret reads, token minting, or API calls using
+  harvested material.
+
+
+*Response and remediation*
+
+
+- Rotate affected service account tokens, kubeconfigs, and cloud keys when access was unauthorized; review RBAC and
+  secret mount policy for the workload.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Requires **Elastic Defend** and/or **Auditd Manager** process telemetry (`logs-endpoint.events.process*`,
+`logs-auditd_manager.auditd-*`, `auditbeat-*`) with command-line argument capture for exec events.
+
+
+*Elastic Defend*
+
+Install the Elastic Defend integration via Fleet on Linux hosts and use a policy that collects process events with
+arguments.
+
+
+*Auditd Manager*
+
+Deploy Auditd Manager and ensure execve (or equivalent process) auditing is enabled so `process.args` and
+`process.executable` populate for monitored binaries.
+
+See https://docs.elastic.co/integrations/auditd_manager
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+host.os.type:linux and event.category:process and event.action:(exec or executed) and 
+(
+  process.name:(
+    busybox or cat or head or tail or more or less or sed or awk or 
+    find or grep or ls or whereis or cp or mv or ln or
+    curl or wget or scp or rsync or tar or zip or gzip or
+    base64 or xxd or od or dd or tee or strings or xargs or jq or yq or
+    openssl or ssh or sftp or nc or ncat or netcat or socat or
+    python* or perl* or ruby* or node or php* or lua* or .*
+  ) or
+  process.args:(
+    cat or head or tail or more or less or sed or awk or 
+    find or grep or cp or mv or curl or wget or base64 or 
+    tar or scp or dd or strings or xargs
+  ) or
+  process.executable:(/tmp/* or /var/tmp/* or /dev/shm/* or /home/* or /run/user/*)
+) and process.args:(
+  "/var/run/secrets/kubernetes.io/serviceaccount/token" or
+  "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt" or
+  "/var/run/secrets/eks.amazonaws.com/serviceaccount/token" or
+  "/var/run/secrets/azure/tokens/azure-identity-token" or
+  "/var/run/secrets/tokens/azure-identity-token" or
+  "/var/lib/kubelet/kubeconfig" or
+  "/etc/kubernetes/admin.conf" or
+  "/etc/kubernetes/pki/ca.key" or
+  "/etc/kubernetes/pki/apiserver-kubelet-client.key" or
+  "/var/lib/kubelet/pki/kubelet-client-current.pem" or
+  "/etc/rancher/k3s/k3s.yaml" or
+  "/etc/shadow" or
+  */.ssh/id_rsa or
+  */root/.ssh/id_ed25519 or
+  */.ssh/id_ecdsa or
+  */.aws/credentials or
+  */.aws/cli/cache/*.json or
+  */.aws/sso/cache/*.json or
+  */.azure/accessTokens.json or
+  */.azure/azureProfile.json or
+  */.azure/msal_token_cache.json or
+  */.config/gcloud/application_default_credentials.json or
+  */.config/gcloud/credentials.db or
+  */.config/gcloud/access_tokens.db or
+  */.config/gcloud/legacy_credentials or
+  */.kube/config or
+  */.docker/config.json
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Unsecured Credentials
+** ID: T1552
+** Reference URL: https://attack.mitre.org/techniques/T1552/
+* Sub-technique:
+** Name: Credentials In Files
+** ID: T1552.001
+** Reference URL: https://attack.mitre.org/techniques/T1552/001/
+* Technique:
+** Name: Steal Application Access Token
+** ID: T1528
+** Reference URL: https://attack.mitre.org/techniques/T1528/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-api-request-impersonating-privileged-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-api-request-impersonating-privileged-identity.asciidoc
new file mode 100644
index 0000000000..a3c6f0f42e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-api-request-impersonating-privileged-identity.asciidoc
@@ -0,0 +1,111 @@
+[[prebuilt-rule-8-19-24-kubernetes-api-request-impersonating-privileged-identity]]
+=== Kubernetes API Request Impersonating Privileged Identity
+
+Detects Kubernetes API requests where a user is impersonating a privileged cluster identity such as system:kube-controller-manager, system:admin, system:anonymous, or a member of the system:masters group. These identities have broad cluster-wide permissions including unrestricted access to all secrets, the ability to create tokens for any service account, schedule pods on any node, and modify RBAC policies. An attacker impersonating system:masters gains full cluster-admin equivalent access, while impersonating system:kube-controller-manager grants access to every secret in every namespace and the ability to mint service account tokens for lateral movement.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes API Request Impersonating Privileged Identity*
+
+
+Compare the real actor (user.name, groups, source.ip, user_agent.original) with impersonated
+fields (kubernetes.audit.impersonatedUser.username, kubernetes.audit.impersonatedUser.groups). Confirm whether
+impersonation is authorized for that principal and target identity.
+
+
+*Possible investigation steps*
+
+
+- Review kubernetes.audit.requestURI, kubernetes.audit.verb, and kubernetes.audit.objectRef for the scope of the
+  operation performed while impersonating.
+- Determine whether the real user or service account should have impersonate rights against the impersonated user
+  or group; inspect RBAC impersonate verb bindings and any recent changes.
+- Correlate with adjacent audit activity (secrets, tokens, RBAC writes, CSR approval) from the same source identity.
+- Hunt for repeated impersonation across namespaces or rapid pivoting after the event.
+
+
+*Response and remediation*
+
+
+- Revoke or tighten impersonate permissions for unexpected identities; rotate credentials for any account that may
+  have abused impersonation.
+- If unauthorized, treat as cluster-wide credential risk: review secrets exposure, issued tokens, and RBAC drift;
+  engage incident response per policy.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:kubernetes.audit_logs and 
+kubernetes.audit.impersonatedUser.username:(* and not ("eks-event-service:event-controller" or eks\:*)) and 
+kubernetes.audit.annotations.authorization_k8s_io/decision:allow and 
+kubernetes.audit.verb:(create or delete or get or list or patch or update) and 
+(kubernetes.audit.impersonatedUser.username:(admin or cluster-admin or kubernetes-admin or "system:admin" or "system:anonymous" or "system:apiserver" or "system:kube-controller-manager" or "system:kube-proxy" or "system:kube-scheduler" or "system:volume-scheduler" or system\:node\:* or system\:serviceaccount\:kube-system\:*) or kubernetes.audit.impersonatedUser.groups:(cluster-admin or "system:cluster-admins" or "system:masters")) and 
+not user.name:(acsService or aksService or masterclient or nodeclient or "system:kube-controller-manager" or "system:kube-scheduler" or arn\:aws\:iam\:*\:role/aws-service-role* or arn\:aws\:sts\:*\:assumed-role/AWSServiceRoleForAmazonEKS* or arn\:aws\:sts\:*\:assumed-role/AWSServiceRoleForAmazonEKSNodegroup* or eks\:* or system\:node\:* or system\:serviceaccount\:kube-system\:*)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Access Token Manipulation
+** ID: T1134
+** Reference URL: https://attack.mitre.org/techniques/T1134/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Access Token Manipulation
+** ID: T1134
+** Reference URL: https://attack.mitre.org/techniques/T1134/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-api-server-proxying-request-to-kubelet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-api-server-proxying-request-to-kubelet.asciidoc
new file mode 100644
index 0000000000..17772ad04a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-api-server-proxying-request-to-kubelet.asciidoc
@@ -0,0 +1,148 @@
+[[prebuilt-rule-8-19-24-kubernetes-api-server-proxying-request-to-kubelet]]
+=== Kubernetes API Server Proxying Request to Kubelet
+
+Detects non-system identities using the Kubernetes nodes/proxy API to proxy requests through the API server directly to a node's Kubelet. The nodes/proxy subresource allows any principal with this RBAC permission to reach the Kubelet API on any worker node without needing direct network access or Kubelet TLS certificates. Through this proxy path, an attacker can list all pod specifications including environment variable secrets, read Kubelet configuration and PKI material, retrieve container logs, and access running pod metadata across all workloads on the target node. Monitoring and health check endpoints such as /metrics, /healthz, and /stats are excluded to reduce noise from legitimate observability tooling.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://kubernetes.io/docs/concepts/cluster-administration/proxies/
+* https://attack.mitre.org/techniques/T1552/007/
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Tactic: Lateral Movement
+* Tactic: Discovery
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes API Server Proxying Request to Kubelet*
+
+
+Review the user.name, source.ip, and user_agent.original fields to determine who initiated the proxy request and from
+where. Examine kubernetes.audit.requestURI to identify which Kubelet endpoint was proxied — the path after /proxy/
+maps directly to the Kubelet API path the attacker accessed.
+
+
+*Possible investigation steps*
+
+
+- Check the proxied Kubelet path in requestURI to determine attacker intent:
+  - /proxy/pods — pod spec enumeration including environment variable secrets
+  - /proxy/exec or /proxy/run — command execution inside containers on that node
+  - /proxy/configz — Kubelet configuration and authentication settings
+  - /proxy/runningpods — active workload enumeration
+  - /proxy/containerLogs — log harvesting for leaked credentials
+- Identify how the principal obtained nodes/proxy permission by reviewing RBAC bindings
+- Check if a ServiceAccount token was created shortly before via the TokenRequest API - this 
+  indicates the attacker minted a token specifically for this access.
+- Review whether the same principal accessed multiple nodes via proxy in a short window, which
+  indicates systematic lateral movement across the cluster.
+
+
+*False positive analysis*
+
+
+- Prometheus, Datadog, and other monitoring agents scrape /metrics and /stats via nodes/proxy.
+  These endpoints are excluded by default. If additional monitoring paths generate noise, add
+  them to the requestURI exclusion.
+- Cluster administration tools that inspect node health via the proxy API can match. Correlate
+  with change management windows and verify the source identity.
+
+
+*Response and remediation*
+
+
+- Immediately review the RBAC role granting nodes/proxy permission and determine if the binding
+  is authorized. Remove unauthorized bindings.
+- If /proxy/pods was accessed, assume all environment variable secrets on that node are compromised.
+  Rotate affected credentials, API keys, and database passwords.
+- If /proxy/exec or /proxy/run was accessed, treat the target node as compromised. Isolate the node,
+  review running containers for unauthorized modifications, and check for persistence mechanisms.
+- Audit all ClusterRoles for nodes/proxy permission — this is a powerful privilege that should be
+  restricted to infrastructure automation only, never granted to application service accounts.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+kubernetes.audit.objectRef.subresource:"proxy" and
+kubernetes.audit.objectRef.resource:"nodes" and
+not kubernetes.audit.requestURI:(*metrics* or *healthz* or *stats/summary* or *elastic-agent* or *configz*) and
+not user.name:(
+  system\:kube-controller-manager or
+  system\:kube-scheduler or
+  system\:serviceaccount\:kube-system\:* or
+  system\:node\:* or
+  eks\:* or aksService
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Escape to Host
+** ID: T1611
+** Reference URL: https://attack.mitre.org/techniques/T1611/
+* Tactic:
+** Name: Lateral Movement
+** ID: TA0008
+** Reference URL: https://attack.mitre.org/tactics/TA0008/
+* Technique:
+** Name: Use Alternate Authentication Material
+** ID: T1550
+** Reference URL: https://attack.mitre.org/techniques/T1550/
+* Sub-technique:
+** Name: Application Access Token
+** ID: T1550.001
+** Reference URL: https://attack.mitre.org/techniques/T1550/001/
+* 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-24/prebuilt-rule-8-19-24-kubernetes-client-certificate-signing-request-created-or-approved.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-client-certificate-signing-request-created-or-approved.asciidoc
new file mode 100644
index 0000000000..dab337d6c2
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-client-certificate-signing-request-created-or-approved.asciidoc
@@ -0,0 +1,146 @@
+[[prebuilt-rule-8-19-24-kubernetes-client-certificate-signing-request-created-or-approved]]
+=== Kubernetes Client Certificate Signing Request Created or Approved
+
+Detects creation or approval of a Kubernetes CertificateSigningRequest (CSR) by a non-system identity. Attackers who have gained cluster access can submit a CSR with a privileged Common Name such as system:kube-controller-manager or system:masters, then approve it themselves to obtain a long-lived client certificate. Unlike service account tokens which expire in hours, client certificates persist until they expire or the cluster CA is rotated, providing durable access that survives pod termination, token revocation, and RBAC changes. On non-EKS clusters, the signed certificate allows the attacker to authenticate as the privileged identity from anywhere without needing cluster network access, making it one of the most persistent backdoor mechanisms available in Kubernetes.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/
+* https://attack.mitre.org/techniques/T1098/
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Privilege Escalation
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes Client Certificate Signing Request Created or Approved*
+
+
+Identify the actor (`user.name`, groups), client (`user_agent.original`), and `source.ip`. Confirm whether the
+principal is expected to create or approve CSRs. Review `kubernetes.audit.requestURI` and, when audit level captures
+request bodies, the CSR `spec` (requested signer, usages, and requested identity / Common Name).
+
+
+*Extracting the Certificate Common Name*
+
+
+For create events, "kubernetes.audit.requestObject.spec.request" holds the base64-encoded PEM certificate signing request.
+Decode that value to PEM, then inspect the CSR subject (for example with OpenSSL’s CSR subject view) to read the
+requested Common Name (CN). 
+
+Known base64 substrings that often appear inside the encoded request for high-risk identities:
+
+- `c3lzdGVtOm1hc3Rlcn` — `system:masters`
+- `c3lzdGVtOmt1YmUtY29udHJvbGxlci1tYW5hZ2Vy` — `system:kube-controller-manager`
+- `c3lzdGVtOmFkbWlu` — `system:admin`
+
+Priority CNs that usually indicate privilege escalation intent:
+
+- `system:masters` (cluster-admin group)
+- `system:kube-controller-manager` (broad control-plane–style access, including secrets and token minting)
+- `system:kube-scheduler` (scheduling across the cluster)
+- `system:kube-proxy` (node/network–adjacent access)
+- Any CN that matches an existing ClusterRoleBinding subject name
+
+
+*Possible investigation steps*
+
+
+- Compare the CSR name and extracted CN against approved PKI or bootstrap processes.
+- Determine whether the same identity both created and approved or patched the CSR in a short window, which matches
+  self-approval abuse.
+- Review `kubernetes.audit.objectRef` and subsequent authentication or API activity from unusual networks.
+- Correlate with RBAC changes, secret access, or TokenRequest activity that preceded CSR activity.
+
+
+*Response and remediation*
+
+
+- If malicious, deny further approval, delete or deny the CSR per incident policy, revoke or rotate cluster signing
+  trust if the CA or signer was abused, and invalidate issued credentials.
+- Remove excessive RBAC that allows `certificatesigningrequests` create/update/patch or approval for untrusted
+  identities; enforce signer restrictions and approved issuers where supported.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"kubernetes.audit_logs" and 
+kubernetes.audit.objectRef.resource:"certificatesigningrequests" and
+kubernetes.audit.verb:("create" or "update" or "patch") and
+kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and
+not user.name:(
+  system\:kube-controller-manager or
+  system\:kube-scheduler or
+  system\:node\:* or
+  system\:serviceaccount\:kube-system\:* or
+  eks\:* or aksService
+)
+
+----------------------------------
+
+*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 Container Cluster Roles
+** ID: T1098.006
+** Reference URL: https://attack.mitre.org/techniques/T1098/006/
+* 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-coredns-or-kube-dns-configuration-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-coredns-or-kube-dns-configuration-modified.asciidoc
new file mode 100644
index 0000000000..7b98f717cb
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-coredns-or-kube-dns-configuration-modified.asciidoc
@@ -0,0 +1,110 @@
+[[prebuilt-rule-8-19-24-kubernetes-coredns-or-kube-dns-configuration-modified]]
+=== Kubernetes CoreDNS or Kube-DNS Configuration Modified
+
+Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace. These ConfigMaps control cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service DNS names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server, database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every pod in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS configuration changes are rare in normal operations and any unexpected modification should be investigated immediately.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/
+* https://coredns.io/plugins/rewrite/
+* https://attack.mitre.org/techniques/T1565/001/
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes CoreDNS or Kube-DNS Configuration Modified*
+
+
+Identify who performed the change (user.name, groups), from where (source.ip), and which ConfigMap was modified.
+If request/response capture is available, review the changed Corefile content for upstream redirection, wildcard
+rewrites, or unexpected forward/proxy targets.
+
+
+*Possible investigation steps*
+
+
+- Confirm the actor is authorized to modify kube-system DNS configuration and whether the change aligns with a change window.
+- Review the ConfigMap diff for added rewrite rules, hosts entries, or forwarding to external or unexpected internal IPs.
+- Correlate with follow-on suspicious activity such as secret reads, token minting, or RBAC modifications.
+- Check for cluster-wide symptoms: service connection failures, TLS errors, or sudden endpoint changes across namespaces.
+
+
+*Response and remediation*
+
+
+- Revert the ConfigMap to a known-good version and restart DNS pods if required by your deployment.
+- Restrict RBAC permissions that allow update/patch/delete on kube-system DNS ConfigMaps and investigate the source identity.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"kubernetes.audit_logs" and 
+kubernetes.audit.objectRef.resource:"configmaps" and
+kubernetes.audit.objectRef.name:("coredns" or "kube-dns" or "coredns-custom") and
+kubernetes.audit.objectRef.namespace:"kube-system" and
+kubernetes.audit.verb:("update" or "patch" or "delete") and
+kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and 
+not user.name:(
+  system\:serviceaccount\:kube-system\:coredns or
+  system\:serviceaccount\:kube-system\:kube-dns or
+  system\:node\:* or
+  eks\:* or aksService or acsService
+)
+
+----------------------------------
+
+*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-24/prebuilt-rule-8-19-24-kubernetes-ephemeral-container-added-to-pod.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-ephemeral-container-added-to-pod.asciidoc
new file mode 100644
index 0000000000..f2db529ca2
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-ephemeral-container-added-to-pod.asciidoc
@@ -0,0 +1,112 @@
+[[prebuilt-rule-8-19-24-kubernetes-ephemeral-container-added-to-pod]]
+=== Kubernetes Ephemeral Container Added to Pod
+
+Detects allowed updates to the pods/ephemeralcontainers subresource by a non-system identity. Ephemeral containers are commonly used for debugging (kubectl debug) but can also be abused to inject tooling into a running pod, access mounted secrets, and execute commands in the target pod context. Attackers with sufficient RBAC may use ephemeral containers to escalate privileges, move laterally, or establish persistence without deploying a new workload.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* 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 Kubernetes Ephemeral Container Added to Pod*
+
+
+Ephemeral containers allow adding a container to an existing pod for troubleshooting. When abused, they can be used to
+gain interactive access to a workload, read sensitive files, and run tools that were not present in the original image.
+
+
+*Possible investigation steps*
+
+
+- Review the actor (user.name, groups), source.ip, and user_agent.original and confirm the identity is authorized to use ephemeral containers.
+- Inspect kubernetes.audit.objectRef (namespace, name) to identify the targeted pod and workload owner.
+- If request bodies are captured, review the ephemeral container image, command, and securityContext for privilege indicators.
+- Correlate with follow-on audit activity such as pod exec, secret reads, TokenRequest, or RBAC modifications.
+
+
+*Response and remediation*
+
+
+- If unauthorized, remove excessive RBAC that grants update/patch on pods/ephemeralcontainers and rotate exposed credentials.
+- Quarantine or redeploy impacted workloads and hunt for additional compromised pods or identities.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"kubernetes.audit_logs" and 
+kubernetes.audit.objectRef.resource:"pods" and
+kubernetes.audit.objectRef.subresource:"ephemeralcontainers" and
+kubernetes.audit.verb:("update" or "patch") and
+kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and
+not user.name:(
+  system\:node\:* or
+  system\:serviceaccount\:kube-system\:*
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Escape to Host
+** ID: T1611
+** Reference URL: https://attack.mitre.org/techniques/T1611/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Container Administration Command
+** ID: T1609
+** Reference URL: https://attack.mitre.org/techniques/T1609/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-multi-resource-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-multi-resource-discovery.asciidoc
new file mode 100644
index 0000000000..482f7174cd
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-multi-resource-discovery.asciidoc
@@ -0,0 +1,121 @@
+[[prebuilt-rule-8-19-24-kubernetes-multi-resource-discovery]]
+=== Kubernetes Multi-Resource Discovery
+
+Adversaries who land credentials in a 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 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. It is less typical for steady-state controllers, which usually touch a narrow set of resources repeatedly. This rule highlights that cross-resource burst from a single client fingerprint within a one-minute bucket so analysts can separate routine automation from potential discovery and permission reconnaissance ahead of follow-on actions.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1613/
+* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Discovery
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes Multi-Resource Discovery*
+
+
+The rule groups Kubernetes audit `get`/`list` events on namespaces, pods, roles, and clusterroles into one-minute windows 
+per `user.name`, `source.ip`, `user_agent.original`, and flags windows where three or more distinct resource types appear. 
+That combination is consistent with someone sketching cluster layout and privilege structure rather than touching a single 
+resource type. **Allowed and denied** authorizations are both included: failures still signal probing and validate which 
+object types the caller attempted to reach.
+
+
+*Possible investigation steps*
+
+
+- Pivot on `Esql.time_interval` and the same identity or IP in raw audit logs to see ordering (e.g. namespaces first,
+  then roles, then pods) and whether calls succeeded.
+- Review `Esql.decisions` and namespaces touched; correlate with RBAC for that identity to see if scope matches a
+  known job or breaks least-privilege expectations.
+- Hunt for follow-on activity: secret/configmap reads, rolebinding changes, pod exec, anonymous or unusual user agents.
+- Baseline automation: CI, GitOps, and some monitoring agents can read several resource types during sync; exclude
+  known service accounts or source networks if noisy.
+
+
+*False positive analysis*
+
+
+- Platform operators or runbooks that reconcile RBAC and workload state may legitimately span these resource types in
+  a short window; tune by user, IP allowlist, or user agent when documented.
+- Some installers briefly query namespaces, pods, and roles during upgrades—correlate with change windows.
+
+
+*Response and remediation*
+
+
+- If malicious, revoke or rotate the implicated credentials, review and tighten RBAC, and inspect for data access or
+  persistence established after the burst.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-kubernetes.audit_logs-* metadata _id, _index, _version
+| eval Esql.time_interval = date_trunc(1 minute, @timestamp)
+| where event.dataset == "kubernetes.audit_logs"
+    and event.action in ("get", "list")
+    and kubernetes.audit.objectRef.resource in ("namespaces", "nodes", "pods", "roles", "configmaps", "serviceaccounts", "clusterroles", "clusterrolebindings", "rolebindings")
+    and source.ip is not null and user.name IS NOT NULL
+    and not to_string(source.ip) in ("127.0.0.1", "::1")
+    and not user.name rlike """(system:serviceaccount:kube-system:|eks:|system:kube-|arn:aws:sts::.*:assumed-role/AWSServiceRoleForAmazonEKS/|system:serviceaccount:kube-system:azure|system:node:aks-default|aksService).*""" 
+    and not kubernetes.audit.user.username in ("system:serviceaccount:flux-system:kustomize-controller", "system:serviceaccount:flux-system:helm-controller", "system:serviceaccount:flux-system:source-controller", "system:serviceaccount:security:trivy-operator")
+| stats
+    Esql.unique_resources = count_distinct(kubernetes.audit.objectRef.resource),
+    Esql.enumerated_resources = values(kubernetes.audit.objectRef.resource),
+    Esql.enumerated_namespaces = values(kubernetes.audit.objectRef.namespace),
+    Esql.decisions = values(`kubernetes.audit.annotations.authorization_k8s_io/decision`)
+  by user.name, kubernetes.audit.user.username, source.ip, user_agent.original, Esql.time_interval
+| where Esql.unique_resources >= 3
+| keep Esql.*, kubernetes.audit.user.username, user.name, 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-24/prebuilt-rule-8-19-24-kubernetes-pod-exec-cloud-instance-metadata-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-pod-exec-cloud-instance-metadata-access.asciidoc
new file mode 100644
index 0000000000..b16c08087e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-pod-exec-cloud-instance-metadata-access.asciidoc
@@ -0,0 +1,139 @@
+[[prebuilt-rule-8-19-24-kubernetes-pod-exec-cloud-instance-metadata-access]]
+=== Kubernetes Pod Exec Cloud Instance Metadata Access
+
+Detects Kubernetes pod exec sessions whose decoded command line references cloud instance metadata endpoints or equivalent hostnames and paths. Workloads that reach the link-local metadata IP, AWS IMDS paths, GCP computeMetadata, Azure IMDS token routes, or encoded variants are often attempting to harvest role credentials, tokens, or instance attributes from the underlying node or hypervisor boundary. That behavior is high risk in multi-tenant and regulated environments because it can expose short-lived cloud credentials to code running inside a container. The rule classifies a coarse cloud target label and whether the string looks like credential retrieval versus lighter reconnaissance.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1552/005/
+* https://hardenedsecurity.io/blog/aws-imds-vulnerabilities-and-mitigations/
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Domain: Cloud
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Tactic: Execution
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes Pod Exec Cloud Instance Metadata Access*
+
+
+This alert fires when an audited exec requestURI, after URL decoding and command reconstruction, matches patterns
+associated with instance metadata services across AWS, GCP, and Azure. Use it to catch interactive or scripted access
+from inside a pod to metadata surfaces that should usually be blocked by network policy or not needed by application
+code.
+
+
+*Possible investigation steps*
+
+
+- Confirm the Kubernetes identity that performed exec: user name, groups, impersonation, source IP, and user agent.
+- Map the pod and namespace to a workload owner, image digest, and entrypoint; determine whether the container should
+  ever call metadata endpoints.
+- Inspect Esql.cloud_target and Esql.is_credential_theft in the alert document and expand the timeline for the same
+  identity for secret reads, IAM changes, or data egress.
+- Correlate with cloud audit logs on the node identity or instance profile for STS or token issuance around the event
+  time.
+
+
+*False positive analysis*
+
+
+- Break-glass debugging from platform engineers may include curl to 169.254.169.254; validate change tickets and
+  bastion use.
+- Misconfigured agents or bootstrap scripts in bespoke images can touch metadata during startup; baseline approved
+  images and tune exclusions narrowly.
+
+
+*Response and remediation*
+
+
+- If unauthorized, terminate the session, isolate the workload, revoke or rotate instance and workload credentials that
+  could have been read, and tighten RBAC on pods exec plus network policies that deny link-local metadata from pods.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM logs-kubernetes.audit_logs-* metadata _id, _index, _version
+| WHERE kubernetes.audit.objectRef.subresource == "exec"
+  AND kubernetes.audit.requestURI LIKE "*command=*"
+| EVAL decoded_uri = URL_DECODE(kubernetes.audit.requestURI)
+| GROK decoded_uri "%{DATA}/exec\\?%{DATA:raw_commands}&(?:container|stdin|stdout|stderr)=%{GREEDYDATA}"
+| EVAL command = REPLACE(raw_commands, "command=", "")
+| EVAL command = REPLACE(command, "&", " ")
+| EVAL Esql.executed_command = REPLACE(command, "\\+", " ")
+| WHERE Esql.executed_command IS NOT NULL 
+  AND Esql.executed_command RLIKE """.*(169\.254\.169\.254|2852039166|0xa9fea9fe|/latest/api/token|/latest/meta-data|/latest/user-data|/latest/dynamic/instance-identity|computeMetadata/v1|metadata\.google\.internal|metadata/identity/oauth2/token|metadata/instance).*"""
+| EVAL Esql.cloud_target = CASE(
+    Esql.executed_command RLIKE """.*(169\.254\.169\.254|2852039166|0xa9fea9fe|/latest/meta-data|/latest/api/token|/latest/user-data|/latest/dynamic).*""", "AWS_IMDS",
+    Esql.executed_command RLIKE """.*(computeMetadata/v1|metadata\.google\.internal).*""", "GCP_METADATA",
+    Esql.executed_command RLIKE """.*metadata/identity/oauth2/token.*""", "AZURE_IMDS",
+    "UNKNOWN"
+  )
+| EVAL Esql.is_credential_theft = CASE(
+    Esql.executed_command RLIKE """.*(security-credentials|/api/token|oauth2/token|service-accounts/.*/token).*""", "yes",
+    "recon"
+  )
+| KEEP *
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Unsecured Credentials
+** ID: T1552
+** Reference URL: https://attack.mitre.org/techniques/T1552/
+* Sub-technique:
+** Name: Cloud Instance Metadata API
+** ID: T1552.005
+** Reference URL: https://attack.mitre.org/techniques/T1552/005/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Container Administration Command
+** ID: T1609
+** Reference URL: https://attack.mitre.org/techniques/T1609/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-pod-exec-potential-reverse-shell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-pod-exec-potential-reverse-shell.asciidoc
new file mode 100644
index 0000000000..2d86e0cdd7
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-pod-exec-potential-reverse-shell.asciidoc
@@ -0,0 +1,121 @@
+[[prebuilt-rule-8-19-24-kubernetes-pod-exec-potential-reverse-shell]]
+=== Kubernetes Pod Exec Potential Reverse Shell
+
+Flags exec into a pod when the URL-decoded command payload resembles reverse-shell or bind-shell one-liners invocation patterns. Legitimate debug sessions sometimes use similar building blocks, but together these patterns align with post-exploitation interactive access and command-and-control.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1609/
+* https://attack.mitre.org/techniques/T1059/
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Execution
+* Tactic: Command and Control
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes Pod Exec Potential Reverse Shell*
+
+
+The rule inspects Kubernetes audit exec requestURI values, URL-decodes them, parses the command query fragment, and 
+matches high-signal shell and socket idioms often used to obtain a allback shell from inside a container.
+
+
+*Possible investigation steps*
+
+
+- Identify the actor (kubernetes.audit.user.username, groups, impersonation), source IP, and user agent
+  (human kubectl vs automation).
+- Resolve the target namespace, pod, and container from kubernetes.audit.objectRef.* and correlate with
+  workload ownership and change tickets.
+- Pull the raw and decoded URI from the alert document and replay the inferred command in a sandbox only if policy
+  allows—otherwise rely on audit and platform logs.
+- Hunt nearby events from the same identity: secret reads, pods/exec to other workloads, RoleBinding
+  changes, or anonymous API use.
+
+
+*False positive analysis*
+
+
+- Security training, CTF-style images, or vendor diagnostics may include bash redirection or /dev/tcp examples;
+  baseline approved images and break-glass accounts.
+- Some observability or mesh sidecars use socat or sockets in ways that could overlap; validate container image and
+  command lineage.
+
+
+*Response and remediation*
+
+
+- If malicious, terminate the exec session, isolate the workload or node, rotate credentials reachable from the
+  pod, and revoke pods/exec for the abused principal unless strictly required.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM logs-kubernetes.audit_logs-* metadata _id, _index, _version
+| WHERE kubernetes.audit.objectRef.subresource == "exec"
+  AND kubernetes.audit.requestURI LIKE "*command=*"
+| EVAL decoded_uri = URL_DECODE(kubernetes.audit.requestURI)
+| GROK decoded_uri "%{DATA}/exec\\?%{DATA:raw_commands}&(?:container|stdin|stdout|stderr)=%{GREEDYDATA}"
+| EVAL command = REPLACE(raw_commands, "command=", "")
+| EVAL command = REPLACE(command, "&", " ")
+| EVAL Esql.executed_command = REPLACE(command, "\\+", " ")
+| WHERE Esql.executed_command IS NOT NULL 
+| WHERE Esql.executed_command IS NOT NULL AND command RLIKE """.*(/dev/tcp/|/dev/udp/|zsh/net/tcp|zsh/net/udp|nc\s+-e|ncat\s+-e|netcat\s+-e|nc\s.*\s-c\s|mkfifo|socat\s.*exec|socat\s.*pty|bash\s+-i\s+>&|0>&1|>&\s*/dev/tcp|import\s+socket.*connect|import\s+pty.*spawn|socket\.socket.*connect|IO::Socket::INET|fsockopen|TCPSocket\.new|/inet/tcp/).*""" AND 
+ // local service health check patterns
+  NOT command RLIKE """.*/dev/tcp/(localhost|127\.0\.0\.1)/(8080|8443|9090|3000|5000|8888|80|443).*"""
+| KEEP *
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Container Administration Command
+** ID: T1609
+** Reference URL: https://attack.mitre.org/techniques/T1609/
+* 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-24/prebuilt-rule-8-19-24-kubernetes-pod-exec-sensitive-file-or-credential-path-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-pod-exec-sensitive-file-or-credential-path-access.asciidoc
new file mode 100644
index 0000000000..598e775686
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-pod-exec-sensitive-file-or-credential-path-access.asciidoc
@@ -0,0 +1,149 @@
+[[prebuilt-rule-8-19-24-kubernetes-pod-exec-sensitive-file-or-credential-path-access]]
+=== Kubernetes Pod Exec Sensitive File or Credential Path Access
+
+Detects Kubernetes pod exec sessions whose decoded command line references high-value host or in-cluster paths and material types: mounted service account or platform tokens, kubelet and control-plane configuration areas, host identity stores, root dot-directories for cloud and kubeconfig material, common private-key and keystore extensions, process environment dumps, and configuration filenames suggestive of embedded secrets. The intent is to catch interactive or scripted access that often precedes lateral movement, privilege escalation, or credential theft from the node or workload boundary. A narrow exclusion ignores benign reads of resolv.conf. The query also labels an access_type bucket to speed triage without altering the detection predicates you validated.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1552/001/
+* https://attack.mitre.org/techniques/T1552/007/
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Tactic: Execution
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes Pod Exec Sensitive File or Credential Path Access*
+
+
+This alert ties Kubernetes audit exec events to reconstructed command text that matches sensitive path and filename
+patterns. Use the Esql.access_type field to prioritize: IRSA token paths, default Kubernetes service account tokens,
+other mounted secrets, certificates and keystores, Kubernetes static config, kubelet state, host passwd or shadow,
+user home credential stores, and proc environ scraping.
+
+
+*Possible investigation steps*
+
+
+- Identify the Kubernetes user, groups, impersonation, source IP, and user agent for the exec caller.
+- Map objectRef namespace, pod, and container to an owning team, image digest, and change history.
+- Compare Esql.executed_command against known runbooks; capture follow-on audit activity such as additional execs,
+  secret reads at the API layer, or RBAC changes.
+- If host-level paths appear, determine whether the workload runs privileged, with hostPath mounts, or on nodes where
+  break-glass access is expected.
+
+
+*False positive analysis*
+
+
+- Diagnostic images and vendor agents sometimes cat resolv.conf or kubeconfig-like paths; the rule excludes resolv.conf
+  but other matches may still be legitimate—baseline stable automation identities.
+- Training containers that deliberately demonstrate passwd reads can trigger; scope exceptions to those images and
+  namespaces.
+
+
+*Response and remediation*
+
+
+- If malicious, end the exec session, isolate the pod or node, rotate any credentials that could have been read,
+  review and tighten pods exec RBAC and admission controls, and inspect for persistence added after the session.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-kubernetes.audit_logs-* metadata _id, _index, _version
+| WHERE kubernetes.audit.objectRef.subresource == "exec"
+  AND kubernetes.audit.requestURI LIKE "*command=*"
+| EVAL decoded_uri = URL_DECODE(kubernetes.audit.requestURI)
+| GROK decoded_uri "%{DATA}/exec\\?%{DATA:raw_commands}&(?:container|stdin|stdout|stderr)=%{GREEDYDATA}"
+| EVAL command = REPLACE(raw_commands, "command=", "")
+| EVAL command = REPLACE(command, "&", " ")
+| EVAL Esql.executed_command = REPLACE(command, "\\+", " ")
+| WHERE Esql.executed_command IS NOT NULL 
+  AND Esql.executed_command RLIKE """.*(/var/run/secrets/|/etc/kubernetes/|/var/lib/kubelet/|/etc/shadow|/etc/passwd|/etc/sudoers|(/root|/home/[^/]+)/\.(ssh|aws|azure|kube|config/gcloud)|\.p12|\.pem|\.key|\.jks|\.keystore|/etc/.*\.conf.*(password|secret|key|token|credential)|/proc/.*/environ).*"""
+  AND NOT Esql.executed_command RLIKE """.*/etc/resolv\.conf.*"""
+| EVAL Esql.access_type = CASE(
+    Esql.executed_command RLIKE """.*/var/run/secrets/eks\.amazonaws\.com.*""", "AWS_IRSA_TOKEN",
+    Esql.executed_command RLIKE """.*/var/run/secrets/azure/tokens/.*""", "AZURE_WORKLOAD_IDENTITY_TOKEN",
+    Esql.executed_command RLIKE """.*/var/run/secrets/tokens/gcp-ksa/.*""", "GCP_WORKLOAD_IDENTITY_TOKEN",
+    Esql.executed_command RLIKE """.*/var/run/secrets/kubernetes\.io/serviceaccount/token.*""", "K8S_SA_TOKEN",
+    Esql.executed_command RLIKE """.*/var/run/secrets/.*""", "MOUNTED_SECRET",
+    Esql.executed_command RLIKE """.*\.(p12|pem|key|jks|keystore).*""", "CERTIFICATE_OR_KEY",
+    Esql.executed_command RLIKE """.*/etc/kubernetes/.*""", "K8S_CONFIG",
+    Esql.executed_command RLIKE """.*/var/lib/kubelet/.*""", "KUBELET_CONFIG",
+    Esql.executed_command RLIKE """.*/etc/shadow.*""", "HOST_CREDENTIALS",
+    Esql.executed_command RLIKE """.*/etc/passwd.*""", "USER_ENUMERATION",
+    Esql.executed_command RLIKE """.*/etc/sudoers.*""", "SUDOERS_ACCESS",
+    Esql.executed_command RLIKE """.*(/root|/home)/\.(ssh|aws|azure|kube|config/gcloud).*""", "USER_CREDENTIALS",
+    Esql.executed_command RLIKE """.*/proc/.*/environ.*""", "PROCESS_ENV_SECRETS",
+    Esql.executed_command RLIKE """.*/etc/.*\.conf.*(password|secret|key|token|credential).*""", "EMBEDDED_CONFIG_SECRET",
+    "OTHER_SENSITIVE"
+  )
+| KEEP *
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Unsecured Credentials
+** ID: T1552
+** Reference URL: https://attack.mitre.org/techniques/T1552/
+* Sub-technique:
+** Name: Credentials In Files
+** ID: T1552.001
+** Reference URL: https://attack.mitre.org/techniques/T1552/001/
+* Sub-technique:
+** Name: Container API
+** ID: T1552.007
+** Reference URL: https://attack.mitre.org/techniques/T1552/007/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Container Administration Command
+** ID: T1609
+** Reference URL: https://attack.mitre.org/techniques/T1609/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-pod-exec-with-curl-or-wget-to-https.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-pod-exec-with-curl-or-wget-to-https.asciidoc
new file mode 100644
index 0000000000..47c4a06772
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-pod-exec-with-curl-or-wget-to-https.asciidoc
@@ -0,0 +1,125 @@
+[[prebuilt-rule-8-19-24-kubernetes-pod-exec-with-curl-or-wget-to-https]]
+=== Kubernetes Pod Exec with Curl or Wget to HTTPS
+
+Detects pod or attach exec API calls where the decoded request query implies **curl** or wget fetching an **https** URL. Attackers with permission to exec into workloads often run one-liners to stage tooling, pull scripts or binaries, or exfiltrate data over HTTPS—activity that should be rare compared to shells, debuggers, or expected health checks. The rule decodes the audit requestURI, reconstructs a readable command string from repeated command parameters, and applies **noise filters** for common cluster health and OIDC/JWKS endpoints so benign automation is less likely to alert.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1609/
+* https://attack.mitre.org/techniques/T1105/
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Execution
+* Tactic: Command and Control
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes Pod Exec with Curl or Wget to HTTPS*
+
+
+Kubernetes audit logs record exec (and similar attach) calls on requestURI, including URL-encoded
+command segments. This rule URL-decodes the URI, extracts the query portion into a single string, and 
+flags curl or wget combined with https, excluding several ommon health, localhost, and OIDC/JWKS patterns.
+
+
+*Possible investigation steps*
+
+
+- Confirm who may exec into the target namespace: review kubernetes.audit.user.username, groups, impersonation, and
+  source.ip / user_agent.original (kubectl, CI, webhooks).
+- Map the pod (kubernetes.audit.objectRef.name) and workload owner; retrieve the exact decoded URI from
+  Esql.decoded_uri and the reconstructed Esql.command in the alert.
+- Search for adjacent audit events from the same identity: secret reads, additional execs, RBAC changes, or anonymous
+  access.
+- If malicious, revoke credentials used for exec, review RoleBindings for **`pods/exec`**, and inspect the pod
+  filesystem or snapshot for dropped artifacts.
+
+
+*False positive analysis*
+
+
+- Approved runbooks or support sessions may use kubectl exec with curl/wget to test egress or download vendor tools;
+  document break-glass identities and tune exclusions.
+- Some cluster components use HTTPS to **kubernetes.default.svc** or **.well-known** endpoints; the rule attempts to
+  filter those—expand the exclusion list if your platform uses additional first-party URLs.
+
+
+*Response and remediation*
+
+
+- Rotate any secrets accessible from the pod, cordon or delete the workload if compromised, and tighten RBAC so only
+  required principals retain **`pods/exec`** on sensitive namespaces.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM logs-kubernetes.audit_logs-* metadata _id, _index, _version
+| WHERE kubernetes.audit.objectRef.subresource == "exec"
+  AND kubernetes.audit.requestURI LIKE "*command=*"
+| EVAL decoded_uri = URL_DECODE(kubernetes.audit.requestURI)
+| GROK decoded_uri "%{DATA}/exec\\?%{DATA:raw_commands}&(?:container|stdin|stdout|stderr)=%{GREEDYDATA}"
+| EVAL command = REPLACE(raw_commands, "command=", "")
+| EVAL command = REPLACE(command, "&", " ")
+| EVAL Esql.executed_command = REPLACE(command, "\\+", " ")
+| WHERE Esql.executed_command IS NOT NULL 
+  AND Esql.executed_command RLIKE """.*(curl.*https|wget.*https).*"""
+  AND NOT Esql.executed_command RLIKE """.*(/api/v1/health|/healthz|/readyz|/livez|127\.0\.0\.1|localhost|/openid/v1/jwks|/openid-connect/certs|/.well-known/openid-configuration|/.well-known/jwks\.json|kubernetes\.default\.svc).*"""
+| KEEP *
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Container Administration Command
+** ID: T1609
+** Reference URL: https://attack.mitre.org/techniques/T1609/
+* 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-rapid-secret-get-activity-against-multiple-objects.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-rapid-secret-get-activity-against-multiple-objects.asciidoc
new file mode 100644
index 0000000000..f77934d41d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-rapid-secret-get-activity-against-multiple-objects.asciidoc
@@ -0,0 +1,114 @@
+[[prebuilt-rule-8-19-24-kubernetes-rapid-secret-get-activity-against-multiple-objects]]
+=== Kubernetes Rapid Secret GET Activity Against Multiple Objects
+
+This rule detects an unusual volume of Kubernetes API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within a defined lookback window. This can indicate credential access or in-cluster reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. Failed get requests are also included, as they may reveal RBAC boundaries, confirm the existence of targeted secrets, or reflect automated probing activity.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1552/007/
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes Rapid Secret GET Activity Against Multiple Objects*
+
+
+This rule surfaces clusters of `get` operations on the `secrets` API where the same identity and client path
+(`user.name`, `source.ip`, `user_agent.original`) touch several different secret names within the rule lookback window.
+**Allowed and denied** outcomes are included: successful reads may indicate harvesting; repeated **forbidden** or
+**unauthorized** responses can still signal reconnaissance, RBAC probing, or scripted spray against secret names that
+exist in the cluster.
+
+
+*Investigation steps*
+
+
+- Inspect `Esql.outcome` for a mix of allow vs deny and whether failures cluster on sensitive namespaces.
+- Map the identity to RBAC and namespace scope; review `Esql.secrets_names` and `Esql.namespaces` for high-value
+  targets (tokens, registry credentials, TLS bundles, application secrets).
+- Pivot on the same `source.ip` and user for follow-on API activity (exec, pod create, role changes, broad `list` on secrets).
+- Validate against expected automation (CI, GitOps, backup, in-cluster controllers) before treating as malicious.
+
+
+*False positives*
+
+
+- Startup, Helm, or controllers may legitimately touch many secrets in one window; tune by user, namespace, or IP
+  allowlists when baselined.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-kubernetes.audit_logs-* metadata _id, _index, _version
+| where event.dataset == "kubernetes.audit_logs"
+    and event.action == "get"
+    and kubernetes.audit.objectRef.resource == "secrets"
+    and source.ip is not null and user.name is not null 
+    and not to_string(source.ip) in ("127.0.0.1", "::1") and 
+    not user.name in ("system:kube-controller-manager", "system:kube-scheduler") and 
+    not kubernetes.audit.objectRef.name like "sh.helm.release.*" and 
+    not kubernetes.audit.user.username in ("system:serviceaccount:flux-system:kustomize-controller", "system:serviceaccount:flux-system:helm-controller", "system:serviceaccount:flux-system:source-controller", "system:serviceaccount:security:trivy-operator")
+| stats
+    Esql.unique_credentials = count_distinct(kubernetes.audit.objectRef.name),
+    Esql.secrets_names = values(kubernetes.audit.objectRef.name),
+    Esql.namespaces = values(kubernetes.audit.objectRef.namespace),
+    Esql.outcome = values(`kubernetes.audit.annotations.authorization_k8s_io/decision`)
+  by user.name, kubernetes.audit.user.username, source.ip, user_agent.original
+| where Esql.unique_credentials >= 3
+| KEEP user.name, kubernetes.audit.user.username, source.ip, user_agent.original, Esql.*
+
+----------------------------------
+
+*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-24/prebuilt-rule-8-19-24-kubernetes-secret-get-or-list-from-node-or-pod-service-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-secret-get-or-list-from-node-or-pod-service-account.asciidoc
new file mode 100644
index 0000000000..517dc020f0
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-secret-get-or-list-from-node-or-pod-service-account.asciidoc
@@ -0,0 +1,124 @@
+[[prebuilt-rule-8-19-24-kubernetes-secret-get-or-list-from-node-or-pod-service-account]]
+=== Kubernetes Secret get or list from Node or Pod Service Account
+
+Kubernetes audit identities for kubelet (`system:node:*`) and workloads (`system:serviceaccount:*`) are meant to operate with tight, predictable API usage. Direct `get` or `list` on the Secrets API from those principals is often a sign of credential access. Attackers who stole a pod service-account token or node credentials sweep Secret objects for tokens, registry credentials, TLS keys, or application configuration. Even denied attempts still reveal intent to reach sensitive material. Legitimate controllers do read secrets they mount or manage, so this signal is most valuable when paired with triage (namespace scope, user agent, RBAC, and whether the identity should touch those secret names at all).
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1552/007/
+* https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes Secret get or list from Node or Pod Service Account*
+
+
+This rule fires on Kubernetes audit events where the authenticated user is a node (`system:node:<nodename>`) or a
+pod service account (`system:serviceaccount:<namespace>:<name>`) and the verb maps to read-style access
+(`get`, `list`) on the **secrets** resource. Treat node-originated secret reads as high priority: kubelet should
+not broadly enumerate cluster secrets. For service accounts, prioritize cross-namespace access, access to
+high-value secret names, and clients that do not match the workload’s normal user agent or deployment.
+
+
+*Possible investigation steps*
+
+
+- Resolve `user.name` (or `kubernetes.audit.user.username` if present) to the node or workload and review RBAC
+  RoleBindings and ClusterRoleBindings for secret `get`/`list` scope.
+- Inspect `kubernetes.audit.objectRef.namespace`, `kubernetes.audit.objectRef.name`, source IP, and
+  `user_agent.original` for automation you recognize versus anomalous scripts or generic HTTP clients.
+- Review `kubernetes.audit.annotations.authorization_k8s_io/decision` for successful reads versus probing denials.
+- Correlate with pod exec, token creation, RoleBinding changes, or secret modification in the same time window.
+
+
+*False positive analysis*
+
+
+- Controllers that reconcile Secrets (e.g. cert-manager, external-secrets, sealed-secrets) may match; allowlist their
+  service accounts if behavior is expected and scoped.
+- Helm and package managers can list release secrets during deploys; correlate with pipelines and chart releases.
+
+
+*Response and remediation*
+
+
+- If malicious, revoke the token or node credentials, cordon or isolate the host or workload, rotate exposed secrets, and
+  tighten RBAC to least privilege for the affected identity.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"kubernetes.audit_logs" and
+event.action:(get or list) and
+kubernetes.audit.objectRef.resource:"secrets" and
+user.name:(system\:serviceaccount\:* or system\:node\:*) and source.ip:* and 
+not kubernetes.audit.user.groups:(
+  "system:serviceaccounts:flux-system"
+  or "system:serviceaccounts:kyverno"
+  or "system:serviceaccounts:ibm-csi"
+  or "system:serviceaccounts:harvester-system"
+  or "system:serviceaccounts:cattle-system"
+  or "system:serviceaccounts:cattle-monitoring-system"
+  or system\:serviceaccounts\:cluster-fleet-local-local-*
+  or "system:serviceaccounts:rabbitmq-system"
+  or "system:serviceaccounts:cattle-fleet-system"
+)
+
+----------------------------------
+
+*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-24/prebuilt-rule-8-19-24-kubernetes-secrets-list-across-cluster-or-sensitive-namespaces.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-secrets-list-across-cluster-or-sensitive-namespaces.asciidoc
new file mode 100644
index 0000000000..c6d0f2c1dc
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-secrets-list-across-cluster-or-sensitive-namespaces.asciidoc
@@ -0,0 +1,109 @@
+[[prebuilt-rule-8-19-24-kubernetes-secrets-list-across-cluster-or-sensitive-namespaces]]
+=== Kubernetes Secrets List Across Cluster or Sensitive Namespaces
+
+Detects list operations on Kubernetes Secrets from a non-loopback client when the request URI targets cluster-wide secrets or list operations under kube-system or default. Useful for spotting broad secret enumeration from remote clients.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1552/007/
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Tactic: Discovery
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes Secrets List Across Cluster or Sensitive Namespaces*
+
+
+Audit events for `list` on the `secrets` resource against `/api/v1/secrets`, paginated cluster lists, or namespace-scoped
+lists under `kube-system` or `default`, from a source IP that is not localhost.
+
+
+*Investigation steps*
+
+
+- Confirm the actor (`user.name`, groups) and whether the client is expected (CI, admin bastion, controller).
+- Review `kubernetes.audit.requestURI`, `user_agent.original`, and follow-on API activity from the same source.
+- Assess exposure: cluster-wide secret listing can surface many credentials.
+
+
+*False positives*
+
+
+- Legitimate controllers or operators listing secrets in `kube-system` / `default` from cluster nodes may match; tune by
+  source IP, user agent, or service account as needed.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:"kubernetes.audit_logs" and event.action:list and 
+kubernetes.audit.objectRef.resource:secrets and 
+kubernetes.audit.requestURI :(/api/v1/secrets or /api/v1/secrets?limit* or /api/v1/namespaces/kube-system/secrets or /api/v1/namespaces/kube-system/secrets?limit* or /api/v1/namespaces/default/secrets or /api/v1/namespaces/default/secrets?limit*) and 
+source.ip:(* and not ("::1" or "127.0.0.1")) and 
+not user.name: (system\:kube-controller-manager or eks\:cloud-controller-manager or eks\:kms-storage-migrator) and 
+not kubernetes.audit.user.groups:"system:serviceaccounts:ibm-csi"
+
+----------------------------------
+
+*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/
+* 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-24/prebuilt-rule-8-19-24-kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc
new file mode 100644
index 0000000000..623a8573dc
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc
@@ -0,0 +1,132 @@
+[[prebuilt-rule-8-19-24-kubernetes-service-account-token-created-via-tokenrequest-api]]
+=== Kubernetes Service Account Token Created via TokenRequest API
+
+Detects the creation of a Kubernetes service account token through the TokenRequest API by a non-system identity. The TokenRequest API allows users and workloads to programmatically generate short-lived tokens for any service account they have create permissions on, without accessing the filesystem or the mounted projected token. Attackers who have gained initial access to a cluster can abuse this API to mint tokens for more privileged service accounts, pivot to cloud provider resources via IRSA/workload identity, or generate long-lived tokens that persist beyond pod termination. Unlike mounted service account tokens which are detectable through file access monitoring, tokens created via the TokenRequest API leave no filesystem footprint, they are only visible in Kubernetes audit logs as a create verb on the serviceaccounts/token subresource. This rule excludes legitimate system components such as the kubelet, kube-controller-manager, and cloud provider managed identities (EKS, AKS, GKE) that routinely create tokens for pod lifecycle management.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-v1/
+* https://attack.mitre.org/techniques/T1552/007/
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: 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 Kubernetes Service Account Token Created via TokenRequest API*
+
+
+This alert indicates a successful `create` against the `serviceaccounts/token` subresource (TokenRequest API), which
+issues a new service account token without a filesystem read. In EKS and other managed clusters, this can be abused to
+mint tokens for more privileged service accounts (including IRSA-linked ones) and pivot to cloud APIs.
+
+
+*What to review first*
+
+
+- Actor and origin:
+  - `user.name` / `kubernetes.audit.user.username`
+  - `source.ip` / `kubernetes.audit.sourceIPs`
+  - `user_agent.original` / `kubernetes.audit.userAgent`
+  - For cloud identity, review `kubernetes.audit.user.extra.*` (e.g., `arn`, `principalId`).
+- Targeted service account:
+  - `kubernetes.audit.objectRef.namespace` and `kubernetes.audit.objectRef.name`
+  - `kubernetes.audit.requestURI` (should resemble `/api/v1/namespaces/<ns>/serviceaccounts/<sa>/token`)
+- Token issuance hints:
+  - `kubernetes.audit.annotations.authentication_kubernetes_io/issued-credential-id` (token JTI/issued credential id)
+
+
+*Scoping*
+
+
+- Identify which Role/ClusterRoleBindings grant the actor `create` on `serviceaccounts/token` in the affected namespace.
+- Pivot on the same `user.name` and `source.ip` for follow-on secret reads, pod exec, RBAC changes, or cloud API calls.
+
+
+*Response and remediation*
+
+
+- If unauthorized, remove/revert the RBAC permission that allows TokenRequest (`serviceaccounts/token`) and rotate the
+  affected service account credentials where applicable.
+- For IRSA/workload identity cases, rotate/revoke the cloud role session pathways and review cloud audit logs for API
+  activity from the time window of the token mint.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"kubernetes.audit_logs" and 
+kubernetes.audit.verb:"create" and
+kubernetes.audit.objectRef.resource:"serviceaccounts" and
+kubernetes.audit.objectRef.subresource:"token" and
+user.name:(* and not 
+ (system\:kube-controller-manager or
+  system\:kube-scheduler or
+  system\:node\:* or
+  system\:serviceaccount\:kube-system\:* or
+  eks\:* or
+  aksService or
+  aks-service or
+  masterclient or
+  nodeclient or
+  system\:serviceaccount\:gke-managed-system\:* or
+  system\:serviceaccount\:gke-connect\:* or
+  system\:serviceaccount\:anthos-identity-service\:* or
+  system\:gke-controller-manager or
+  system\:serviceaccount\:tigera-operator\:* or
+  system\:serviceaccount\:calico-system\:*))
+
+----------------------------------
+
+*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-24/prebuilt-rule-8-19-24-kubernetes-static-pod-manifest-file-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-static-pod-manifest-file-access.asciidoc
new file mode 100644
index 0000000000..665df97880
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-kubernetes-static-pod-manifest-file-access.asciidoc
@@ -0,0 +1,152 @@
+[[prebuilt-rule-8-19-24-kubernetes-static-pod-manifest-file-access]]
+=== Kubernetes Static Pod Manifest File Access
+
+Detects Linux process executions where shells, editors, interpreters, or file/stream utilities reference /etc/kubernetes/manifests in process arguments. That directory holds static pod manifests read by the kubelet; interaction via editors, downloaders, kubectl, redirection helpers (tee, dd), or scripting runtimes may indicate staging or tampering with manifests for persistence or privileged workload placement. Pairs with file-telemetry rules that flag direct manifest creation on container workloads.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* auditbeat-*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/
+* https://attack.mitre.org/techniques/T1053/007/
+
+*Tags*: 
+
+* Data Source: Auditd Manager
+* Data Source: Elastic Defend
+* Domain: Endpoint
+* Domain: Kubernetes
+* Domain: Container
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Privilege Escalation
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes Static Pod Manifest File Access*
+
+
+Review the full command line (process.args, process.command_line), user.id, user.name, process.parent, and whether the
+session was interactive. Confirm if the host is a Kubernetes node or admin jump host where manifest edits are expected.
+
+
+*Possible investigation steps*
+
+
+- Compare activity to change windows and identity baselines; prioritize events without matching change tickets.
+- Inspect subsequent process and file events on the same host for writes under /etc/kubernetes/manifests or kubelet
+  restarts.
+- Correlate with Kubernetes audit logs and node/agent telemetry for related compromise indicators.
+
+
+*Response and remediation*
+
+
+- If unauthorized, restore manifests from known-good sources, isolate the host, and review cluster integrity per incident
+  policy.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Requires **Elastic Defend** and/or **Auditd Manager** process telemetry (`logs-endpoint.events.process*`,
+`logs-auditd_manager.auditd-*`, `auditbeat-*`) with command-line argument capture for exec events.
+
+
+*Elastic Defend*
+
+Install the Elastic Defend integration via Fleet on Linux hosts and use a policy that collects process events with
+arguments.
+
+
+*Auditd Manager*
+
+Deploy Auditd Manager and ensure execve (or equivalent process) auditing is enabled so `process.args` and
+`process.executable` populate for monitored binaries.
+
+See https://docs.elastic.co/integrations/auditd_manager
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+host.os.type:linux and event.category:process and event.action:(exec or executed) and 
+process.name:(
+  bash or sh or dash or zsh or 
+  cat or cp or mv or touch or tee or dd or
+  sed or awk or 
+  curl or wget or scp or
+  vi or vim or nano or echo or
+  busybox or
+  python* or perl* or ruby* or node or lua* or
+  openssl or base64 or xxd or
+  .*) and 
+  process.args:(*/etc/kubernetes/manifests/* and not (/etc/kubernetes/manifests/etcd* or /etc/kubernetes/manifests/kube-apiserver* or /etc/kubernetes/manifests/kube-scheduler* or /etc/kubernetes/manifests/kube-controller-manager*))
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Scheduled Task/Job
+** ID: T1053
+** Reference URL: https://attack.mitre.org/techniques/T1053/
+* Sub-technique:
+** Name: Container Orchestration Job
+** ID: T1053.007
+** Reference URL: https://attack.mitre.org/techniques/T1053/007/
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Create or Modify System Process
+** ID: T1543
+** Reference URL: https://attack.mitre.org/techniques/T1543/
+* Sub-technique:
+** Name: Container Service
+** ID: T1543.005
+** Reference URL: https://attack.mitre.org/techniques/T1543/005/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-lateral-movement-via-startup-folder.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-lateral-movement-via-startup-folder.asciidoc
new file mode 100644
index 0000000000..bc3254acc9
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-lateral-movement-via-startup-folder.asciidoc
@@ -0,0 +1,180 @@
+[[prebuilt-rule-8-19-24-lateral-movement-via-startup-folder]]
+=== Lateral Movement via Startup Folder
+
+Identifies suspicious file creations in the startup folder of a remote system. An adversary could abuse this to move laterally by dropping a malicious script or executable that will be executed after a reboot or user logon.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.file-*
+* winlogbeat-*
+* logs-windows.sysmon_operational-*
+* endgame-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.mdsec.co.uk/2017/06/rdpinception/
+* 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
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Microsoft Defender XDR
+* Data Source: SentinelOne
+* Resources: Investigation Guide
+
+*Version*: 315
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Lateral Movement via Startup Folder*
+
+
+
+*Possible investigation steps*
+
+
+- What remote Startup-folder write did the alert capture?
+  - Focus: `file.path`, `file.extension`, `process.name`, `process.pid`, and `process.executable`.
+  - Implication: escalate when a remote writer plants a scriptable or executable item, especially in ProgramData Startup; lower suspicion only when the Startup item, writer, user, and host identify one bounded deployment or support component.
+- What does the planted Startup item contain or point to?
+  - Focus: `file.name`, `file.size`, `file.Ext.header_bytes`, and `file.Ext.windows.zone_identifier`.
+  - Implication: escalate on shortcuts, scripts, archives, executables, renamed payloads, or content/header mismatches that could run at logon; lower suspicion when a bounded installer or support shortcut has content and provenance matching the same named tool.
+- Does writer and user context identify the same support or deployment component?
+  - Focus: `user.id`, `user.domain`, `process.command_line`, and `process.parent.name`.
+  - Hint: for PID 4 SMB writes, recover surrounding SMB connection events to identify `source.ip`; for "mstsc.exe" writes, validate the RDP drive-redirection source through Terminal Services or RDP session logs when available. Missing SMB/RDP telemetry is unresolved, not benign. !{investigate{"description":"","label":"SMB connection events on the host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"event.action","queryType":"phrase","value":"connection_accepted","valueType":"string"},{"excluded":false,"field":"destination.port","queryType":"phrase","value":"445","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the account, host, parent, or command line does not explain remote RDP/SMB Startup persistence; lower suspicion when command line, parent, and user-host pairing point to the same bounded component.
+- Did the same Startup directory show staging, renames, or cleanup?
+  - Focus: file events in the same Startup directory on `host.id`, especially `file.directory`, `file.path`, `file.name`, and `file.Ext.original.path`. !{investigate{"description":"","label":"File events in the same Startup directory","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.directory","queryType":"phrase","value":"{{file.directory}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: use the directory view to separate one bounded write from broader Startup-folder staging.
+  - Implication: escalate on multiple writes, renames, mixed payload types, or cleanup artifacts; a single stable artifact narrows scope but does not clear the alert until execution and workflow fit are resolved.
+- Has the Startup item executed on the host?
+  - Focus: process starts on `host.id` where `process.executable` matches the written `file.path`, then review `process.command_line` and `user.id`. !{investigate{"description":"","label":"Process events where the Startup item later executed","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Hint: for shortcuts or scripts, exact path matching may miss the launched target; inspect the artifact and search same-host process starts for the referenced interpreter or target path.
+  - Implication: escalate when the item or referenced target executes, especially under a different user than the writer; no execution yet lowers immediacy, but clears only when writer, artifact, and directory evidence already prove a benign tool.
+- If local evidence is suspicious or incomplete, are there related same-host alerts?
+  - Focus: related alerts for the same `host.id` involving remote services, credentials, execution, discovery, or persistence. !{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: related alerts broaden the case from one Startup write to an intrusion path; no related alerts or an unavailable pivot narrows scope only and cannot close contradictory artifact, writer, or execution evidence.
+- Escalate for remotely planted Startup persistence or later execution; close only when writer mechanism, path, artifact, directory, execution, and alert pivots bind to one bounded benign component without contradiction; preserve artifacts and escalate when evidence is mixed or incomplete.
+
+
+*False positive analysis*
+
+
+- Software deployment, break-fix support, enterprise agents, or line-of-business applications can place bounded installers, shortcuts, support utilities, or stable per-user/all-users components in Startup through RDP or SMB. Confirm that `file.path`, `file.name`, `file.extension`, writer process or command line, `user.id`, `host.id`, directory view, and later direct or shortcut-target execution all identify the same bounded component, with no extra staging files or suspicious same-host alerts. Do not close on a role, ticket, or partial field match when current telemetry does not bind writer, artifact, and execution behavior together.
+- Build exceptions from the minimum confirmed workflow pattern: the specific `file.path`, writer `process.name` or `process.pid`, `user.id`, `host.id`, and bounded later-execution or quiet-directory evidence that distinguishes the benign case. Avoid exceptions on the Startup folder path alone, on "mstsc.exe" alone, or on PID 4 alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and document the exact `file.path`, writer `process.name` or `process.pid`, `user.id`, `host.id`, and quiet-directory or later-execution evidence that established the bounded workflow. Create an exception only when that same evidence set distinguishes the benign workflow from remote Startup-folder abuse.
+- If suspicious but unconfirmed, preserve a copy of the written Startup item, the Startup directory listing, and case exports for the relevant file events, writer process metadata, later execution records, user-host identifiers, and related-alert context before containment.
+- Apply reversible containment before destructive action: quarantine the Startup item after preserving it, restrict further RDP or SMB administrative access to the host, or heighten monitoring on the affected `host.id`. Isolate the host only when later execution or related alerts show broader compromise and the host role can tolerate disruption.
+- If confirmed malicious, record any later-executed process identifiers and command lines, preserve the Startup item and same-directory artifacts, then isolate the host when feasible, terminate malicious execution, and remove the Startup item, shortcuts, scripts, and staging artifacts identified during the investigation.
+- Before deleting artifacts or resetting credentials, scope other hosts and accounts for the same `file.name`, `file.path`, writer `process.command_line`, or later `process.executable` pattern. Reset or reissue credentials only when related alerts or later execution indicate likely account misuse.
+- Post-incident hardening: restrict unnecessary RDP drive redirection, tighten SMB administrative write access, monitor Startup folder changes on remote-access targets, and retain the file/process telemetry needed to distinguish repeat deployment workflows from repeat abuse.
+
+==== 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 in ("creation", "change") and
+
+ /* via RDP TSClient mounted share or SMB */
+  (process.name : "mstsc.exe" or process.pid == 4) and
+
+   file.path : ("?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*",
+                "?:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*")
+
+----------------------------------
+
+*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: Remote Desktop Protocol
+** ID: T1021.001
+** Reference URL: https://attack.mitre.org/techniques/T1021/001/
+* 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/
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Boot or Logon Autostart Execution
+** ID: T1547
+** Reference URL: https://attack.mitre.org/techniques/T1547/
+* Sub-technique:
+** Name: Registry Run Keys / Startup Folder
+** ID: T1547.001
+** Reference URL: https://attack.mitre.org/techniques/T1547/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-lsass-memory-dump-handle-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-lsass-memory-dump-handle-access.asciidoc
new file mode 100644
index 0000000000..43e4c70766
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-lsass-memory-dump-handle-access.asciidoc
@@ -0,0 +1,170 @@
+[[prebuilt-rule-8-19-24-lsass-memory-dump-handle-access]]
+=== LSASS Memory Dump Handle Access
+
+Identifies handle requests for the Local Security Authority Subsystem Service (LSASS) object access with specific access masks that many tools with a capability to dump memory to disk use (0x1fffff, 0x1010, 0x120089). This rule is tool agnostic as it has been validated against a host of various LSASS dump tools such as SharpDump, Procdump, Mimikatz, Comsvcs etc. It detects this behavior at a low level and does not depend on a specific tool or dump file name.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4656
+* https://twitter.com/jsecurity101/status/1227987828534956033?s=20
+* https://attack.mitre.org/techniques/T1003/001/
+* https://threathunterplaybook.com/notebooks/windows/06_credential_access/WIN-170105221010.html
+* http://findingbad.blogspot.com/2017/
+* https://www.elastic.co/security-labs/detect-credential-access
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Resources: Investigation Guide
+* Data Source: Windows Security Event Logs
+
+*Version*: 218
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating LSASS Memory Dump Handle Access*
+
+
+Local Security Authority Server Service (LSASS) is a process in Microsoft Windows operating systems that is responsible for enforcing security policy on the system. It verifies users logging on to a Windows computer or server, handles password changes, and creates access tokens.
+
+Adversaries may attempt to access credential material stored in LSASS process memory. After a user logs on, the system generates and stores a variety of credential materials in LSASS process memory. This is meant to facilitate single sign-on (SSO) ensuring a user isn’t prompted each time resource access is requested. These credential materials can be harvested by an adversary using administrative user or SYSTEM privileges to conduct lateral movement using https://attack.mitre.org/techniques/T1550/[alternate authentication material].
+
+> **Note**:
+> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
+
+
+*Possible investigation steps*
+
+
+- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Examine the host for derived artifacts that indicate suspicious activities:
+  - Analyze the process executable using a private sandboxed analysis system.
+  - Observe and collect information about the following activities in both the sandbox and the alert subject host:
+    - Attempts to contact external domains and addresses.
+      - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.
+      - Examine the DNS cache for suspicious or anomalous entries.
+        - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}}
+    - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
+    - Examine the host services for suspicious or anomalous entries.
+      - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}}
+      - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}}
+      - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}}
+  - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
+- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.
+
+
+
+*False positive analysis*
+
+
+- There should be very few or no false positives for this rule. If this activity is expected or noisy in your environment, consider adding exceptions — preferably with a combination of user and command line conditions.
+- If the process is related to antivirus or endpoint detection and response solutions, validate that it is installed on the correct path and signed with the company's valid digital signature.
+
+
+*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.
+- Scope compromised credentials and disable the accounts.
+- 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*
+
+
+Audit Handle Manipulation must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-handle-manipulation
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+host.os.type:"windows" and event.code:"4656" and
+  (
+    winlog.event_data.AccessMask : ("0x1fffff" or "0x1010" or "0x120089" or "0x1F3FFF") or
+    winlog.event_data.AccessMaskDescription : ("READ_CONTROL" or "Read from process memory")
+  ) and
+  winlog.event_data.ObjectType : "Process" and 
+  winlog.event_data.ObjectName : *\\Windows\\System32\\lsass.exe and
+  not winlog.event_data.ProcessName : (
+      "C:\Windows\System32\wbem\WmiPrvSE.exe" or
+      "C:\Windows\SysWOW64\wbem\WmiPrvSE.exe" or
+      "C:\Windows\System32\dllhost.exe" or
+      "C:\Windows\System32\svchost.exe" or
+      "C:\Windows\System32\msiexec.exe" or
+      "C:\Windows\explorer.exe" or 
+      "C:\\Windows\\Sysmon64.exe" or 
+      "C:\\Windows\\BTPass\\x64\\BTPassSvc.exe" or 
+      "C:\\Windows\\Sysmon.exe" or 
+      "C:\\Windows\\System32\\RtkAudUService64.exe" or 
+      "C:\\Windows\\System32\\RtkAudUService64.exe" or 
+       C\:\\Windows\\System32\\DriverStore\\FileRepository\\fn.inf_amd64_*\\driver\\tphkload.exe
+  )
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-lsass-process-access-via-windows-api.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-lsass-process-access-via-windows-api.asciidoc
new file mode 100644
index 0000000000..2fa10d7ac8
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-lsass-process-access-via-windows-api.asciidoc
@@ -0,0 +1,209 @@
+[[prebuilt-rule-8-19-24-lsass-process-access-via-windows-api]]
+=== LSASS Process Access via Windows API
+
+Identifies access attempts to the LSASS handle, which may indicate an attempt to dump credentials from LSASS memory.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 15m
+
+*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1003.001/T1003.001.md
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Tactic: Execution
+* Data Source: Elastic Defend
+* Data Source: Microsoft Defender XDR
+* Resources: Investigation Guide
+
+*Version*: 19
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating LSASS Process Access via Windows API*
+
+
+The Local Security Authority Subsystem Service (LSASS) is a critical Windows component responsible for managing user authentication and security policies. Adversaries may attempt to access the LSASS handle to dump credentials from its memory, which can be used for lateral movement and privilege escalation.
+
+This rule identifies attempts to access LSASS by monitoring for specific API calls (OpenProcess, OpenThread) targeting the "lsass.exe" process.
+
+> **Note**:
+> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
+
+
+*Possible investigation steps*
+
+
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Investigate the process execution chain (parent process tree) of the process that accessed the LSASS handle.
+  - Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
+  - Determine the first time the process executable was seen in the environment and if this behavior happened in the past.
+  - Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.
+  - Investigate any abnormal behavior by the subject process, such as network connections, DLLs loaded, registry or file modifications, and any spawned child processes.
+- Assess the access rights (`process.Ext.api.parameters.desired_access`field) requested by the process. This https://learn.microsoft.com/en-us/windows/win32/procthread/process-security-and-access-rights[Microsoft documentation] may be useful to help the interpretation.
+- If there are traces of LSASS memory being successfully dumped, investigate potentially compromised accounts. Analysts can do this by searching for login events (e.g., 4624) to the target host.
+- Examine the host for derived artifacts that indicate suspicious activities:
+  - Analyze the executables of the processes 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's `process.entity_id`.
+      - Examine the DNS cache for suspicious or anomalous entries.
+        - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}}
+    - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
+    - Examine the host services for suspicious or anomalous entries.
+      - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}}
+      - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}}
+      - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}}
+  - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
+
+
+
+*False positive analysis*
+
+
+- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of `process.executable`, `process.code_signature.subject_name` and `process.Ext.api.parameters.desired_access_numeric` conditions.
+
+
+*Related Rules*
+
+
+- Suspicious Lsass Process Access - 128468bf-cab1-4637-99ea-fdf3780a4609
+- Potential Credential Access via DuplicateHandle in LSASS - 02a4576a-7480-4284-9327-548a806b5e48
+- LSASS Memory Dump Handle Access - 208dbe77-01ed-4954-8d44-1e5751cb20de
+
+
+*Response and Remediation*
+
+
+- Initiate the incident response process based on the outcome of the triage.
+  - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps.
+- 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.
+- Reimage the host operating system or restore the compromised files to clean versions.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-endpoint.events.api-*, logs-m365_defender.event-* metadata _id, _version, _index
+
+| where event.category == "api" and host.os.family == "windows" and
+   process.Ext.api.name in ("OpenProcess", "OpenThread", "ReadProcessMemory") and
+   Target.process.name == "lsass.exe" and process.executable is not null and
+
+   // Noisy patterns
+   not to_lower(process.executable) like """c:\\program files\\*.exe""" and
+   not to_lower(process.executable) like """c:\\program files (x86)\\*.exe""" and
+   not to_lower(process.executable) like """c:\\programdata\\microsoft\\windows defender\\platform\\msmpeng.exe""" and
+   not to_lower(process.executable) like """c:\\programdata\\microsoft\\windows defender\\platform\\*\\msmpeng.exe"""
+
+ /* normalize process paths to reduce known random patterns in process.executable */
+| eval Esql.process_path = replace(process.executable, """([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|ns[a-z][A-Z0-9]{3,4}\.tmp|DX[A-Z0-9]{3,4}\.tmp|7z[A-Z0-9]{3,5}\.tmp|[0-9\.\-\_]{3,})""", "")
+
+// Group by process path
+| stats Esql.access_count = count(*),
+        Esql.count_distinct_hosts = count_distinct(host.id),
+        Esql.host_id_values = VALUES(host.id),
+        Esql.host_name_values = VALUES(host.name),
+        Esql.user_name_values = VALUES(user.name),
+        Esql.process_pid_values = VALUES(process.entity_id),
+        Esql.process_executable_values = VALUES(process.executable),
+        Esql.data_stream_namespace.values = VALUES(data_stream.namespace),
+        Esql.user_name_values = VALUES(user.name) by Esql.process_path
+
+// Limit to rare instances limited to 1 unique host
+| where Esql.count_distinct_hosts == 1 and Esql.access_count <= 3
+
+// Extract the single host ID and process into their corresponding ECS fields for alerts exclusion
+| eval host.id = mv_min(Esql.host_id_values),
+       host.name = mv_min(Esql.host_name_values),
+       process.executable = mv_min(Esql.process_executable_values), 
+       user.name = mv_min(Esql.user_name_values)
+
+// Add the new field to the keep statement
+| keep Esql.*, host.id, host.name, user.name, process.executable
+
+----------------------------------
+
+*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/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Native API
+** ID: T1106
+** Reference URL: https://attack.mitre.org/techniques/T1106/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-m365-identity-login-from-atypical-region.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-m365-identity-login-from-atypical-region.asciidoc
new file mode 100644
index 0000000000..a694813364
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-m365-identity-login-from-atypical-region.asciidoc
@@ -0,0 +1,136 @@
+[[prebuilt-rule-8-19-24-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 <<rule-schedule, `Additional look-back time`>>)
+
+*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*: 11
+
+*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 10 or 2 or 3 or 5 or 6) and
+    o365.audit.UserId:(* and not "Not Available") and
+    source.geo.country_name:* and
+    source.geo.region_name:* and
+    not o365.audit.ApplicationId:(
+        29d9ed98-a469-4536-ade2-f981bc1d605e or
+        38aa3b87-a06d-4817-b275-7a316988d93b or
+        a809996b-059e-42e2-9866-db24b99a9782 or
+        08e18876-6177-487e-b8b5-cf950c1e598c or
+        3e62f81e-590b-425b-9531-cad6683656cf or
+        d7b530a4-7680-4c23-a8bf-c52c121d2e87
+    ) and not o365.audit.ExtendedProperties.RequestType:(
+        "Consent:Set" or
+        "DeviceAuth:ReprocessTls" or
+        "Kmsi:kmsi" or
+        "Login:reprocess" or
+        "Login:resume" or
+        "MessagePrompt:MessagePrompt" or
+        "Saml2:processrequest" or
+        "SAS:EndAuth" or
+        "SAS:ProcessAuth"
+    ) and
+    not user_agent.original:(*iPhone* or *iPad* or *Android* or *PKeyAuth*)
+
+----------------------------------
+
+*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-24/prebuilt-rule-8-19-24-m365-identity-login-from-impossible-travel-location.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-m365-identity-login-from-impossible-travel-location.asciidoc
new file mode 100644
index 0000000000..983c1eb60b
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-m365-identity-login-from-impossible-travel-location.asciidoc
@@ -0,0 +1,131 @@
+[[prebuilt-rule-8-19-24-m365-identity-login-from-impossible-travel-location]]
+=== M365 Identity Login from Impossible Travel Location
+
+Detects successful Microsoft 365 portal logins from impossible travel locations. Impossible travel locations are defined as two different countries within a short time frame. This behavior may indicate an adversary attempting to access a Microsoft 365 account from a compromised account or a malicious actor attempting to access a Microsoft 365 account from a different location.
+
+*Rule type*: threshold
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*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*: 10
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating M365 Identity Login from Impossible Travel Location*
+
+
+Microsoft 365's cloud-based services enable global access, but this can be exploited by adversaries logging in from disparate locations within short intervals, indicating potential account compromise. The detection rule identifies such anomalies by analyzing login events for rapid geographic shifts, flagging suspicious activity that may suggest unauthorized access attempts.
+
+
+*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 10 or 2 or 3 or 5 or 6) and
+    o365.audit.UserId:(* and not "Not Available") and
+    source.geo.country_name:* and
+    not o365.audit.ApplicationId:(
+        29d9ed98-a469-4536-ade2-f981bc1d605e or
+        38aa3b87-a06d-4817-b275-7a316988d93b or
+        a809996b-059e-42e2-9866-db24b99a9782 or
+        08e18876-6177-487e-b8b5-cf950c1e598c or
+        3e62f81e-590b-425b-9531-cad6683656cf or
+        d7b530a4-7680-4c23-a8bf-c52c121d2e87
+    ) and not o365.audit.ExtendedProperties.RequestType:(
+        "Cmsi:Cmsi" or
+        "Consent:Set" or
+        "Login:reprocess" or
+        "Login:resume" or
+        "MessagePrompt:MessagePrompt" or
+        "SAS:EndAuth"
+    )
+
+----------------------------------
+
+*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-24/prebuilt-rule-8-19-24-m365-potential-aitm-userloggedin-via-office-app-tycoon2fa.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-m365-potential-aitm-userloggedin-via-office-app-tycoon2fa.asciidoc
new file mode 100644
index 0000000000..80eae40ce2
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-m365-potential-aitm-userloggedin-via-office-app-tycoon2fa.asciidoc
@@ -0,0 +1,119 @@
+[[prebuilt-rule-8-19-24-m365-potential-aitm-userloggedin-via-office-app-tycoon2fa]]
+=== M365 Potential AiTM UserLoggedIn via Office App (Tycoon2FA)
+
+Detects Microsoft 365 audit "UserLoggedIn" events consistent with Tycoon 2FA phishing-as-a-service (PhaaS) adversary-in-the-middle (AiTM) activity: the Microsoft Authentication Broker requesting access where the object identifier matches Microsoft Graph or Exchange Online, or the Office web client application authenticating to itself, combined with Node.js-style user agents (node, axios, undici). Tycoon 2FA bypasses MFA by relaying authentication and capturing session material, often targeting Microsoft 365 and Gmail. Baseline legitimate automation and developer tooling before tuning.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://any.run/malware-trends/tycoon/
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Domain: SaaS
+* Data Source: Microsoft 365
+* Data Source: Microsoft 365 Audit Logs
+* Use Case: Threat Detection
+* Threat: Tycoon2FA
+* Tactic: Initial Access
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating M365 Potential AiTM UserLoggedIn via Office App (Tycoon2FA)*
+
+
+Review `o365.audit.UserId`, `user_agent.original`, `source.ip` or `o365.audit.ActorIpAddress`, and related Entra ID
+sign-in logs (`azure.signinlogs`) for the same session or time window.
+
+Confirm whether the account owner intentionally authenticated and whether Node.js-style user agents (node, axios, undici)
+are expected for Microsoft Authentication Broker or Office web client flows in your environment.
+
+
+*Possible investigation steps*
+
+
+- Correlate with `azure.signinlogs` for matching user principal name, IP, and session identifiers.
+- Review Microsoft Graph or Exchange audit activity following the login for mailbox or data access anomalies.
+- Hunt for other `UserLoggedIn` events from the same source with unusual user agents or rapid OAuth patterns.
+
+
+*Response and remediation*
+
+
+- If malicious, revoke refresh tokens for the user, reset credentials per policy, and review conditional access outcomes.
+- Block or monitor the source IP and escalate per incident procedures.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"o365.audit" and event.category:"authentication" and event.action:"UserLoggedIn" and
+(
+    (
+        o365.audit.ApplicationId:"29d9ed98-a469-4536-ade2-f981bc1d605e" and
+        o365.audit.ObjectId:(
+            "00000002-0000-0ff1-ce00-000000000000" or "00000003-0000-0000-c000-000000000000"
+        )
+    ) or
+    (
+        o365.audit.ApplicationId:"4765445b-32c6-49b0-83e6-1d93765276ca" and
+        o365.audit.ObjectId:"4765445b-32c6-49b0-83e6-1d93765276ca"
+    )
+) and user_agent.original:(node or axios* or undici)
+
+----------------------------------
+
+*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/
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Steal Web Session Cookie
+** ID: T1539
+** Reference URL: https://attack.mitre.org/techniques/T1539/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-microsoft-exchange-worker-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-microsoft-exchange-worker-spawning-suspicious-processes.asciidoc
new file mode 100644
index 0000000000..286ca65f67
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-microsoft-exchange-worker-spawning-suspicious-processes.asciidoc
@@ -0,0 +1,190 @@
+[[prebuilt-rule-8-19-24-microsoft-exchange-worker-spawning-suspicious-processes]]
+=== Microsoft Exchange Worker Spawning Suspicious Processes
+
+Identifies suspicious processes being spawned by the Microsoft Exchange Server worker process (w3wp). This activity may indicate exploitation activity or access to an existing web shell backdoor.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process-*
+* winlogbeat-*
+* logs-windows.sysmon_operational-*
+* endgame-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers
+* https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities
+* https://discuss.elastic.co/t/detection-and-response-for-hafnium-activity/266289
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Initial Access
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Microsoft Defender XDR
+* Data Source: SentinelOne
+* Resources: Investigation Guide
+
+*Version*: 316
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Microsoft Exchange Worker Spawning Suspicious Processes*
+
+
+
+*Possible investigation steps*
+
+
+- What Exchange worker-child path did the alert capture?
+  - Focus: child `process.executable` and `process.command_line`; worker `process.parent.executable`, `process.parent.args`, and `process.parent.command_line`; exact MSExchange app pool.
+  - Implication: escalate when an Exchange app pool launches shell/PowerShell for execution, download, discovery, or staging; lower suspicion only when parent arguments and child command match one narrow maintenance task with no webshell or RCE indicators.
+- What intent does the shell or PowerShell command show?
+  - Focus: `process.command_line`; encoded or inline execution, download cradles, archive/export, discovery, Set-OabVirtualDirectory, mailbox access, or FrontEnd\HttpProxy, aspnet_client, web.config, and applicationHost.config paths.
+  - Implication: escalate on payload retrieval, web-root staging, credential access, account changes, mailbox export, cleanup, or lateral movement; lower suspicion only for one bounded recognized Exchange maintenance or validation action.
+- Does token and session context support human administration or service-context abuse?
+  - Why: w3wp.exe children often inherit app-pool or service identity, so user fields alone do not prove human administration.
+  - Focus: `user.id`, `user.name`, `user.domain`, `process.Ext.session_info.logon_type`, and `process.Ext.authentication_id`.
+  - Implication: escalate when a service, app-pool, or unexpected logon context launches interactive shell behavior or remote administration; lower suspicion only when identity, session type, and command scope match the same recognized workflow.
+- Is the child binary expected or masqueraded?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the child is renamed, user-writable, unsigned or untrusted, hash-new for the server, or mismatched to PE original name; a trusted Microsoft shell lowers identity concern but does not clear the unusual chain.
+- If process evidence is suspicious or unresolved, did file evidence show webshells or artifacts?
+  - Focus: with endpoint file telemetry, scope by `host.id` + `process.entity_id`, or `host.id` + `process.pid` + tight alert window if absent; inspect `file.path`, `file.Ext.original.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier` for ASPX, scripts, binaries, DLLs, archives, or output under Exchange/IIS paths. !{investigate{"description":"","label":"File events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: check whether a written `file.path` later appears as `process.executable`; missing file telemetry limits proof but is not benign.
+  - Implication: escalate when the child writes new or modified ASPX, scripts, binaries, DLLs, archives, or output under Exchange FrontEnd\HttpProxy, IIS aspnet_client, temp, or web-root paths; lower suspicion only when file activity stays inside the exact maintenance path with no web-content or payload staging.
+- If process evidence is suspicious or unresolved, did network evidence show retrieval or callback?
+  - Focus: with endpoint network telemetry, scope DNS and connections by `host.id` + `process.entity_id`, or `host.id` + `process.pid` + tight alert window if absent; read DNS (`dns.question.name`, `dns.resolved_ip`) separately from connections (`destination.ip`, `destination.port`). !{investigate{"description":"","label":"Network events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: map `dns.resolved_ip` to `destination.ip` before deciding whether the same process reached it. Missing network telemetry is unresolved, not benign.
+  - Implication: escalate when the child downloads tools, reaches public staging or callback infrastructure, or connects to systems unrelated to the Exchange task; lower suspicion only when destinations are internal, proxy, or vendor services fitting the same bounded workflow.
+- Does same-worker or same-host scope show broader Exchange compromise?
+  - Focus: surrounding same-worker process starts and related alerts on `host.id` or `user.id`, especially `process.parent.executable`, `process.parent.args`, `process.command_line`, and `process.hash.sha256` for repeated w3wp.exe descendants, credential dumping, account changes, archiving, cleanup, or side-loading chains.
+    - !{investigate{"description":"","label":"Process events from the same Exchange worker","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","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"}}
+    - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate scope when the host shows credential dumping, account changes, archive creation, cleanup, lateral movement, or repeated Exchange worker children; keep local only when surrounding process evidence and related alerts stay confined to the same recognized maintenance window.
+- Escalate on unexplained server-side execution, suspicious command intent, payload staging, suspicious destinations, or broader host compromise; close only when all available evidence aligns with one recognized Exchange workflow on this host; preserve artifacts and escalate when evidence is mixed or visibility incomplete.
+
+
+*False positive analysis*
+
+
+- Recognized Exchange maintenance or controlled validation is the bounded benign path. Confirm only when `process.parent.args`, child `process.command_line`, `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `user.id`, and `host.id` align with one task, and any `file.path`, `dns.question.name`, or `destination.ip` evidence shows no payload staging or external callback. Use change records as corroboration; otherwise require recurring prior alerts with the same parent arguments, command pattern, child identity, user, host, and no contradictory artifacts or destinations.
+- Build exceptions only from the minimum confirmed pattern: `process.parent.args`, child `process.executable` or `process.hash.sha256`, `process.code_signature.subject_name`, stable `process.command_line` fragment, `user.id`, `host.id`, and any bounded artifact or destination pattern distinguishing the benign task. Avoid exceptions on "w3wp.exe", `process.name`, or `host.id` alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and document the exact evidence that validated the workflow: `process.parent.args`, child `process.executable`, `process.command_line`, `user.id`, `host.id`, and any bounded artifact or destination pattern. Create an exception only after the same pattern is stable across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve the alert, process tree, child `process.entity_id` or `process.pid`, `process.command_line`, parent `process.parent.entity_id`, `process.parent.args`, child hash and signer, `user.id`, `host.id`, and any staged artifacts, destinations, or IIS/Exchange log snippets before containment. Apply reversible containment first: block confirmed malicious destinations, restrict external access to the implicated Exchange service, or increase monitoring. Isolate only when active compromise evidence and server criticality justify disruption.
+- If confirmed malicious, contain the Exchange server or exposed service path based on the process, artifact, destination, and same-host evidence already preserved. Record process and artifact identifiers before terminating the child, then block confirmed malicious domains, IPs, and hashes.
+- Eradicate only the webshells, scripts, archives, scheduled tasks, dropped utilities, and configuration changes identified during triage. Restore modified Exchange or IIS content from known-good state, patch the Exchange server, review the virtual directories and app pools implicated by `process.parent.args`, and rotate Exchange, application, or service credentials if credential access, configuration theft, or mailbox export was involved.
+- Retain the related process, file, network, IIS, and Exchange logs that supported the decision. Document any adjacent variant or telemetry gap, such as missing endpoint file/network events or unavailable IIS request logs, for the detection engineering team.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+  process.parent.name : "w3wp.exe" and process.parent.args : "MSExchange*AppPool" and
+  (
+    (process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe") or
+    ?process.pe.original_file_name in ("Cmd.Exe", "PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE"))
+  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Exploit Public-Facing Application
+** ID: T1190
+** Reference URL: https://attack.mitre.org/techniques/T1190/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
+* Sub-technique:
+** Name: Windows Command Shell
+** ID: T1059.003
+** Reference URL: https://attack.mitre.org/techniques/T1059/003/
+* 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-microsoft-graph-multi-category-reconnaissance-burst.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-microsoft-graph-multi-category-reconnaissance-burst.asciidoc
new file mode 100644
index 0000000000..192bf8cf79
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-microsoft-graph-multi-category-reconnaissance-burst.asciidoc
@@ -0,0 +1,213 @@
+[[prebuilt-rule-8-19-24-microsoft-graph-multi-category-reconnaissance-burst]]
+=== Microsoft Graph Multi-Category Reconnaissance Burst
+
+Detects Microsoft Graph activity from delegated user tokens (public client, client_auth_method 0) where a single user session and source IP rapidly touches multiple high-value Graph paths indicative of reconnaissance. The query classifies requests into categories such as role discovery, cross-tenant relationship queries, mailbox paths, contact harvesting, and organization or licensing metadata. When three or more distinct categories appear within a short burst window, it suggests a broad enumeration playbook rather than normal application traffic.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Domain: API
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Graph
+* Data Source: Microsoft Graph Activity Logs
+* Use Case: Threat Detection
+* Tactic: Discovery
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Microsoft Graph Multi-Category Reconnaissance Burst*
+
+
+This rule uses an aggregation-based ES|QL query. Alert documents contain summarized fields; pivot to raw Graph activity
+logs using user principal object ID, session ID (c_sid), source IP, tenant ID, and timestamps from the alert.
+
+
+*Possible investigation steps*
+
+
+- Review Esql.categories and Esql.sample_paths to see which Graph endpoints were touched and whether they align with the app purpose.
+- Validate azure.graphactivitylogs.properties.app_id and user_agent.original against approved applications.
+- Correlate with Entra ID sign-in logs for the same user and session for MFA, conditional access, and token issuance context.
+- Check whether failed_calls indicates probing or permission errors versus successful enumeration.
+
+
+*Response and remediation*
+
+
+- If malicious, revoke refresh tokens for the user, disable or restrict the application consent, and reset credentials per policy.
+- Add conditional access or block rules for high-risk Graph patterns where appropriate.
+
+
+==== Setup
+
+
+
+*Microsoft Graph Activity Logs*
+
+Requires Microsoft Graph Activity Logs ingested into `logs-azure.graphactivitylogs-*` (for example via Azure Event Hub).
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-azure.graphactivitylogs-* metadata _id, _version, _index
+
+// Graph calls via delegated user tokens (any status, any method)
+| where event.dataset == "azure.graphactivitylogs"
+  and azure.graphactivitylogs.properties.c_idtyp == "user"
+  and azure.graphactivitylogs.properties.client_auth_method == 0
+
+// high-value recon endpoints by url.path
+| eval Esql.is_role_enum = case(
+    url.path like "*roleManagement/directory*"
+      or url.path like "*memberOf/microsoft.graph.directoryRole*"
+      or url.path like "*transitiveRoleAssignments*",
+    true,
+    false
+  )
+| eval Esql.is_cross_tenant_enum = case(
+    url.path like "*tenantRelationships*"
+      or url.path like "*getResourceTenants*",
+    true,
+    false
+  )
+| eval Esql.is_mailbox_recon = case(
+    url.path like "*mailboxSettings*"
+      or url.path like "*mailFolders*"
+      or url.path like "*messages*"
+      or url.path like "*inbox*",
+    true,
+    false
+  )
+| eval Esql.is_contact_harvest = case(
+    url.path like "*contacts*"
+      or url.path like "*contactFolders*",
+    true,
+    false
+  )
+| eval Esql.is_org_recon = case(
+    url.path like "*subscribedSkus*"
+      or url.path like "*appRoleAssign*"
+      or (
+          url.path like "*/organization*"
+          and not url.path like "*branding*"
+          and not url.path like "*localizations*"
+        ),
+    true,
+    false
+  )
+
+// Combine: is this request hitting a high-value endpoint?
+| eval Esql.is_high_value = case(
+    Esql.is_role_enum or Esql.is_cross_tenant_enum or Esql.is_mailbox_recon
+      or Esql.is_contact_harvest or Esql.is_org_recon,
+    true,
+    false
+  )
+| where Esql.is_high_value == true
+
+// Classify each hit into a recon category
+| eval Esql.recon_category = case(
+    Esql.is_role_enum, "role_discovery",
+    Esql.is_cross_tenant_enum, "cross_tenant_recon",
+    Esql.is_mailbox_recon, "mailbox_recon",
+    Esql.is_contact_harvest, "contact_harvesting",
+    Esql.is_org_recon, "org_and_licensing_recon",
+    "other"
+  )
+
+// Flag failed requests (recon that errored is still recon)
+| eval Esql.is_failed_request = case(
+    http.response.status_code >= 400, true, false
+  )
+
+// Aggregate per user + session + source IP
+| stats
+    Esql.total_high_value_calls = count(*),
+    Esql.distinct_categories = count_distinct(Esql.recon_category),
+    Esql.distinct_paths = count_distinct(url.path),
+    Esql.failed_calls = sum(case(Esql.is_failed_request, 1, 0)),
+    Esql.categories = values(Esql.recon_category),
+    Esql.sample_paths = values(url.path),
+    Esql.http_methods = values(http.request.method),
+    Esql.status_codes = values(http.response.status_code),
+    Esql.first_seen = min(@timestamp),
+    Esql.last_seen = max(@timestamp),
+    Esql.user_agents = values(user_agent.original),
+    Esql.app_ids = values(azure.graphactivitylogs.properties.app_id)
+  by
+    azure.graphactivitylogs.properties.user_principal_object_id,
+    source.ip,
+    source.`as`.organization.name,
+    source.`as`.number,
+    azure.graphactivitylogs.properties.c_sid,
+    azure.tenant_id
+
+// Threshold: 3+ distinct recon categories 
+| where Esql.distinct_categories >= 4 and Esql.total_high_value_calls >= 20
+
+// Burst duration in seconds
+| eval Esql.burst_duration_seconds = date_diff("seconds", Esql.first_seen, Esql.last_seen)
+| where Esql.burst_duration_seconds <= 60
+
+| keep
+    azure.graphactivitylogs.properties.user_principal_object_id,
+    azure.graphactivitylogs.properties.c_sid,
+    azure.tenant_id,
+    source.ip,
+    source.`as`.organization.name,
+    source.`as`.number,
+    Esql.*
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Discovery
+** ID: TA0007
+** Reference URL: https://attack.mitre.org/tactics/TA0007/
+* Technique:
+** Name: Cloud Service Discovery
+** ID: T1526
+** Reference URL: https://attack.mitre.org/techniques/T1526/
+* Technique:
+** Name: Account Discovery
+** ID: T1087
+** Reference URL: https://attack.mitre.org/techniques/T1087/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-mimikatz-memssp-log-file-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-mimikatz-memssp-log-file-detected.asciidoc
new file mode 100644
index 0000000000..0b1d41e271
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-mimikatz-memssp-log-file-detected.asciidoc
@@ -0,0 +1,177 @@
+[[prebuilt-rule-8-19-24-mimikatz-memssp-log-file-detected]]
+=== Mimikatz Memssp Log File Detected
+
+Identifies the default Mimikatz MemSSP credential log file, mimilsa.log. This file is created after the misc::memssp module injects a malicious Security Support Provider into LSASS and can contain credentials from subsequent logons to the host.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-endpoint.events.file-*
+* logs-windows.sysmon_operational-*
+* endgame-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-m365_defender.event-*
+* logs-crowdstrike.fdr*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.elastic.co/security-labs/detect-credential-access
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Resources: Investigation Guide
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Data Source: Microsoft Defender XDR
+* Data Source: Crowdstrike
+
+*Version*: 419
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Mimikatz Memssp Log File Detected*
+
+
+
+*Possible investigation steps*
+
+
+- Is the alert-local event the default MemSSP credential log?
+  - Focus: `file.name`, `file.path`, `file.size`, `process.name`, and `process.executable`.
+  - Implication: escalate when "lsass.exe" creates "mimilsa.log", especially at "C:\Windows\System32\mimilsa.log" or a staging path; lower suspicion only when the same host, path, and process evidence align with an authorized red-team, responder, malware-analysis, or isolated lab run.
+
+- Was the log handled like credential material after creation?
+  - Focus: file events on the same `host.id` around `file.path`, including `file.Ext.original.path`, `file.extension`, and the acting `process.executable`.
+  - Implication: escalate when "mimilsa.log" is copied, renamed, archived, deleted, or paired with DLL/archive artifacts such as "mimilib.dll"; absence of follow-on file handling does not clear the alert because the log creation itself can mean credential capture.
+  - Hint: pivot first on the exact `file.path` and rename source path, then on companion "mimilib.dll" file events on the same host. !{investigate{"description":"","label":"MemSSP log and companion file events","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","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":"file.Ext.original.path","queryType":"phrase","value":"{{file.path}}","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":"file.name","queryType":"phrase","value":"mimilib.dll","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+
+- Which process activity likely enabled MemSSP before LSASS wrote the log?
+  - Focus: process starts on the same `host.id`: `process.command_line`, `process.executable`, `process.parent.executable`, `process.code_signature.trusted`, and `process.Ext.token.integrity_level_name`.
+  - Implication: escalate when "misc::memssp", Mimikatz/Invoke-Mimikatz, "mimilib.dll", PowerShell, rundll32, regsvr32, unsigned helpers, or high-integrity/system tooling appear before the write; a clean process search narrows the launcher only if collection covers that window.
+  - Hint: search backward from alert `@timestamp` for process starts containing "memssp", "mimikatz", "mimilib", or script/LOLBIN launchers on the same `host.id`.
+
+- Which accounts may have been exposed after the log appeared?
+  - Why: MemSSP records credentials from successful authentications after injection, so exposure depends on who logged on or unlocked the host after the write.
+  - Focus: if Windows Security authentication logs are available, correlate same-`host.id` events after `@timestamp` with `winlog.event_id`, `winlog.event_data.TargetUserName`, `winlog.logon.type`, `source.ip`, and `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Authentication events after MemSSP log creation","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4776","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}}
+  - Implication: escalate when privileged, service, machine, remote, or unexpected NTLM logons appear after creation; if policy permits secure collection, accounts visible in "mimilsa.log" are direct exposure evidence. Missing Windows Security telemetry or uncollected log content is unresolved, not benign.
+
+- Does the host show default in-memory MemSSP only, or a persistent SSP setup?
+  - Why: persistent SSP changes survive a single process-memory event and widen eradication scope beyond the observed log file.
+  - Focus: companion DLL file events (`file.path`, `file.extension`) and, when registry telemetry is available, LSA Security Packages changes in `registry.path` and `registry.data.strings`.
+  - Implication: escalate persistence scope when "mimilib.dll" or an unfamiliar SSP DLL is placed for loading, or when LSA Security Packages registry data names it; if registry telemetry is unavailable, persistence is unresolved and must not be used to close.
+
+- If local evidence is suspicious or unresolved, what related alert activity changes scope?
+  - Focus: related alerts for the same `host.id` in the last 48 hours covering delivery, privilege escalation, LSASS access, persistence, lateral movement, or additional credential access. !{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"}}
+  - Hint: use the `user.id` alert pivot only when a non-SYSTEM account from process or authentication evidence becomes part of scope. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden response when related alerts explain precursor access or follow-on use of captured credentials; keep scope local only when artifact, lineage, exposure, and persistence evidence remain bounded and no contradictory alerts appear.
+
+- Escalate when alert-local artifact, file handling, enabling process, credential exposure, persistence, or related alerts point to hostile MemSSP use; close only when telemetry and outside confirmation align with one authorized lab, red-team, or responder workflow; preserve and escalate when evidence is mixed, missing, or credential exposure cannot be scoped.
+
+
+*False positive analysis*
+
+
+- Normal Windows operation should not create "mimilsa.log". Authorized red-team, responder, malware-analysis, or isolated lab validation is the narrow benign path. Confirm by verifying alert-local `file.path`/`process.executable`, enabling `process.command_line`/`process.parent.executable`, file handling, asset identity, and any credential-exposure evidence all align with the same case; if any dimension contradicts it, do not close as benign.
+- If exercise or case records are unavailable, do not exception a first occurrence; require a previously confirmed exercise or responder case plus the same stable pattern (`host.id`, `file.path`, `process.executable`, enabling `process.command_line`, and file-handling behavior) across prior alerts. Avoid exceptions on `file.name`, `process.name`, or host alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse containment and document the exact exercise or responder case with `host.id`, `file.path`, `process.executable`, enabling command/parent, and file-handling evidence. Create an exception only for the recurring same pattern.
+- If suspicious but unconfirmed, preserve evidence before containment: export the alert, surrounding process/file events, related alerts, any available authentication events, and securely collect "mimilsa.log" as credential material if policy permits. Capture volatile LSASS state or memory through approved IR tooling before rebooting because restart can remove in-memory evidence.
+- Then apply reversible containment based on scope: restrict network access for the affected `host.id`, heighten monitoring, and scrutinize accounts identified in "mimilsa.log" or post-write logons. Avoid deleting the log, terminating suspected tooling, or rebooting until preservation is complete.
+- If confirmed malicious, isolate or rebuild the host as host criticality allows; remove "mimilsa.log", companion DLLs, archives, and any persistent SSP configuration discovered; terminate tooling only after evidence capture; then reboot or rebuild to clear injected SSP state.
+- Reset or rotate credentials for privileged, service, machine, and lateral-movement-relevant accounts shown in the log content or post-write authentication evidence; review related hosts/accounts before broad resets when exposure is uncertain.
+- Post-incident hardening: reduce interactive logons to high-value hosts, restrict debug and LSASS access, review LSA protection and allowed SSP configuration where compatible, monitor for "mimilsa.log" and "mimilib.dll", and document telemetry gaps that limited credential-exposure or persistence scoping.
+
+
+==== 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-11-setup[Sysmon Event ID 11 - File Create]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+file where host.os.type == "windows" and file.name : "mimilsa.log" and process.name : "lsass.exe"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: OS Credential Dumping
+** ID: T1003
+** Reference URL: https://attack.mitre.org/techniques/T1003/
+* Technique:
+** Name: Modify Authentication Process
+** ID: T1556
+** Reference URL: https://attack.mitre.org/techniques/T1556/
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Boot or Logon Autostart Execution
+** ID: T1547
+** Reference URL: https://attack.mitre.org/techniques/T1547/
+* Sub-technique:
+** Name: Security Support Provider
+** ID: T1547.005
+** Reference URL: https://attack.mitre.org/techniques/T1547/005/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-hidden-run-key-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-hidden-run-key-detected.asciidoc
new file mode 100644
index 0000000000..772dc17d1f
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-hidden-run-key-detected.asciidoc
@@ -0,0 +1,195 @@
+[[prebuilt-rule-8-19-24-persistence-via-hidden-run-key-detected]]
+=== Persistence via Hidden Run Key Detected
+
+Identifies a persistence mechanism that utilizes the NtSetValueKey native API to create a hidden (null terminated) registry key. An adversary may use this method to hide from system utilities such as the Registry Editor (regedit).
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.registry-*
+* winlogbeat-*
+* logs-windows.sysmon_operational-*
+* endgame-*
+* logs-crowdstrike.fdr*
+* 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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/outflanknl/SharpHide
+* https://github.com/ewhitehats/InvisiblePersistence/blob/master/InvisibleRegValues_Whitepaper.pdf
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Resources: Investigation Guide
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Crowdstrike
+* Data Source: SentinelOne
+* Data Source: Microsoft Defender XDR
+
+*Version*: 216
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Persistence via Hidden Run Key Detected*
+
+
+
+*Possible investigation steps*
+
+
+- Does the registry event support hidden or null-terminated Run-value semantics, and what would it launch?
+  - Why: trailing Run-key `registry.path` with launch data can indicate a null-prefixed value name created through NtSetValueKey; raw telemetry can preserve it when regedit does not.
+  - Focus: `registry.path`, `registry.hive`, `registry.value`, `registry.data.type`, and `registry.data.strings`.
+  - Hint: trust the registry event over GUI rendering; record exact `registry.data.strings` before tools normalize the hidden value name.
+  - Implication: escalate when raw evidence supports hidden-value semantics and an unexpected command; lower suspicion only when exact raw value, payload, user, and host match authorized hidden-registry testing. The alert indicates a hiding technique, not one tool.
+
+- Which hive and logon scope would activate the hidden autorun?
+  - Focus: `registry.hive`, `registry.path`, `user.id`, and `host.id`.
+  - Implication: prioritize host-wide containment for machine hives and user-focused containment for user hives; lower urgency only when raw value evidence supports a constrained test user or lab host.
+
+- Which process wrote the hidden value, and does its identity and launch chain fit the expected test or validation workflow?
+  - Focus: `process.entity_id`, `process.executable`, `process.command_line`, `process.parent.executable`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Hint: use the writer's process-start event on `host.id` and `process.entity_id` to confirm command line, parent, and signer. !{investigate{"description":"","label":"Process events for the registry writer","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the writer is a script host, document child, remote-admin tool, unsigned/untrusted binary, user-writable executable, or SharpHide-like command line; lower suspicion when signer, path, parent, command line, user, and host align with the same recognized test or validation component.
+
+- Did the hidden autorun command execute after logon or spawn suspicious follow-on activity?
+  - Focus: post-alert process starts on `host.id` where `process.executable` or `process.command_line` matches the `registry.data.strings` payload.
+  - Hint: for user-hive paths, include `user.id`; for machine-hive paths, check the next interactive logon. Use `process.parent.name` and `process.parent.executable` to identify the launcher. !{investigate{"description":"","label":"Process starts matching the hidden Run payload","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.command_line","queryType":"phrase","value":"{{registry.data.strings}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}}
+  - Implication: escalate when the payload launches after logon, runs through a shell, script host, LOLBin, user-writable path, or obfuscated chain, or creates unusual children; no later launch leaves execution unproven, not benign, unless the value and writer are fully explained.
+
+- Did the same writer modify other startup or hidden-registry locations around the alert time?
+  - Focus: writer-scoped registry events, especially `registry.path`, `registry.key`, `registry.value`, and `registry.data.strings` for Run, RunOnce, Policies\Explorer\Run, or related startup paths.
+  - Hint: start with `host.id` and `process.entity_id`, then widen only to the same host and startup-path family. !{investigate{"description":"","label":"Registry events from the writer process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the process spreads persistence across startup keys, rewrites the same path, or creates additional hidden or malformed values; a single bounded change lowers scope only after writer and payload are independently explained.
+
+- If local evidence remains suspicious or unresolved, do same-user or same-host alerts show broader activity?
+  - Focus: recent same-`user.id` alerts tied to persistence, defense evasion, credential access, or lateral movement. !{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: review same-`host.id` alerts when local evidence is suspicious or incomplete. !{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 containment when related alerts show precursor access, more persistence, credential abuse, or follow-on movement; keep local only when related alerts are absent and the hidden value is otherwise exactly explained.
+
+- Escalate when hidden Run semantics pair with a suspicious writer, payload, later execution, adjacent persistence, or related alerts; close only when same-host telemetry and corroborating test or validation records explain the exact value, writer, payload, user, and host with no contradictions; preserve registry, process, and payload evidence and escalate when answers remain mixed or incomplete.
+
+
+*False positive analysis*
+
+
+- Authorized adversary emulation, detection validation, or security-product testing can create hidden Run values to test detection of regedit-hidden startup entries. Close only when `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `registry.path`, `registry.data.strings`, `user.id`, and `host.id` match the same authorized test chain, and any later `process.command_line` stays bounded to it. Without validation records, do not close on recurrence alone; keep suspicious or unresolved until exact test scope is verified.
+- Routine software installation can explain ordinary Run-key writes, but should not require a hidden or null-terminated value name. Treat installer or support claims as insufficient unless telemetry proves the exact hidden value, writer, payload, and execution pattern belong to a recognized lab, validation, or product-test workflow.
+- Before an exception, require a verified test or validation workflow, then confirm the same `process.executable`, `process.code_signature.subject_name`, `registry.path`, `registry.data.strings`, `user.id`, and `host.id` pattern recurs across prior alerts from this rule. Build the exception from that minimum confirmed workflow; avoid exceptions on Run paths alone, `process.name` alone, payload strings alone, or the rule name alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse any temporary containment and record the `process.executable`, signer, `process.command_line`, `registry.path`, exact `registry.data.strings`, `user.id`, `host.id`, and later logon execution pattern that proved the authorized workflow. Keep any exception narrow and tied to the recurring workflow.
+- If suspicious but unconfirmed, first preserve the raw registry event, affected Run-key hive with the hidden value intact when possible, writer `process.entity_id`, writer command line, process lineage, payload string from `registry.data.strings`, and related-alert context. Then apply reversible containment tied to those findings, such as isolating the host if its role tolerates it, temporarily preventing the affected user from logging back in, or blocking execution of the referenced payload.
+- If confirmed malicious, preserve the same registry and process evidence before destructive action. Use tooling that can enumerate null-prefixed value names to remove the hidden autorun, collect or quarantine the referenced payload artifact, and review the same `process.entity_id`, `registry.path`, and startup-key family for additional hidden or visible autoruns before cleanup. Terminate a recovered payload process only after recording its `process.entity_id` and command line.
+- After containment, review other hosts and users for the same `registry.data.strings`, startup-path family, signer, or payload path before deleting artifacts, then verify that no additional Run or RunOnce locations reference the same payload.
+- Post-incident hardening: restrict startup-key modifications to recognized installers and management tools, retain registry and process telemetry needed to correlate hidden Run-key writes with writer lineage and logon execution, and record any adjacent hidden-registry or startup-persistence variant in case notes.
+
+
+==== 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-reg-setup[Sysmon Registry Events]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+registry where host.os.type == "windows" and event.type == "change" and length(registry.data.strings) > 0 and
+  
+  /* Registry Path ends with backslash */
+  registry.path : "*\\Run\\" and
+  registry.path : (
+    "*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\",
+    "*\\Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Run\\",
+    "*\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\"
+  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Boot or Logon Autostart Execution
+** ID: T1547
+** Reference URL: https://attack.mitre.org/techniques/T1547/
+* Sub-technique:
+** Name: Registry Run Keys / Startup Folder
+** ID: T1547.001
+** Reference URL: https://attack.mitre.org/techniques/T1547/001/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Native API
+** ID: T1106
+** Reference URL: https://attack.mitre.org/techniques/T1106/
+* 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/
+* 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-24/prebuilt-rule-8-19-24-persistence-via-microsoft-office-addins.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-microsoft-office-addins.asciidoc
new file mode 100644
index 0000000000..0c33710187
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-microsoft-office-addins.asciidoc
@@ -0,0 +1,177 @@
+[[prebuilt-rule-8-19-24-persistence-via-microsoft-office-addins]]
+=== Persistence via Microsoft Office AddIns
+
+Detects attempts to establish persistence on an endpoint by abusing Microsoft Office add-ins.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.file-*
+* winlogbeat-*
+* logs-windows.sysmon_operational-*
+* endgame-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-crowdstrike.fdr*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://labs.withsecure.com/publications/add-in-opportunities-for-office-persistence
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Microsoft Defender XDR
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 314
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Persistence via Microsoft Office AddIns*
+
+
+
+*Possible investigation steps*
+
+
+- Which Office add-in autoload mechanism does the alert show?
+  - Focus: alert `file.path`, `file.name`, `file.extension`, and `user.id` on `host.id`: "wll" maps to Word Startup, "xla"/"xlam" to Excel XLSTART, and "xll"/"ppa"/"ppam" to add-in locations that may need loader settings.
+  - Implication: escalate when a user-profile Office startup or add-in path receives a one-off or user-initiated add-in; lower suspicion only when path, name, extension, writer, and provenance all fit the same recognized deployment or repair.
+
+- Does the artifact identity or provenance look like a staged payload?
+  - Why: DLL-style "wll"/"xll" and Office container add-ins have different expected headers, so rename and origin fields can expose payload staging.
+  - Focus: `file.Ext.header_bytes`, `file.Ext.original.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier`.
+  - Implication: escalate when headers, rename history, internet-zone provenance, or archive/mail-cache origin conflict with the claimed add-in; lower suspicion when format and provenance align with the same recognized vendor package.
+
+- Does the writer process fit an add-in installer or a dropper chain?
+  - Focus: writer `process.executable`, `process.command_line`, `process.parent.executable`, and `process.code_signature.subject_name`.
+  - Implication: escalate when browsers, mail clients, scripting engines, archive tools, or unsigned user-writable binaries write the add-in; lower suspicion when signer, path, command line, and parent all match the same recognized installer or managed integration. Signer trust alone never clears the placement.
+
+- If registry telemetry is available, did the writer create loader settings required for this add-in type?
+  - Why: the alert is a file write; loader settings, when visible, show whether Office was configured to consume the add-in rather than merely store it.
+  - Focus: same `host.id` and writer `process.entity_id`; check `registry.path`, `registry.value`, `registry.data.type`, and `registry.data.strings` for Office loader values pointing to the alerted file. !{investigate{"description":"","label":"Registry events for the same writing 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":"registry","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when loader values reference the alerted file or directory; do not require registry corroboration when path, provenance, or writer evidence is already suspicious. Missing registry telemetry is unresolved, not benign.
+
+- Did Office later load the add-in or spawn follow-on activity from it?
+  - Focus: later Office `process.name` values "WINWORD.EXE", "EXCEL.EXE", or "POWERPNT.EXE" on the same `host.id`, Office `process.entity_id`, child `process.parent.entity_id`, child `process.executable`, and, if library telemetry exists, `dll.path` matching the add-in.
+    - !{investigate{"description":"","label":"Office process starts on the host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"WINWORD.EXE","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"EXCEL.EXE","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"POWERPNT.EXE","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Library loads for the add-in path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"dll.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Hint: missing library telemetry is unresolved, not benign; use those pivots and child process expansion from recovered Office instances as fallback execution evidence.
+  - Implication: escalate when Office loads the add-in path, starts a child from the same session, or touches a payload dropped with the add-in; do not wait for library telemetry when file, writer, or loader evidence already warrants escalation.
+
+- If local evidence is suspicious or unresolved, what related host activity changes scope?
+  - Focus: related alerts on the same `host.id`, especially document delivery, script execution, suspicious file writes, Office child processes, or additional persistence activity. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: expand scope when related host alerts connect the add-in write to delivery, execution, credential access, or another persistence mechanism; do not close solely because related alerts are absent.
+
+- What disposition do the add-in mechanism, artifact identity, writer lineage, loader state, Office execution, and scope support?
+  - Escalate on suspicious provenance, unexpected writer lineage, matching loader values, Office follow-on execution, or related host activity; close only when file, writer, provenance, loader state, and Office behavior align with one verified deployment or integration and no contradictions remain; preserve artifacts and escalate mixed or incomplete evidence.
+
+
+*False positive analysis*
+
+
+- Managed Office add-in deployment, repair, and productivity, accessibility, or CRM first-use installs can place files in these paths. Close only when writer `process.executable`, `process.command_line`, signer `process.code_signature.subject_name`, parent `process.parent.executable`, final `file.path`, required loader state, provenance fields, later Office `process.name`, and child `process.executable` all align with one deployment or vendor workflow and no contradictory evidence remains. Use change or inventory records as corroboration, not as a telemetry substitute.
+- Before creating an exception, build it from the minimum current-case pattern: `file.path`, writer `process.code_signature.subject_name`, writer `process.parent.executable`, required loader-state pattern, and `host.id` or `user.id` scope. Avoid exceptions on Office startup directories, file extensions, or Office process names alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and document the verified workflow with `file.path`, `file.hash.sha256`, writer `process.executable`, signer `process.code_signature.subject_name`, and any recovered loader-state evidence. Create any exception from that exact workflow pattern and scope it narrowly to the confirmed host or user cohort.
+- If suspicious but unconfirmed, preserve the alert export, the add-in file and hash from `file.path` and `file.hash.sha256`, writer `process.entity_id` and `process.command_line`, and any recovered loader-state, library-load, or child-process evidence before deleting anything. Apply reversible containment first, such as quarantining the add-in file, disabling the affected Office add-in path, or temporarily restricting Office execution on the host.
+- If confirmed malicious, isolate the host if its role can tolerate interruption, then terminate responsible Office or loader processes only after preserving their entity IDs, command lines, and the add-in file evidence. Remove the malicious add-in, clear associated Office loader configuration, restore affected Office add-in settings, and remediate the delivery path that introduced the file. Reset credentials only if the investigation also shows account misuse.
+- Review related hosts and users for the same `file.path`, `file.hash.sha256`, writer lineage, and loader-state pattern before eradication. For Word WLL cases, do not rely on the Office UI alone to prove the add-in is disabled; verify the file and supporting configuration are gone.
+- Post-incident hardening: restrict write access to Office startup directories and add-in loader locations, prefer signed managed add-in deployment, retain process/file plus registry or library telemetry needed to confirm later Office execution, and document adjacent variants such as Word WLL autoload abuse or registry-backed Office add-in loading in the case record.
+
+
+==== 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-11-setup[Sysmon Event ID 11 - File Create]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+file where host.os.type == "windows" and event.type != "deletion" and
+ file.extension : ("wll","xll","ppa","ppam","xla","xlam") and
+ file.path : (
+    "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Word\\Startup\\*",
+    "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\AddIns\\*",
+    "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Excel\\XLSTART\\*",
+
+    /* Crowdstrike specific condition as it uses NT Object paths */
+    "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Roaming\\Microsoft\\Word\\Startup\\*",
+    "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Roaming\\Microsoft\\AddIns\\*",
+    "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Roaming\\Microsoft\\Excel\\XLSTART\\*"
+ ) and
+ not (file.name : "~$*" and process.name : "excel.exe" and ?file.size in (0, 165))
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Office Application Startup
+** ID: T1137
+** Reference URL: https://attack.mitre.org/techniques/T1137/
+* Sub-technique:
+** Name: Add-ins
+** ID: T1137.006
+** Reference URL: https://attack.mitre.org/techniques/T1137/006/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc
new file mode 100644
index 0000000000..93bbbd5343
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc
@@ -0,0 +1,200 @@
+[[prebuilt-rule-8-19-24-persistence-via-telemetrycontroller-scheduled-task-hijack]]
+=== Persistence via TelemetryController Scheduled Task Hijack
+
+Detects the successful hijack of Microsoft Compatibility Appraiser scheduled task to establish persistence with an integrity level of system.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* endgame-*
+* logs-crowdstrike.fdr*
+* logs-endpoint.events.process-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-system.security*
+* logs-windows.forwarded*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.trustedsec.com/blog/abusing-windows-telemetry-for-persistence
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Windows Security Event Logs
+* Data Source: Microsoft Defender XDR
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 318
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Persistence via TelemetryController Scheduled Task Hijack*
+
+
+
+*Possible investigation steps*
+
+
+- What behavior path did the alert preserve from CompatTelRunner to the child?
+  - Why: "-cv" marks the TelemetryController handoff; the executable path before it is the key artifact.
+  - Focus: `process.parent.executable`, `process.command_line`, `process.executable`, `process.Ext.token.integrity_level_name`, and `user.id`.
+  - Implication: escalate when "CompatTelRunner.exe" launches a user-writable, script-hosted, renamed, or newly introduced child with SYSTEM context; lower suspicion only when the handoff resolves to a stable Microsoft telemetry component for this host, then still validate the registry state that produced it.
+
+- Does the child binary identity match the command path and expected telemetry role?
+  - Focus: `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.Ext.relative_file_creation_time`.
+  - Implication: escalate when metadata, signer, hash, or recent file age conflicts with the path or Microsoft telemetry role; lower suspicion when identity, signer, path, and age fit a stable Windows or enterprise diagnostic binary.
+
+- Which TelemetryController values enabled this launch, and which process wrote them?
+  - Focus: recovered registry events on `host.id` for TelemetryController `registry.path`, `registry.value`, `registry.data.strings`, and writer `process.executable`.
+  - Range: search back several days; the registry hijack can precede scheduled task execution.
+  - Hint: search the TelemetryController root and subkeys, compare command-like `registry.data.strings` to the alert child, and treat registry telemetry as recovery evidence; missing registry history leaves persistence unresolved. Do not clear only because startup folders or service keys are clean.
+  - Implication: escalate when a command value points to the alert child or another non-Windows binary or script and the same subkey enables execution; an unexpected writer exposes the privileged component that planted HKLM persistence. Lower suspicion only when values, writer, and child path all match one controlled diagnostic or test workflow.
+
+- Did the launched child stage or reuse artifacts that extend the persistence chain?
+  - Focus: same-process file events on `host.id` using `process.entity_id`, or `process.pid` in a tight alert window: `file.path`, `file.Ext.original.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and later `process.executable` reuse. !{investigate{"description":"","label":"File events for the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the child writes executable or scriptable content to user-writable, startup, service, or task paths, especially with external provenance or later execution; absent file telemetry does not clear a suspicious command or registry handoff.
+
+- Did the launched child contact destinations inconsistent with telemetry or the signer?
+  - Focus: same-process DNS and connection events on `host.id`: `dns.question.name`, `dns.resolved_ip`, `destination.ip`, `destination.port`, and `destination.as.organization.name`. !{investigate{"description":"","label":"Network events for the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: Missing network telemetry is unresolved, not benign. Treat infrastructure ownership as context rather than a verdict.
+  - Implication: escalate when the child reaches public, rare, or signer-misaligned infrastructure; lower suspicion when destinations consistently fit Microsoft telemetry, internal servicing, or the same verified diagnostic workflow.
+
+- If local evidence remains suspicious or unresolved, is this a local test pattern or repeated TelemetryController persistence?
+  - Focus: recent alerts for the same `process.executable` before broader host review. !{investigate{"description":"","label":"Alerts involving the same child path","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: use host alert history only after child identity, command line, registry, file, or network evidence remains suspicious or unresolved. !{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 the same child path, TelemetryController pattern, or follow-on alert chain appears on unrelated hosts; keep scope local when telemetry ties the exact child, writer, values, and host scope to one verified lab or diagnostic workflow.
+
+- Escalate when the handoff, child identity, registry writer/values, artifacts, destinations, or alert history show arbitrary or staged execution through TelemetryController; close only when the same evidence ties the exact child, writer, values, and scope to a controlled diagnostic or validation workflow; preserve artifacts and escalate when registry, file, or network evidence is missing or contradictory.
+
+
+*False positive analysis*
+
+
+- Non-Microsoft TelemetryController command registration is an operational anti-pattern. Controlled image-validation or compatibility-lab workflows can still trigger this rule when they register a signed diagnostic or servicing binary. Close benign only when telemetry ties `process.command_line`, `process.executable`, `process.hash.sha256`, TelemetryController `registry.path`, `registry.data.strings`, writer `process.executable`, and the `host.id` cohort to the same build or lab workflow. Use records only as corroboration; before exceptioning, validate recurrence for the same payload identity, writer, value pattern, and lab-host scope.
+- Authorized adversary-emulation or detection-validation tests can deliberately hijack TelemetryController. Close benign only when `process.command_line`, `process.hash.sha256`, TelemetryController `registry.path`, expected `host.id` or `user.id` test scope, and registry-writing `process.executable` all match exercise telemetry. Use engagement records only as corroboration; before exceptioning, verify the same payload hash or path and writer recur only on known test assets and not unrelated production hosts. Do not exception on `process.parent.name`, "CompatTelRunner.exe", "-cv", or `process.name` alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign:
+  - Record the TelemetryController `registry.path`, child `process.executable` or `process.hash.sha256`, writer `process.executable`, host scope, and telemetry that proved the workflow, then reverse any temporary containment. Build exceptions from that minimum pattern plus `host.id`, not from `process.parent.name`, "CompatTelRunner.exe", or "-cv" alone.
+- If suspicious but unconfirmed:
+  - Preserve the alert process record, recovered TelemetryController registry events, writer lineage, written `file.path` artifacts, and any `dns.question.name` or `destination.ip` indicators before cleanup.
+  - Apply reversible containment tied to the findings, such as temporarily disabling the suspect TelemetryController subkey or blocking the child binary or destination. Escalate to host isolation only when host criticality allows it and same-process artifacts or destinations show active follow-on behavior.
+- If confirmed malicious:
+  - Isolate the host and terminate the malicious child only after recording the child process identity, command line, TelemetryController values, writer lineage, written `file.path`, `process.hash.sha256`, and destination indicators. If direct endpoint response is unavailable, escalate with that evidence set to the team that can contain the asset.
+  - Remove the malicious TelemetryController subkey or restore its values to known-good state, then remove only the payloads and additional persistence artifacts identified during the investigation. Validate that the "Microsoft Compatibility Appraiser" task no longer launches the malicious child, and scope other hosts for the same child path or registry pattern before deleting artifacts.
+- Post-incident hardening:
+  - Restrict local admin rights on exposed hosts, keep process, registry, file, and network telemetry for this key family enabled, and record any TelemetryController visibility gaps in the case notes.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/crowdstrike-integration[CrowdStrike]
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+- https://ela.st/audit-process-creation[Windows Process Creation Logs]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+  process.parent.name : "CompatTelRunner.exe" and process.args : "-cv*" and
+  not process.name : ("conhost.exe",
+                      "DeviceCensus.exe",
+                      "CompatTelRunner.exe",
+                      "DismHost.exe",
+                      "rundll32.exe",
+                      "powershell.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/
+* Technique:
+** Name: Hijack Execution Flow
+** ID: T1574
+** Reference URL: https://attack.mitre.org/techniques/T1574/
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* 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/
+* Technique:
+** Name: Hijack Execution Flow
+** ID: T1574
+** Reference URL: https://attack.mitre.org/techniques/T1574/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-update-orchestrator-service-hijack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-update-orchestrator-service-hijack.asciidoc
new file mode 100644
index 0000000000..2687d7544d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-update-orchestrator-service-hijack.asciidoc
@@ -0,0 +1,211 @@
+[[prebuilt-rule-8-19-24-persistence-via-update-orchestrator-service-hijack]]
+=== Persistence via Update Orchestrator Service Hijack
+
+Identifies potential hijacking of the Microsoft Update Orchestrator Service to establish persistence with an integrity level of SYSTEM.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* endgame-*
+* logs-endpoint.events.process-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/irsl/CVE-2020-1313
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Use Case: Vulnerability
+* Resources: Investigation Guide
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Microsoft Defender XDR
+* Data Source: Sysmon
+* Data Source: Windows Security Event Logs
+* Data Source: SentinelOne
+
+*Version*: 319
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Persistence via Update Orchestrator Service Hijack*
+
+
+
+*Possible investigation steps*
+
+
+- What did UsoSvc actually launch, and does the child identity fit Windows or Office servicing?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Hint: use `process.parent.command_line` to confirm svchost is hosting UsoSvc, not just sharing the name.
+  - Implication: escalate when UsoSvc launches a renamed, user-writable, unsigned, rare, or non-servicing child; lower concern only when path, signer, and parent service context match a recognized Windows Update or Click-to-Run component. Identity alone does not clear it.
+
+- Does the command line show attacker-controlled work running with service-level privilege?
+  - Why: on unpatched hosts, CVE-2020-1313 ScheduleWork can queue signed System32 or Common Files binaries with attacker-controlled arguments.
+  - Focus: `process.command_line`, `process.Ext.token.integrity_level_name`, and `user.id`.
+  - Implication: escalate when "cmd.exe", "rundll32.exe", "regsvr32.exe", a scripting host, or another signed binary runs shell, download, staging, redirection, or persistence arguments under SYSTEM or high integrity; lower concern when arguments fit the exact servicing binary workflow.
+
+- If registry telemetry is available, was matching work queued under the Update Orchestrator UScheduler path?
+  - Focus: same `host.id` registry events for `registry.path` under "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Orchestrator\UScheduler", with `registry.value`, `registry.data.strings`, and writer `process.executable`.
+  - Range: search several days before the alert; queued work can run overnight or after a multi-day service window.
+  - Hint: interpret queued strings with `registry.data.type`, then compare them to `process.command_line` and `process.executable`; missing registry telemetry is unresolved, not benign.
+  - Implication: escalate when the queue names the same unusual child or arguments, especially from a non-servicing writer; absent queue history only limits this corroborator.
+
+- Did the child stage artifacts or spawn follow-on processes that extend the abuse?
+  - Focus: child starts from `process.entity_id`; if file telemetry exists, same-process `file.path`, `file.Ext.original.path`, and `file.origin_url`.
+    - !{investigate{"description":"","label":"Child process starts from the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"File events for the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: scope file pivots with `host.id` plus `process.entity_id`; use `host.id` plus `process.pid` and a tight alert window only when entity ID is absent. Missing file telemetry limits artifact review, but child-process and command evidence can justify escalation.
+  - Implication: escalate when the child writes executable or scriptable content to user-writable or deceptive paths, renames staged content, or launches written artifacts; lower concern when activity stays inside the recognized servicing path with no follow-on execution.
+
+- If network telemetry is available, does the child contact destinations consistent with servicing?
+  - Focus: process-scoped DNS `dns.question.name` and `dns.resolved_ip`, then connections by `destination.ip`, `destination.port`, and `destination.as.organization.name`. !{investigate{"description":"","label":"Network events for the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: use "lookup_result" DNS events for populated `dns.resolved_ip`; scope with `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` and a tight alert window. Infrastructure ownership is context, not a verdict; missing network telemetry is unresolved, not benign.
+  - Implication: escalate when the child reaches rare or public infrastructure unrelated to Microsoft servicing, the signer, or recovered queue; lower concern when destinations fit the signed binary's normal update or repair endpoints.
+
+- If local evidence remains suspicious or unresolved, do related alerts change scope?
+  - Focus: compare recent alerts for the same `process.executable`. !{investigate{"description":"","label":"Alerts involving the same child executable","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: review same `host.id` alerts only when child identity, command, queue, artifact, or destination evidence needs scope. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same child path or host shows repeated privilege-escalation, persistence, staging, or follow-on alerts; keep urgency local when isolated and no corroborating alert history appears.
+
+- Escalate on attacker-controlled UsoSvc child identity or command intent, using queue, artifact, destination, or related-alert evidence as corroboration; close only when alert-local and recovered evidence tie to one exact servicing or authorized validation workflow without contradictions; preserve artifacts and escalate when evidence is mixed, incomplete, or unavailable.
+
+
+*False positive analysis*
+
+
+- Windows Update, repair, or Office Click-to-Run servicing can trigger this rule when UsoSvc queues a servicing component outside the exclusions. Close from telemetry first: child path, signer, command line, parent service context, UScheduler queue content when available, artifacts, destinations, and `host.id` cohort must align with one recognized servicing workflow. Patch-window or change records may corroborate; prior alerts only prove exception stability after current evidence fits.
+- Authorized exploit-validation or adversary-emulation tests can exercise Update Orchestrator abuse. Confirm stable payload identity such as `process.hash.sha256`, `process.command_line`, expected `host.id` or `user.id` test scope, matching queue content when available, and no spread to unrelated production hosts. Use engagement records or prior test alerts only as corroboration, and do not exception on `process.parent.executable`, "UsoSvc", or `process.name` alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign:
+  - Record the exact evidence that proved the servicing or test workflow: child identity, command line, parent service context, queue content when available, same-process artifacts or destinations, and recurrence or records. Then reverse temporary containment and build any exception from that minimum pattern plus `host.id`, not from UsoSvc or a generic signed-binary condition.
+- If suspicious but unconfirmed:
+  - Preserve a case export with the alert process instance, process tree, command line, UScheduler queue values when available, writer-process details, written artifacts, destination indicators, and related-alert context before cleanup.
+  - Apply reversible containment tied to the finding, such as blocking the child hash or destination, temporarily disabling the queued work after preservation, or increasing host monitoring. Escalate to host isolation only when host criticality allows it and artifacts, destinations, or related alerts show active follow-on behavior.
+- If confirmed malicious:
+  - Preserve the case export first: child `process.entity_id` or `process.pid`, command line, queue values, writer lineage, payload hashes, artifact paths, and destination indicators. Then isolate the host when the identity, command, queue, artifact, or destination evidence confirms unauthorized UsoSvc execution.
+  - Remove the malicious queued work or restore the Update Orchestrator registry state to known-good, eradicate only payloads and persistence artifacts identified during triage, validate that UsoSvc returns to recognized servicing children, and review other hosts for the same child path or queue pattern before deleting preserved evidence.
+- Post-incident hardening:
+  - Apply the June 2020 or later Windows security updates where still applicable because the fix blocks untrusted caller queuing, retire unsupported builds, restrict write paths that can feed Update Orchestrator abuse, and retain registry/process telemetry for UScheduler queue changes.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+- https://ela.st/audit-process-creation[Windows Process Creation Logs]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+  process.parent.executable : "C:\\Windows\\System32\\svchost.exe" and
+  process.parent.args : "UsoSvc" and
+  not process.executable :
+          ("?:\\ProgramData\\Microsoft\\Windows\\UUS\\Packages\\*\\amd64\\MoUsoCoreWorker.exe",
+          "?:\\Windows\\System32\\UsoClient.exe",
+          "?:\\Windows\\System32\\MusNotification.exe",
+          "?:\\Windows\\System32\\MusNotificationUx.exe",
+          "?:\\Windows\\System32\\MusNotifyIcon.exe",
+          "?:\\Windows\\System32\\WerFault.exe",
+          "?:\\Windows\\System32\\WerMgr.exe",
+          "?:\\Windows\\UUS\\amd64\\MoUsoCoreWorker.exe",
+          "?:\\Windows\\System32\\MoUsoCoreWorker.exe",
+          "?:\\Windows\\UUS\\amd64\\UsoCoreWorker.exe",
+          "?:\\Windows\\System32\\UsoCoreWorker.exe",
+          "?:\\Program Files\\Common Files\\microsoft shared\\ClickToRun\\OfficeC2RClient.exe") and
+  not process.name : ("MoUsoCoreWorker.exe", "OfficeC2RClient.exe")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Create or Modify System Process
+** ID: T1543
+** Reference URL: https://attack.mitre.org/techniques/T1543/
+* Sub-technique:
+** Name: Windows Service
+** ID: T1543.003
+** Reference URL: https://attack.mitre.org/techniques/T1543/003/
+* Technique:
+** Name: Hijack Execution Flow
+** ID: T1574
+** Reference URL: https://attack.mitre.org/techniques/T1574/
+* Sub-technique:
+** Name: Services Registry Permissions Weakness
+** ID: T1574.011
+** Reference URL: https://attack.mitre.org/techniques/T1574/011/
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Exploitation for Privilege Escalation
+** ID: T1068
+** Reference URL: https://attack.mitre.org/techniques/T1068/
+* Technique:
+** Name: Hijack Execution Flow
+** ID: T1574
+** Reference URL: https://attack.mitre.org/techniques/T1574/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-wmi-standard-registry-provider.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-wmi-standard-registry-provider.asciidoc
new file mode 100644
index 0000000000..64ca9963f2
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-persistence-via-wmi-standard-registry-provider.asciidoc
@@ -0,0 +1,222 @@
+[[prebuilt-rule-8-19-24-persistence-via-wmi-standard-registry-provider]]
+=== Persistence via WMI Standard Registry Provider
+
+Identifies use of the Windows Management Instrumentation StdRegProv (registry provider) to modify commonly abused registry locations for persistence.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.registry-*
+* endgame-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://learn.microsoft.com/en-us/previous-versions/windows/desktop/regprov/stdregprov
+* https://www.elastic.co/security-labs/hunting-for-persistence-using-elastic-security-part-1
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 114
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Persistence via WMI Standard Registry Provider*
+
+
+*Possible investigation steps*
+
+
+- Which StdRegProv-backed persistence value changed, and what will it run?
+  - Why: StdRegProv can set logon and service ASEPs through "WmiPrvSe.exe" without a child process from the requester; registry value data is the payload clue.
+  - Focus: `registry.path`, `registry.value`, `registry.data.type`, and `registry.data.strings`.
+  - Implication: escalate when machine-wide Run/RunOnce, Winlogon shell, policy script, "ServiceDLL", or "ImagePath" values launch user-writable, share-hosted, script-host, shell-replacement, or unusual service content; lower suspicion only when the exact value and data match a recognized WMI-based deployment, configuration, or test workflow.
+
+- Who is the logical requester behind the WMI provider host?
+  - Why: `process.executable` usually identifies the provider host; effective process fields can identify the StdRegProv requester.
+  - Focus: `Effective_process.executable`, `Effective_process.name`, `Effective_process.entity_id`, `process.executable`, and `process.entity_id`.
+  - Hint: do not clear on the Microsoft-signed provider host alone; attacker and admin tooling can both route registry writes through "WmiPrvSe.exe".
+  - Implication: escalate when the requester is blank with suspicious value data, or is a script host, user-writable binary, Office/browser descendant, or unexpected remote administration tool; lower suspicion when requester path and name match the management or deployment component that owns the value.
+
+- Does the launch and session context fit the expected WMI workflow?
+  - Focus: `process.command_line`, `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, and `user.id`.
+  - Implication: escalate when WMI registry writes occur under an unexpected user, service, remote, or parent context; lower suspicion when parent chain, session type, and user scope match the same recognized management or validation workflow.
+
+- Did the payload referenced by the modified value execute?
+  - Focus: same-host process starts after `@timestamp` where `process.command_line` matches the payload from `registry.data.strings`. !{investigate{"description":"","label":"Process starts matching the modified registry payload","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.command_line","queryType":"phrase","value":"{{registry.data.strings}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}}
+  - Hint: empty results do not prove non-execution; quoting, environment expansion, or arguments may require manual parsing.
+  - Implication: escalate when the payload launches after the WMI-backed registry change, especially from user-writable, share-hosted, service, shell, or script paths; keep unresolved when value data cannot be matched directly.
+
+- Did the same requester cluster additional persistence changes on this host?
+  - Why: clustered ASEP writes separate one managed configuration change from service-plus-logon fallback persistence.
+  - Focus: same-host registry changes by `Effective_process.entity_id`, or `process.entity_id` when the effective requester is blank, reviewing `registry.path`, `registry.value`, and `registry.data.strings`. !{investigate{"description":"","label":"Registry changes by the same effective requester","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"Effective_process.entity_id","queryType":"phrase","value":"{{Effective_process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the same requester changes multiple ASEPs, service values, shell values, or policy scripts in one timeline; lower suspicion when activity is limited to one exact value with data matching the recognized workflow.
+
+- If local evidence remains suspicious or unresolved, does the requester or host recur in recent alerts?
+  - Focus: recent alerts for `Effective_process.executable`. !{investigate{"description":"","label":"Alerts involving the same effective requester path","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"Effective_process.executable","queryType":"phrase","value":"{{Effective_process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: run the host alert view only after the registry target, requester, session, or same-host registry cluster remains suspicious or unresolved. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the requester path or host shows repeated WMI abuse, persistence changes, or related execution alerts; keep local when recurrence is absent and local evidence supports a recognized workflow.
+
+- Escalate for unrecognized or blank requester with suspicious value data, unexpected remote/service context, clustered ASEP changes, execution, or alert recurrence; close only when modified ASEP, value data, requester, process/session context, cluster, and recurrence evidence bind one recognized management or test workflow with no contradictory registry data; preserve evidence and escalate if mixed or incomplete.
+
+
+*False positive analysis*
+
+
+- Configuration managers, endpoint-management agents, installers, and hardening baselines can use StdRegProv to set Run keys, policy scripts, or service values. Confirm `Effective_process.executable`, `Effective_process.name`, parent context, registry path/value/data, and host or user scope converge on the same workflow. Use change records, owner confirmation, or tool inventory when available; otherwise require the same requester path, modified ASEP, and registry data pattern to recur across prior alerts from this rule on the same managed host cohort.
+- Authorized security testing or detection validation can write persistence values through StdRegProv. Confirm the expected requester, exact value, value data, parsed payload path, test scope, and engagement records when available. Without records, require recurrence only on known test assets and no appearance on unrelated production hosts. Do not exception on `process.name`, "WmiPrvSe.exe", or a broad ASEP family alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign:
+  - Reverse temporary containment and document the requester identity, exact registry value and data, host or user scope, and the recurrence or records that proved the management or test workflow. Build exceptions from that minimum pattern, not from "WmiPrvSe.exe", `process.name`, or a broad registry key alone.
+- If suspicious but unconfirmed:
+  - Preserve the alert event, exact registry value and data, effective requester identifiers, parsed payload path from the value data, and same-requester registry timeline before changing host state.
+  - Apply reversible containment tied to the evidence, such as disabling the exact Run, policy, shell, or service value, blocking the requester path, or increasing monitoring on the affected host. Use host isolation only when host criticality allows it and the registry or requester evidence shows active persistence risk.
+- If confirmed malicious:
+  - Isolate the host after preserving the registry evidence, requester identifiers, parsed payload paths, and same-requester registry changes that established malicious activity; contain the affected account only when process or session evidence supports account misuse.
+  - Terminate the requester process only after recording the relevant entity or PID, then remove the malicious Run key, shell value, policy script, "ServiceDLL", or "ImagePath" change, restore the ASEP to known-good state, and remove only the payloads identified from the investigation.
+  - Review other hosts for the same requester path or registry pattern before deleting artifacts that may be needed for scoping.
+- Post-incident hardening:
+  - Restrict unnecessary WMI and remote administration access, monitor WMI-hosted writes to high-value ASEPs, keep endpoint process and registry telemetry enabled, and document any visibility gaps surfaced during 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
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+registry where host.os.type == "windows" and event.type == "change" and
+ registry.data.strings != null and process.name : "WmiPrvSe.exe" and
+ registry.path : (
+                  "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Command Processor\\Autorun",
+                  "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*",
+                  "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*",
+                  "HKLM\\Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Run\\*",
+                  "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*",
+                  "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*",
+                  "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\*",
+                  "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\*",
+                  "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\*",
+                  "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\*",
+                  "HKLM\\SYSTEM\\*ControlSet*\\Services\\*\\ServiceDLL",
+                  "HKLM\\SYSTEM\\*ControlSet*\\Services\\*\\ImagePath",
+                  "HKEY_USERS\\*\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell\\*",
+                  "HKEY_USERS\\*\\Environment\\UserInitMprLogonScript",
+                  "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Load",
+                  "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell",
+                  "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\Shell",
+                  "HKEY_USERS\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Logoff\\Script",
+                  "HKEY_USERS\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Logon\\Script",
+                  "HKEY_USERS\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Shutdown\\Script",
+                  "HKEY_USERS\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Startup\\Script",
+                  "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Ctf\\LangBarAddin\\*\\FilePath",
+                  "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Internet Explorer\\Extensions\\*\\Exec",
+                  "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Internet Explorer\\Extensions\\*\\Script",
+                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Command Processor\\Autorun",
+                  "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*",
+                  "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*",
+                  "\\REGISTRY\\MACHINE\\Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Run\\*",
+                  "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*",
+                  "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*",
+                  "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\*",
+                  "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\*",
+                  "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\*",
+                  "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\*",
+                  "\\REGISTRY\\MACHINE\\SYSTEM\\*ControlSet*\\Services\\*\\ServiceDLL",
+                  "\\REGISTRY\\MACHINE\\SYSTEM\\*ControlSet*\\Services\\*\\ImagePath",
+                  "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell\\*",
+                  "\\REGISTRY\\USER\\*\\Environment\\UserInitMprLogonScript",
+                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Load",
+                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell",
+                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\Shell",
+                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Logoff\\Script",
+                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Logon\\Script",
+                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Shutdown\\Script",
+                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Startup\\Script",
+                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Ctf\\LangBarAddin\\*\\FilePath",
+                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Internet Explorer\\Extensions\\*\\Exec",
+                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Internet Explorer\\Extensions\\*\\Script"
+                  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Create or Modify System Process
+** ID: T1543
+** Reference URL: https://attack.mitre.org/techniques/T1543/
+* Sub-technique:
+** Name: Windows Service
+** ID: T1543.003
+** Reference URL: https://attack.mitre.org/techniques/T1543/003/
+* Technique:
+** Name: Boot or Logon Autostart Execution
+** ID: T1547
+** Reference URL: https://attack.mitre.org/techniques/T1547/
+* Sub-technique:
+** Name: Registry Run Keys / Startup Folder
+** ID: T1547.001
+** Reference URL: https://attack.mitre.org/techniques/T1547/001/
+* Sub-technique:
+** Name: Winlogon Helper DLL
+** ID: T1547.004
+** Reference URL: https://attack.mitre.org/techniques/T1547/004/
+* 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-possible-fin7-dga-command-and-control-behavior.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-possible-fin7-dga-command-and-control-behavior.asciidoc
new file mode 100644
index 0000000000..6423b27d63
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-possible-fin7-dga-command-and-control-behavior.asciidoc
@@ -0,0 +1,88 @@
+[[prebuilt-rule-8-19-24-possible-fin7-dga-command-and-control-behavior]]
+=== Possible FIN7 DGA Command and Control Behavior
+
+This rule detects a known command and control pattern in network events. The FIN7 threat group is known to use this command and control technique, while maintaining persistence in their target's network.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* packetbeat-*
+* auditbeat-*
+* filebeat-*
+* logs-network_traffic.*
+* logs-panw.panos*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.fireeye.com/blog/threat-research/2018/08/fin7-pursuing-an-enigmatic-and-evasive-global-criminal-operation.html
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Tactic: Command and Control
+* Domain: Endpoint
+* Data Source: PAN-OS
+* Resources: Investigation Guide
+
+*Version*: 110
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+In the event this rule identifies benign domains in your environment, the `destination.domain` field in the rule can be modified to include those domains. Example: `...AND NOT destination.domain:(zoom.us OR benign.domain1 OR benign.domain2)`.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+(data_stream.dataset: (network_traffic.tls OR network_traffic.http) OR
+    (event.category: (network OR network_traffic) AND network.protocol: (tls OR http) AND network.transport: tcp)) AND
+destination.domain:/[a-zA-Z]{4,5}\.(pw|us|club|info|site|top)/ AND NOT destination.domain:zoom.us
+
+----------------------------------
+
+*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: 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-command-shell-via-netcat.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-command-shell-via-netcat.asciidoc
new file mode 100644
index 0000000000..87dd505a54
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-command-shell-via-netcat.asciidoc
@@ -0,0 +1,156 @@
+[[prebuilt-rule-8-19-24-potential-command-shell-via-netcat]]
+=== Potential Command Shell via NetCat
+
+Identifies potential attempt to execute via a reverse shell using the netcat utility to execute Windows commands using the default interpreters like Cmd.exe and Powershell.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Execution
+* Resources: Investigation Guide
+* Data Source: Elastic Defend
+
+*Version*: 3
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Command Shell via NetCat*
+
+
+
+*Possible investigation steps*
+
+
+- Which remote-shell mode does the alert-local process evidence show?
+  - Focus: `process.parent.command_line`, `process.parent.args_count`, and `process.name`.
+  - Implication: escalate when "-e" wires "cmd.exe" or "powershell.exe" to an explicit IP, unusual port, or "-l"/"-p" listener; lower concern only when shell mode, port or destination, and child shell match a known lab, red-team, or break-glass workflow.
+
+- Does the parent binary identity fit a recognized NetCat-family tool instead of a renamed payload?
+  - Focus: `process.parent.executable`, `process.parent.name`, and code signature.
+  - Implication: escalate when the parent is unsigned, renamed, or runs from temp, downloads, archives, shares, or another user-writable path; identity lowers concern only when path and signer fit the same controlled tool, and never clears the `-e` shell behavior by itself.
+
+- Do recovered parent network events confirm a connect-back destination or exposed listener?
+  - Focus: network events on `host.id` for `process.parent.entity_id`; separate DNS `dns.question.name` from `destination.ip`, `destination.port`, and `network.direction`. !{investigate{"description":"","label":"Network events for the netcat parent process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: network fields come from endpoint network events, not the process alert; compare any command-line IP or port with recovered connections.
+  - Implication: escalate when recovered connections confirm a public or unexpected destination, or a listener is exposed on an unexpected asset; missing network telemetry is unresolved, not benign.
+
+- Did the spawned shell launch operator commands after start?
+  - Focus: child process starts where `process.parent.entity_id` matches the spawned shell `process.entity_id`; review `process.name`, `process.executable`, and `process.command_line`. !{investigate{"description":"","label":"Descendant processes from the spawned shell","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 descendants show reconnaissance, credential, download, persistence, staging, lateral movement, or cleanup; no descendants weakens operator-control evidence but does not make the remote-shell pattern benign.
+
+- Does the user and host context support the shell exposure?
+  - Focus: `user.id`, `user.name`, `host.id`, `host.name`, and `process.parent.command_line`.
+  - Implication: escalate when user-host pairing or account identity conflicts with expected testing or emergency use; lower concern only when the same user, host, and parent command fit one bounded authorized activity.
+
+- If local evidence is suspicious or unresolved, do surrounding alerts expand the scope?
+  - Focus: alerts for the same `user.id`, especially execution, defense-evasion, persistence, credential-access, lateral-movement, or command-and-control tied to the same parent command or recovered destination. !{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: also check the same `host.id` to decide whether this remains one process on one asset or part of a broader compromise. !{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 response scope when surrounding alerts share the user, host, parent command, or recovered destination pattern; keep triage local when no corroborating alerts appear after the parent, network, and descendant checks.
+
+- What disposition is supported by shell mode, parent identity, descendant commands, network recovery, user-host context, and alert scope?
+  - Focus: synthesize shell mode, parent identity, descendants, network recovery, user-host context, and alert scope.
+  - Implication: escalate on alert-local "-e" behavior plus any corroborator: unrecognized parent, external or exposed network evidence, operator descendants, user-host conflict, or related alerts. Close only when all categories bind to one authorized security-testing or break-glass activity with no contradictions; if telemetry cannot prove legitimacy, require outside confirmation. Preserve artifacts and escalate when evidence is mixed or visibility is incomplete.
+
+
+*False positive analysis*
+
+
+- NetCat "-e" shells are an operational anti-pattern outside confirmed security testing or break-glass support. Confirm benign use only when parent path and signer, exact parent command, shell mode, child shell, recovered destination or listen-port evidence, `user.id`, and `host.id` all align to the same bounded workflow. Use schedules, tickets, or owner confirmation only to corroborate that telemetry-matched activity; without them, require telemetry-only confirmation that the same user, host, parent command, and destination or port pattern recur for this rule. Any mismatch keeps the alert suspicious.
+- Before creating an exception, validate stability across prior alerts for the same `user.id` and `host.id`. Anchor the exception on `process.parent.executable`, `process.parent.command_line`, child `process.command_line`, user/host scope, and recovered destination or listen-port pattern. Avoid exceptions on `process.name`, parent basename, or shell name alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse any temporary containment and document the parent identity, exact command, shell mode, child shell, user/host scope, and recovered destination or listen-port evidence that proved the workflow. Create an exception only if that same workflow is stable across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve volatile state and case exports first: parent and child process entity IDs, command lines, descendant commands, parent binary path and signer, and recovered network indicators. Apply reversible containment tied to the findings, such as temporary destination blocks, firewall control of the exposed listener, or host isolation when interactive control or broader scope is likely and the host can tolerate it. Avoid process termination or deletion until evidence capture is complete.
+- If confirmed malicious, first record `process.parent.entity_id`, `process.entity_id`, parent and child command lines, descendant commands, and recovered network indicators. Then isolate the host as appropriate, block recovered destination, domain, IP, or port indicators, and terminate the NetCat parent, spawned shell, and malicious descendants after evidence capture. Reset credentials only when descendant commands, user-host context, or related alerts show credential or administrator-command exposure.
+- Eradicate only artifacts found during the investigation: the NetCat binary or script wrapper, staged payloads, persistence, service or listener configuration, tunnels, and cleanup scripts. Then remediate the delivery path that placed the tool on the host.
+- Post-incident hardening: restrict unauthorized NetCat-family binaries and "-e" shell usage, retain process and network telemetry, and document adjacent variants such as renamed utilities, relay mode without "-e", or delayed shell handoff in the case record for future response.
+
+
+==== 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]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+process.name : ("cmd.exe", "powershell.exe") and process.parent.args : "-e" and
+ (
+  (process.parent.args_count == 5 and process.parent.command_line regex~ """.*[0-9]{1,3}(\.[0-9]{1,3}){3}.*""") or
+  (process.parent.args : "-*l*" and process.parent.args : "-*p*" and process.parent.args : ("cmd.exe", "powershell.exe"))
+  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
+* Sub-technique:
+** Name: Windows Command Shell
+** ID: T1059.003
+** Reference URL: https://attack.mitre.org/techniques/T1059/003/
+* Tactic:
+** Name: Command and Control
+** ID: TA0011
+** Reference URL: https://attack.mitre.org/tactics/TA0011/
+* Technique:
+** Name: Non-Application Layer Protocol
+** ID: T1095
+** Reference URL: https://attack.mitre.org/techniques/T1095/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc
new file mode 100644
index 0000000000..155f1f3473
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc
@@ -0,0 +1,186 @@
+[[prebuilt-rule-8-19-24-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940]]
+=== Potential cPanel WHM CRLF Authentication Bypass (CVE-2026-41940)
+
+Identifies the network signature of CVE-2026-41940, a pre-auth root-level authentication bypass in cPanel and WebHost Manager (WHM) caused by a CRLF injection in the session writer. The exploit-inherent shape on the wire is a `GET /` request to a cPanel/WHM admin port (typically TCP/2087, 2086, 2083, 2082, 2095, 2096) carrying an `Authorization: Basic` header whose base64-decoded value contains CRLF-injected session fields, which causes cpsrvd to respond with a 3xx redirect whose `Location` header leaks a `/cpsessNNNNNNNNNN` token granting the attacker a privileged session. This is the network-layer equivalent of the cPanel `access_log` artifact identified by Unfold and watchTowr as the first bulletproof detection for this CVE: a `GET /` recorded with `auth_method=b` (HTTP Basic). Legitimate access to `GET /` on a WHM admin port returns 200 with the login screen and never includes HTTP Basic credentials, so this combination is not produced by normal use.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* packetbeat-*
+* logs-network_traffic.http*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.unfold.ai/blog/cpanel-exploit-cve-2026-41940
+* https://labs.watchtowr.com/the-internet-is-falling-down-falling-down-falling-down-cpanel-whm-authentication-bypass-cve-2026-41940/
+* https://www.picussecurity.com/resource/blog/cve-2026-41940-explained-cpanel-whm-authentication-bypass-hit-1-5m-servers
+* https://support.cpanel.net/hc/en-us/articles/40073787579671-Security-CVE-2026-41940-cPanel-WHM-WP2-Security-Update-04-28-2026
+* https://nvd.nist.gov/vuln/detail/CVE-2026-41940
+* https://docs.cpanel.net/knowledge-base/cpanel-product/the-cpanel-log-files
+* https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-http-options.html#_send_all_headers
+
+*Tags*: 
+
+* Domain: Network
+* Domain: Application
+* Domain: Web
+* Use Case: Threat Detection
+* Use Case: Vulnerability
+* Tactic: Initial Access
+* Data Source: Network Packet Capture
+* Data Source: Network Traffic
+* 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 cPanel WHM CRLF Authentication Bypass (CVE-2026-41940)*
+
+
+CVE-2026-41940 is a critical (CVSS 9.8) authentication bypass in cPanel & WHM that gives an unauthenticated attacker
+a root-privileged session on the host. The exploit chains a CRLF injection in the session writer with an
+encryption-skip triggered by a malformed cookie, then uses how cPanel caches sessions to promote the injected data
+into a privileged login. Around 1.5M cPanel instances were exposed at disclosure and exploitation has been observed in
+the wild since 2026-02-23, two months before the patch.
+
+This rule fires on the Stage 2 request/response shape: a `GET /` to a cPanel admin port that carries an
+`Authorization: Basic` header and receives a 3xx redirect whose `Location` points at a freshly minted
+`/cpsessNNNNNNNNNN` path. Per the watchTowr and Unfold writeups, this is the only request shape that lets the
+exploit retrieve the security token needed for Stage 4 (privileged use of the session).
+
+
+*Detection logic*
+
+
+The rule requires all of the following on a single decoded HTTP transaction matched from
+`data_stream.dataset:network_traffic.http` (or `event.category:network_traffic` with `network.protocol:http`):
+
+- `http.request.method:GET` and `url.path:"/"` — request targets the root path exactly. The CRLF vulnerability is only
+  reachable on `GET /`; the same payload on other paths does not return the redirect that leaks the token, so the
+  match is intentionally exact (a request like `GET /index.html` will not fire).
+- `destination.port:(2087 OR 2086 OR 2083 OR 2082 OR 2095 OR 2096)` — cPanel/WHM admin and webmail ports. These are
+  not in the default Network Packet Capture HTTP port list and must be added explicitly (see Setup).
+- `http.response.status_code:[300 TO 399]` — a redirect response. Normal `GET /` to WHM returns 200 with the login
+  screen; only the exploit produces a 3xx here.
+- `http.request.headers.authorization:Basic*` — HTTP Basic credentials sent on `GET /`. This is the network-layer
+  equivalent of the `auth_method=b` flag the Unfold and watchTowr writeups identify as the first bulletproof artifact
+  in cPanel's `access_log`. `GET /` is an unauthenticated endpoint in normal cPanel operation and never legitimately
+  carries Basic auth.
+- `http.response.headers.location:/cpsess*` — the response redirects to a `/cpsess`-prefixed path, leaking the CSRF
+  token the attacker needs for Stage 4. This is what makes the exploit succeed and is not produced by any benign flow.
+
+
+*Possible investigation steps*
+
+
+- Capture the alert evidence. Record `source.ip` (attacker), `destination.ip` (cPanel host), `destination.port`,
+  `user_agent.original`, `http.response.status_code`, the exact `http.response.headers.location` value (which contains
+  the leaked `cpsess` token), and the captured `http.request.headers.authorization` value.
+- Decode the Authorization header to confirm the CRLF payload. Strip the leading `Basic ` from
+  `http.request.headers.authorization` and base64-decode the remainder. A legitimate Basic credential decodes to
+  `username:password`; the exploit's payload decodes to a multi-line block delimited by `\r\n` containing fields like
+  `successful_internal_auth_with_timestamp=`, `tfa_verified=1`, and `hasroot=1`. CRLF bytes in the decoded value
+  distinguish exploitation from a misconfigured Basic-auth client.
+- Confirm the destination host runs cPanel/WHM. Identify the installed version and whether the 2026-04-28 emergency
+  patch is applied.
+- Pivot on the source IP across the host's `/usr/local/cpanel/logs/access_log`. The exploit-inherent log artifact is a
+  request line of the form `"GET / HTTP/1.1" 3xx 0 "-" "<UA>" "b" "-" <port>` — `auth_method=b` on `GET /` should never
+  occur in normal operation and corresponds 1:1 to the `http.request.headers.authorization:Basic*` clause in this rule.
+- Look for the Stage 4 follow-on from the same source IP: a request to the leaked `cpsess` path
+  (`/cpsessNNNNNNNNNN/...`) with `auth_method=s` (session) and HTTP 200, without a preceding successful login
+  (form POST `/login`, `/openid_connect/`, or reseller `?session=`). This is the post-exploitation artifact.
+- Identify whether privileged WHM API actions were invoked under the leaked `cpsess` token (account creation, package
+  install, file manager writes, terminal API).
+- Review egress from the host for outbound connections initiated after the alert that could indicate web shell or
+  implant install.
+
+
+*False positive analysis*
+
+
+- Legitimate WHM administration never produces `GET /` with HTTP Basic authentication and a 3xx redirect leaking a
+  fresh `cpsess` token. This combination is exploit-inherent.
+- Authorized vulnerability scans running CVE-2026-41940 plugins will reproduce the request shape.
+
+
+*Response and remediation*
+
+
+- Apply the cPanel emergency patch released 2026-04-28 (or the WP Squared equivalent). Verify by checking the
+  installed cPanel version against the advisory.
+- If the alert is paired with an `auth_method=s` `cpsess` request (post-exploitation), assume host compromise:
+  rotate root credentials, audit `/var/cpanel/sessions/`, look for newly created accounts, scheduled tasks, SSH keys,
+  and `authorized_keys` modifications.
+- Restrict access to cPanel admin ports (2087/2086/2083/2082/2095/2096) to known administrator source IPs at the
+  perimeter or via host firewall.
+- Block the source IP at the WAF or perimeter if exploitation is confirmed.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires HTTP traffic decoded by the Network Packet Capture integration (or legacy Packetbeat) with cPanel
+admin ports added to the HTTP protocol configuration and `send_all_headers` enabled, so that
+`http.request.headers.authorization` and `http.response.headers.location` are populated. cPanel admin ports
+(2087/2086/2083/2082/2095/2096) are not in the default HTTP port list and must be added explicitly. Because cPanel
+admin traffic is normally TLS, the sensor needs decryption visibility (TLS interception, sidecar on the host, or
+sensor on the management network upstream of TLS termination) for this rule to observe HTTP fields.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+(data_stream.dataset:network_traffic.http OR (event.category:network_traffic AND network.protocol:http)) AND
+http.request.method:GET AND
+url.path:"/" AND
+destination.port:(2087 OR 2086 OR 2083 OR 2082 OR 2095 OR 2096) AND
+http.response.status_code>=300 and http.response.status_code < 400 AND
+http.request.headers.authorization:Basic* AND
+http.response.headers.location:/cpsess*
+
+----------------------------------
+
+*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-24/prebuilt-rule-8-19-24-potential-cve-2025-33053-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-cve-2025-33053-exploitation.asciidoc
new file mode 100644
index 0000000000..7578a279a1
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-cve-2025-33053-exploitation.asciidoc
@@ -0,0 +1,197 @@
+[[prebuilt-rule-8-19-24-potential-cve-2025-33053-exploitation]]
+=== Potential CVE-2025-33053 Exploitation
+
+Identifies Internet Explorer Diagnostics launching a helper name from a non-System32 path, which may indicate CVE-2025-33053 exploitation.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process-*
+* winlogbeat-*
+* logs-windows.sysmon_operational-*
+* endgame-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://research.checkpoint.com/2025/stealth-falcon-zero-day/
+* https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2025-33053
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Initial Access
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Microsoft Defender XDR
+* Data Source: SentinelOne
+* Resources: Investigation Guide
+
+*Version*: 4
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential CVE-2025-33053 Exploitation*
+
+
+
+*Possible investigation steps*
+
+
+- Does the alert show "iediagcmd.exe" launching a non-system helper?
+  - Focus: `process.parent.executable`, `process.name`, `process.executable`, and `process.command_line`; check for WebDAV, UNC, temp, downloads, archive-extracted, or user-writable helper paths.
+  - Implication: escalate when the helper name matches a diagnostics utility but `process.executable` is outside "C:\Windows\System32\" or points to remote/user-writable content; lower suspicion only when the path is a controlled diagnostic harness bounded to this `host.id` and `user.id`.
+- Does child identity fit the claimed system utility?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the child is unsigned, newly seen, remotely hosted, user-writable, or PE metadata mismatches the helper name; a trusted signer/familiar name confirms identity only, not benign "iediagcmd.exe" use.
+- Does parent/session context fit user-triggered execution?
+  - Focus: `process.parent.command_line`, `process.Ext.session_info.logon_type`, and `user.id`.
+  - Hint: inspect `process.Ext.ancestry` only when direct parent/child context is incomplete.
+  - Implication: escalate when the parent command line/ancestry points to a shortcut, archive, browser, mail client, or document-open path in an interactive user session; lower suspicion when parent/session evidence stays inside a controlled diagnostic or authorized test launch path.
+- If file telemetry is available, did the lure or child stage follow-on artifacts?
+  - Focus: recover file events with `host.id` + `process.entity_id`; if absent, use `host.id` + `process.pid` in the alert window. Review `file.name`, `file.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier` for ".url" lures, archive extraction, decoy PDFs, copied helpers, DLLs, or payloads. !{investigate{"description":"","label":"File events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if the child writes a file, check later starts where `process.executable` equals `file.path`.
+  - Implication: escalate on internet provenance, WebDAV/UNC lure paths, decoys, copied utilities, DLLs, or written artifacts later executed; missing file telemetry is unresolved, not benign.
+- If DNS/connection telemetry is available, did the child contact a remote share or callback?
+  - Focus: recover network events with `host.id` + `process.entity_id`; if absent, use `host.id` + `process.pid` in the alert window. Separate DNS `dns.question.name`/`dns.resolved_ip` from connection `destination.ip`/`destination.port`. !{investigate{"description":"","label":"Network events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: map "lookup_result" `dns.question.name` to `dns.resolved_ip`, then compare with `destination.ip` and any remote host from the helper path or lure.
+  - Implication: escalate when the child reaches a remote-share host, rare public destination, or later C2-like infrastructure unrelated to diagnostics; missing DNS/connection telemetry is unresolved, not benign.
+- Do descendants or siblings show cleanup, decoy opening, or payload execution?
+  - Focus: later process starts on the same `host.id`, using direct `process.parent.entity_id` links first; review `process.executable`, `process.command_line`, `process.Ext.created_suspended`, and signer context. !{investigate{"description":"","label":"Child process starts from the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: use PID matching only in a tight alert-time window, and inspect `process.Ext.ancestry` only when direct lineage is incomplete.
+  - Implication: escalate when the chain launches "taskkill.exe", opens a decoy through "cmd.exe", starts a browser from an abnormal path, creates a suspended process, or runs unsigned follow-on payloads; keep host-local only when no follow-on evidence contradicts a bounded diagnostic or test path.
+- If local evidence is suspicious or incomplete, do related alerts show broader delivery or post-exploitation?
+  - Focus: review same-`user.id` alerts over 48 hours for the same lure, proxy-execution, payload, or C2 pattern. !{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 user scope is sparse or shared, compare same-`host.id` alerts for the same ".url", WebDAV, child hash, or payload pattern. !{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 response scope when related alerts show the same lure, remote working directory, payload, or post-exploitation pattern; keep response host-local only when related alerts are absent and local telemetry fully explains one recognized workflow.
+- What disposition do helper-path, identity, launch, artifact, network, descendant, and related-alert findings support?
+  - Implication: escalate on remote working-directory abuse, lure delivery, payload staging, suspicious destinations, cleanup, or broader compromise; close only when process, artifact, network, descendant, and alert-scope evidence bind one recognized diagnostic or authorized test workflow; preserve and escalate on incomplete or mixed visibility.
+
+
+*False positive analysis*
+
+
+- Routine diagnostics resolve helpers from "C:\Windows\System32\". Treat helper execution from WebDAV, UNC, temp, downloads, or archive paths as an operational anti-pattern unless telemetry proves a controlled harness or authorized exploit test: child identity (`process.executable`, `process.hash.sha256`, signer, `process.command_line`), parent launch context, `user.id`, `host.id`, and ".url", file-provenance, DNS, or destination evidence stay inside the same bounded workflow; use testing records only to corroborate telemetry.
+- Before exceptions, validate the minimum recurring pattern: child path or hash, signer, command line, `process.parent.executable`, `user.id`, `host.id`, and bounded lure or destination pattern. Avoid exceptions on "iediagcmd.exe", `process.name`, helper basename, or `host.id` alone because those fields also match malicious working-directory hijack chains.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse containment and document the exact child path/hash, command line, parent launch context, `user.id`, `host.id`, and lure or destination evidence proving the diagnostic or testing workflow. Create an exception only for that recurring bounded pattern.
+- If suspicious but unconfirmed, preserve a case export of the alert, parent/child process details, suspicious helper binary, ".url" or archive artifacts, file-provenance records, DNS/connection records, and descendant process evidence before containment. Apply reversible containment first: block the confirmed WebDAV or callback destination, remove remote-share access, or raise monitoring on `host.id`; isolate only when artifact, network, or descendant evidence shows active compromise and the host role can tolerate disruption.
+- If confirmed malicious, isolate the host or terminate the malicious child and confirmed descendants only after recording process entity IDs, command lines, hashes, lure paths, destination indicators, and related alert identifiers. If endpoint response is unavailable, hand off preserved evidence to contain the endpoint or block remote infrastructure.
+- Before deleting artifacts, scope other users and hosts for the same ".url" filename pattern, WebDAV/UNC host, child hash, command line, decoy path, and payload path. Remove only lure files, dropped helpers, DLLs, decoys, archives, and payloads found during the investigation, then restore modified execution paths that supported the hijack chain.
+- After containment, apply the June 2025 Windows security updates for CVE-2025-33053 where missing, restrict untrusted Internet Shortcut content and remote-working-directory execution paths, retain process/file/network telemetry, and document variants such as helper names or WebDAV paths for detection engineering review.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+  process.parent.executable : "C:\\Program Files\\Internet Explorer\\iediagcmd.exe" and
+  process.name : ("route.exe", "netsh.exe", "ipconfig.exe", "dxdiag.exe", "conhost.exe", "makecab.exe") and
+  process.executable != null and
+  not process.executable : ("C:\\Windows\\System32\\route.exe",
+                            "C:\\Windows\\System32\\netsh.exe",
+                            "C:\\Windows\\System32\\ipconfig.exe",
+                            "C:\\Windows\\System32\\dxdiag.exe",
+                            "C:\\Windows\\System32\\conhost.exe",
+                            "C:\\Windows\\System32\\makecab.exe")
+
+----------------------------------
+
+*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: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Masquerading
+** ID: T1036
+** Reference URL: https://attack.mitre.org/techniques/T1036/
+* Sub-technique:
+** Name: Match Legitimate Resource Name or Location
+** ID: T1036.005
+** Reference URL: https://attack.mitre.org/techniques/T1036/005/
+* Technique:
+** Name: System Binary Proxy Execution
+** ID: T1218
+** Reference URL: https://attack.mitre.org/techniques/T1218/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Exploitation for Client Execution
+** ID: T1203
+** Reference URL: https://attack.mitre.org/techniques/T1203/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-direct-kubelet-access-via-process-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-direct-kubelet-access-via-process-arguments.asciidoc
new file mode 100644
index 0000000000..c108f32b26
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-direct-kubelet-access-via-process-arguments.asciidoc
@@ -0,0 +1,147 @@
+[[prebuilt-rule-8-19-24-potential-direct-kubelet-access-via-process-arguments]]
+=== Potential Direct Kubelet Access via Process Arguments
+
+Detects potential direct Kubelet API access attempts on Linux by identifying process executions whose arguments contain URLs targeting Kubelet ports (10250/10255). Adversaries may probe or access Kubelet endpoints to enumerate pods, fetch logs, or attempt remote execution, which can enable discovery and lateral movement in Kubernetes environments.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* auditbeat-*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#kubelet-api
+* https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster
+* https://www.aquasec.com/blog/kubernetes-exposed-exploiting-the-kubelet-api/
+
+*Tags*: 
+
+* Domain: Endpoint
+* Domain: Container
+* Domain: Kubernetes
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Discovery
+* Tactic: Lateral Movement
+* Data Source: Elastic Defend
+* 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 Potential Direct Kubelet Access via Process Arguments*
+
+
+This detection flags a process on a Linux host whose arguments include a URL targeting the Kubelet API ports 10250/10255.
+Attackers often use `curl`, `wget`, or scripting runtimes to access endpoints such as `/pods`, `/runningpods`,
+`/metrics`, `/exec`, or `/containerLogs`. Successful access can provide node and workload visibility, and in some cases
+enable actions that facilitate lateral movement within the cluster.
+
+
+*Possible investigation steps*
+
+
+- Extract and reconstruct the full URL from `process.args` / `process.command_line`, including the hostname/IP, port, and
+  path, and determine whether the request intent was discovery or execution.
+- Identify the user and session that launched the process and whether it originated from an interactive shell, scheduled
+  task, or automation.
+- Correlate the timestamp with Kubernetes audit logs and node/Kubelet logs to confirm whether the request was
+  authenticated and whether it returned success.
+- If the destination is a node IP, check whether this host should be allowed to reach node Kubelet ports and whether
+  other nodes were contacted in a scanning pattern.
+
+
+*False positive analysis*
+
+
+- SRE/operator troubleshooting sessions validating Kubelet reachability or TLS/auth behavior.
+- Approved health checks, debugging scripts, or node agents that query Kubelet endpoints.
+
+
+*Response and remediation*
+
+
+- Restrict access to Kubelet ports 10250/10255 at the network layer; block pod-to-node or host-to-node traffic except for
+  approved agents.
+- Rotate any potentially exposed credentials (service account tokens, client certs, kubeconfigs) and assess for follow-on
+  activity such as `exec/attach` and secret reads.
+- Harden Kubelet configuration (disable anonymous auth, enforce webhook authn/authz) and review RBAC/admission controls.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "executed") and
+(
+  /* direct utility execution */
+  process.name like ("curl", "wget", "python*", "perl*", "php*", "node*", "java", "ruby*", "lua*", ".*") or
+  
+  process.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/var/run/*", "/home/*", "/run/user/*", "/busybox/*")
+) and
+process.args like ("http*:10250/*", "http*:10255/*", "wss:*:10250/*", "wss:*:10255/*")
+
+----------------------------------
+
+*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/
+* 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/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: Unix Shell
+** ID: T1059.004
+** Reference URL: https://attack.mitre.org/techniques/T1059/004/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-escalation-via-vulnerable-msi-repair.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-escalation-via-vulnerable-msi-repair.asciidoc
new file mode 100644
index 0000000000..59a77a3382
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-escalation-via-vulnerable-msi-repair.asciidoc
@@ -0,0 +1,170 @@
+[[prebuilt-rule-8-19-24-potential-escalation-via-vulnerable-msi-repair]]
+=== Potential Escalation via Vulnerable MSI Repair
+
+Identifies when a browser process navigates to the Microsoft Help page followed by spawning an elevated process. This may indicate a successful exploitation for privilege escalation abusing a vulnerable Windows Installer repair setup.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* winlogbeat-*
+* endgame-*
+* logs-endpoint.events.process-*
+* logs-windows.sysmon_operational-*
+* 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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://sec-consult.com/blog/detail/msi-installer-repair-to-system-a-detailed-journey/
+* https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2024-38014
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Data Source: Microsoft Defender XDR
+* Resources: Investigation Guide
+
+*Version*: 207
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Escalation via Vulnerable MSI Repair*
+
+
+*Possible investigation steps*
+
+
+- What did the elevated browser parent launch?
+  - Why: MSI repair abuse can expose a SYSTEM browser through a help-link redirect; a non-browser child marks the privilege-escalation boundary.
+  - Focus: `process.parent.command_line`, `process.name`, `process.executable`, `process.command_line`, and `process.Ext.token.integrity_level_name`.
+  - Implication: escalate when a Microsoft Help-tied browser launches a SYSTEM or high-integrity shell, script host, installer, admin utility, file manager, or user-writable binary; lower concern only when the command line shows a browser-internal role, path and signer match the parent browser family, and no non-browser child appears in the alert window.
+- Does the lineage fit an MSI repair-to-help-link path?
+  - Focus: `process.parent.entity_id`, `process.parent.pid`, surrounding `process.name`, and `process.command_line`.
+  - Implication: escalate when ancestry or surrounding starts show MSI repair, installer custom actions, console activity, or an unexpected SYSTEM browser before the child; lower concern when the chain stays inside browser self-maintenance without repair, console, or custom-action ancestry.
+  - Hint: recover the parent browser event first. If parentage is incomplete, inspect `process.Ext.ancestry`; if entity IDs are absent, use `host.id`, `process.parent.pid`, and a tight alert window. !{investigate{"description":"","label":"SYSTEM browser parent process event","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+- Is the child process identity expected for the host and signer?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.Ext.relative_file_creation_time`.
+  - Implication: escalate when the child runs from a user-writable or temporary path, has a mismatched original file name, lacks a trusted signer, or was recently created; lower concern only when signer, path, age, and browser parent context all fit the same recognized component.
+- What follow-on process activity came from the same SYSTEM browser or spawned child?
+  - Focus: same-host starts from the browser `process.parent.entity_id` or child `process.entity_id`: `process.name`, `process.command_line`, and `process.Ext.token.integrity_level_name`.
+  - Implication: escalate when the browser or child launches shells, scripts, persistence or administration tools, additional installers, or chained SYSTEM processes; keep scope local when activity stops at browser helpers with no privileged child chain.
+  - Hint: prefer `host.id` plus parent or child `process.entity_id`; use `host.id`, `process.pid`, and a tight window only when entity IDs are absent.
+    - !{investigate{"description":"","label":"Process starts from the SYSTEM browser parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","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.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Process starts from the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}}
+- Does the user and session context support interactive exploitation?
+  - Focus: `user.id`, `user.name`, `user.domain`, `process.Ext.authentication_id`, and `process.Ext.session_info.logon_type`.
+  - Implication: escalate when a low-privileged or unexpected interactive session is tied to the SYSTEM browser-to-child chain; a pre-existing user browser usually breaks the SYSTEM child path, so a SYSTEM or high-integrity child tied to an interactive session is severity-changing. Lower concern only when process evidence maps to controlled repair validation or browser-helper behavior.
+- Does process telemetry show the same SYSTEM-browser-to-tool pattern beyond this process instance?
+  - Focus: same `process.parent.command_line` redirect fragment, suspicious `process.name` or `process.executable`, `user.id`, and `host.id` across recent starts.
+  - Implication: broaden when recent starts show the same non-browser child pattern across unrelated hosts or users; keep response scoped when telemetry shows only this browser parent, child command line, and no repeated non-browser descendants.
+  - Hint: run this pivot only if child intent, lineage, or session context remains suspicious or unresolved. !{investigate{"description":"","label":"Recent process starts with the same child executable","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+- Based on the evidence gathered, what disposition is supported?
+  - Escalate on SYSTEM or high-integrity browser-to-tool execution, MSI repair lineage, suspicious child identity, interactive session linkage, or repeated scope; close only for same-browser helper behavior with no non-browser descendants or an authorized test whose process facts exactly match scope. Preserve evidence and escalate when child intent, lineage, or session context is mixed or incomplete.
+
+
+*False positive analysis*
+
+
+- Browser helper, renderer, GPU, updater, or crash subprocesses can trigger after a SYSTEM browser opens a Microsoft Help link. Confirm a browser-internal role, same browser family, installed-browser path and signer, and no shell, installer, file manager, or admin tool from the same parent.
+- Authorized MSI repair security validation is benign only when `@timestamp`, `host.id`, `user.id`, the SYSTEM browser parent command line, and child command line match the exact exercise; outside records may corroborate but not replace process facts.
+- Build exceptions from the minimum confirmed workflow: browser family and signer, exact redirect parent context, expected child executable or command pattern, `host.id`, and tightly scoped test or managed-repair cohort. Avoid exceptions on `user.domain`, browser name, or redirect URL alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, document the process evidence that proved the browser-helper or validation workflow, reverse any temporary containment, and create only the narrow exception described above if the same workflow recurs.
+- If suspicious but unconfirmed, preserve the alert and Timeline/export records for the browser parent, child, ancestor chain, host, and user. Record command lines, `process.entity_id`, `process.parent.entity_id`, `host.id`, `user.id`, and any visible MSI package or vulnerable-application names before containment or process termination.
+- Apply reversible containment first when findings remain suspicious: isolate the host if its business role allows, or restrict the affected account/session while preserving endpoint telemetry. Do not terminate the child process until its command line, parentage, and spawned descendants are recorded.
+- If confirmed malicious, contain the host and affected account based on the process lineage and session evidence, then terminate the malicious child and descendants after recording their identifiers. Remove only the payloads, repair artifacts, or configuration changes identified during the investigation.
+- Patch Windows Installer and the vulnerable application package involved in the repair path, verify that the affected OS has the relevant vendor security update for CVE-2024-38014, and repackage or disable repair flows that let low-privileged users reach elevated custom actions, console windows, or help-link execution.
+- Document the final evidence set, repair path, affected hosts, and any missing telemetry that limited certainty so future alerts can distinguish browser helper noise, authorized validation, and repeated exploitation.
+
+==== 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 event.type == "start" and host.os.type == "windows" and
+ user.domain : ("NT AUTHORITY", "AUTORITE NT", "AUTORIDADE NT") and
+ process.parent.name : ("chrome.exe", "msedge.exe", "brave.exe", "whale.exe", "browser.exe", "dragon.exe", "vivaldi.exe",
+                        "opera.exe", "iexplore", "firefox.exe", "waterfox.exe", "iexplore.exe", "tor.exe", "safari.exe") and
+ process.parent.command_line : "*go.microsoft.com*"
+
+----------------------------------
+
+*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: 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: Msiexec
+** ID: T1218.007
+** Reference URL: https://attack.mitre.org/techniques/T1218/007/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-execution-via-filefix-phishing-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-execution-via-filefix-phishing-attack.asciidoc
new file mode 100644
index 0000000000..fb737eeee3
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-execution-via-filefix-phishing-attack.asciidoc
@@ -0,0 +1,206 @@
+[[prebuilt-rule-8-19-24-potential-execution-via-filefix-phishing-attack]]
+=== Potential Execution via FileFix Phishing Attack
+
+Identifies the execution of Windows commands or downloaded files via the browser's dialog box. Adversaries may use phishing to instruct the victim to copy and paste malicious commands for execution via crafted phishing web pages.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* 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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://mrd0x.com/filefix-clickfix-alternative/
+
+*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
+* Resources: Investigation Guide
+
+*Version*: 4
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Execution via FileFix Phishing Attack*
+
+
+
+*Possible investigation steps*
+
+
+- Does the alert show the FileFix browser-to-Explorer execution path?
+  - Focus: alert-local `process.parent.executable`, `process.parent.args`, `process.name`, `process.executable`, and `process.command_line`.
+  - Implication: escalate when a Chromium-style file-picker parent using "--message-loop-type-ui" and "--service-sandbox-type=none" launches PowerShell, curl, certutil, certreq, msiexec, mshta, rundll32, wscript, cscript, or a "?:\Users\*\Downloads\*" executable; lower suspicion only when the child is a signed installer or diagnostic tool and the parent/command shape matches a recognized browser-initiated support or install flow.
+- Is the launched child the expected binary for that workflow?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`; recover absent values from same-process events. !{investigate{"description":"","label":"Events for the launched process on this host","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the path is user-writable or signer/original name mismatches the expected tool; lower identity risk when signer, original name, path, and known hash history fit, but continue command-intent checks.
+- Does the command line reveal pasted-command social engineering?
+  - Focus: `process.command_line` and `process.name`.
+  - Implication: escalate when the command hides execution before a fake path or comment, invokes PowerShell or a LOLBin to retrieve/run content, or starts a "%USERPROFILE%\Downloads" payload directly; lower suspicion only when arguments open the signed installer or diagnostic tool with no hidden command, URL, or shell operator.
+- Does a Downloads-path child look newly staged or renamed?
+  - Focus: `process.executable`, `process.Ext.relative_file_creation_time`, `process.Ext.relative_file_name_modify_time`, `process.code_signature.thumbprint_sha256`, and same-process file writes/renames; recover absent process values from same-process events. !{investigate{"description":"","label":"File events for the launched process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: for the downloaded-EXE variant, process file-age is the recovery signal; absent file provenance does not make a Downloads path benign.
+  - Implication: escalate when a Downloads or other user-profile executable runs shortly after creation or rename, especially with weak identity; lower suspicion when file age, stable signer, and path match the same recognized update or support workflow.
+- Did the launched child spawn follow-on tools?
+  - Focus: child process starts from `process.entity_id`, then descendant `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child process starts from the launched process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if entity IDs are unavailable, fall back to parent PID plus a tight alert-time window on the same host.
+  - Implication: escalate when the chain fans out into shells, script hosts, installers, archive tools, or task/scheduler utilities; no descendants keeps scope local but does not clear suspicious command intent or identity mismatch.
+- Did the launched child contact retrieval or staging destinations?
+  - Focus: same-process network events for `destination.ip`, `destination.port`, and destination ownership when available. !{investigate{"description":"","label":"Network events for the launched process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when PowerShell, curl, certutil, certreq, mshta, or another child reaches external staging, paste, storage, or command-and-control infrastructure; missing network telemetry is unresolved, not benign.
+- If local evidence remains suspicious or unresolved, does the pattern recur for this user or host?
+  - Focus: related alerts and process starts for the same `user.id` and `host.id`, comparing `process.parent.args` and child `process.command_line`.
+  - Hint: review related user alerts with !{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: review related host alerts with !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same browser-parented shell, LOLBin, or Downloads-path launch repeats for this user, host, or other users; keep the case local when it is isolated and the process evidence resolves cleanly.
+- Escalate when ancestry, child identity, command intent, file age, descendants, network, or recurrence supports user-assisted command execution or downloaded payload launch; close only when process evidence shows a signed installer or diagnostic identity, non-hidden command shape, expected file age/path, no suspicious descendants, no suspicious network where telemetry exists, and no related spread; preserve evidence and escalate when facts conflict or remain incomplete.
+
+
+*False positive analysis*
+
+
+- Signed browser-initiated installer/diagnostic workflows or authorized security tests can trigger. Confirm exact alignment across parent flags, child path, signer, hash, command line, user, host, timing, and absence of suspicious descendants; do not close on a ticket or owner statement if process evidence conflicts.
+- Before creating an exception, require recurrence with stable `process.parent.executable`, `process.parent.args`, `process.executable`, `process.code_signature.thumbprint_sha256`, command-line shape, `user.id`, and `host.id`. Avoid exceptions on browser parentage, `process.name`, or Downloads-path execution alone.
+
+
+*Response and remediation*
+
+
+- If suspicious but unconfirmed, first preserve the alert event, same-process event export, descendant process timeline, command-line text, parent context, child binary copy, hash and signature details, and the affected user/host identifiers.
+- Apply reversible containment only after preservation, such as restricting the affected browser session or account, blocking the exact child hash, or quarantining the downloaded child binary. Escalate to host isolation only when command intent, identity, or descendants indicate likely payload execution.
+- If confirmed malicious, isolate the host when the launched child or descendants executed payloads, then terminate the child and descendants after recording identifiers. Do not reset credentials from this alert alone; use identity response only when separate evidence proves credential exposure or account misuse.
+- Eradicate only the downloaded executables, scripts, task utilities, or secondary payloads identified in the process timeline, then remediate the phishing page access or browser session that enabled the user-assisted execution.
+- If confirmed benign, reverse temporary containment and document the exact parent flags, child identity, command shape, user, host, and outside confirmation that proved the workflow. Create an exception only after the stable bounded pattern recurs.
+- Post-incident hardening: restrict direct execution from user download locations where feasible, warn on browser-file-picker social engineering, retain process telemetry needed for the pivots above, and document the FileFix variant observed in the case record.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+ process.parent.args == "--message-loop-type-ui" and process.parent.args == "--service-sandbox-type=none" and
+ (
+  process.name : ("pwsh.exe", "powershell.exe", "curl.exe", "msiexec.exe", "mshta.exe", "wscript.exe", "cscript.exe", "rundll32.exe", "certutil.exe", "certreq.exe") or
+  process.executable : "?:\\Users\\*\\Downloads\\*"
+  ) and
+not (process.name : "rundll32.exe" and process.args : ("ndfapi.dll,NdfRunDllDiagnoseWithAnswerFile", "shwebsvc.dll,AddNetPlaceRunDll"))
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
+* Sub-technique:
+** Name: Windows Command Shell
+** ID: T1059.003
+** Reference URL: https://attack.mitre.org/techniques/T1059/003/
+* 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/
+* Sub-technique:
+** Name: Malicious Copy and Paste
+** ID: T1204.004
+** Reference URL: https://attack.mitre.org/techniques/T1204/004/
+* 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: Mshta
+** ID: T1218.005
+** Reference URL: https://attack.mitre.org/techniques/T1218/005/
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Phishing
+** ID: T1566
+** Reference URL: https://attack.mitre.org/techniques/T1566/
+* Sub-technique:
+** Name: Spearphishing 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-fake-captcha-phishing-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-fake-captcha-phishing-attack.asciidoc
new file mode 100644
index 0000000000..b3b89a5341
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-fake-captcha-phishing-attack.asciidoc
@@ -0,0 +1,212 @@
+[[prebuilt-rule-8-19-24-potential-fake-captcha-phishing-attack]]
+=== Potential Fake CAPTCHA Phishing Attack
+
+Identifies potential fake CAPTCHA phishing attacks based on PowerShell, Cmd, or Mshta command-line values. Adversaries employ this technique via compromised websites with browser injects, posing either as fake CAPTCHAs to access the site or as a page loading error requiring a fix to display the page. The victim is instructed to copy and paste a malicious command to the Windows Run dialog box.
+
+*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-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* 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
+* Resources: Investigation Guide
+
+*Version*: 4
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Fake CAPTCHA Phishing Attack*
+
+
+*Possible investigation steps*
+
+
+- What does the pasted command do after the CAPTCHA or verification text?
+  - Why: lure text is the wrapper; payload behavior separates clickfix execution from testing or inert copy text.
+  - Focus: `process.name`, `process.command_line`, `process.parent.name`, and `process.parent.command_line` for URLs, encoded content, inline script, archive handling, or handoff to "mshta.exe", "cmd.exe", or "powershell.exe".
+  - Hint: fake-update or page-fix wording is the same abuse path when the command downloads, decodes, or hands execution to another utility.
+  - Implication: escalate when the command downloads content, rebuilds a payload, invokes another script host, or hides work after CAPTCHA wording; lower suspicion only for a bounded authorized simulation or lab command with no second-stage behavior.
+
+- Is the shell or proxy binary and launch context consistent with paste-and-run clickfix?
+  - Focus: `process.executable`, `process.parent.executable`, `process.parent.command_line`, and `user.id`.
+  - Implication: escalate faster when the binary is renamed, user-writable, or launched from an unusual parent context for the user; a native shell path confirms identity but does not clear suspicious command content.
+
+- Do children from the alerting instance show payload execution or follow-on tooling?
+  - Focus: child starts where `process.parent.entity_id` maps to `process.entity_id`, reviewing child `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child process starts from the same alerting instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `process.entity_id` is absent, recover children with `host.id` + `process.pid` in a tight alert-time window and treat the match as weaker.
+  - Implication: escalate when the same shell or "mshta.exe" starts installers, script hosts, archive tools, credential tooling, or more shells; no children reduce scope only if command intent and artifact/destination evidence also stay bounded.
+
+- If file telemetry is available, did the process stage scripts, HTAs, archives, or payloads?
+  - Focus: process-scoped file events using `host.id` + `process.entity_id`, or `host.id` + `process.pid` as fallback, reviewing `file.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier`. !{investigate{"description":"","label":"File activity for the alerting instance","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"}}
+  - Implication: escalate when artifacts land in temp, downloads, desktop, public, startup, or other user-writable paths, carry internet provenance, or later execute; missing file telemetry is unresolved, not benign.
+
+- If network telemetry is available, did the process retrieve payloads or contact callbacks?
+  - Focus: process-scoped network events using `host.id` + `process.entity_id`, separating DNS `dns.question.name` from connection `destination.ip` / `destination.port`. !{investigate{"description":"","label":"Network activity for the alerting instance","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `process.entity_id` is absent, use `host.id` + `process.pid` and a tight alert-time window. Missing network telemetry is unresolved, not benign.
+  - Implication: escalate when the same process reaches rare public domains, direct IPs, paste/file hosts, or service ports fitting retrieval or callback behavior; lower suspicion only when destinations belong to the same authorized simulation or lab workflow.
+
+- Do surrounding process events explain the lure path into "explorer.exe"?
+  - Focus: same `host.id` and `user.id` process timeline, especially browser, chat, mail, archive, or download-manager starts in `process.name`, `process.parent.executable`, and `process.parent.command_line`. !{investigate{"description":"","label":"Process timeline for the host and user","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when a browser/chat/download chain immediately precedes the paste-run shell or no controlled source explains the lure; lower suspicion when the sequence matches a planned awareness platform or lab harness and the command remains bounded.
+
+- If local findings stay suspicious or unresolved, do related alerts change scope?
+  - Focus: recent alerts for the same `host.id`, then `user.id`, emphasizing reuse of the command fragment, shell/proxy binary, recovered artifact, destination, or persistence chain. !{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"}}
+  - Hint: use the user view after the host view, or when a shared host needs actor scoping for the command or lure pattern. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden response when related alerts show the same lure-driven execution pattern on this host or user; quiet alert history does not close the case without a telemetry-backed benign workflow.
+
+- Escalate on clickfix command intent plus suspicious children, staged artifacts, process-scoped destinations, delivery context, or related alerts; close only when alert-local evidence and recovery bind one authorized simulation or lab workflow with no contradiction; if evidence is mixed or visibility incomplete, preserve evidence and escalate.
+
+
+*False positive analysis*
+
+
+- Security-awareness, phishing-simulation, red-team, malware-analysis, browser-security, and QA labs can intentionally execute fake CAPTCHA samples. Confirm one exact workflow: stable `process.command_line` fragment, expected `process.executable` and `process.parent.name`, bounded `user.id` / `host.id`, and recovered children, artifacts, and destinations that stay inside the exercise or lab set.
+- Without exercise or lab records, close only when telemetry proves the same command fragment, parent context, `user.id`, `host.id`, and recovered evidence stayed bounded across prior alerts from this rule. Do not close when child execution, artifact staging, destination activity, or related alerts contradict the expected workflow.
+- Build exceptions only from the minimum confirmed workflow: command fragment, process identity, parent context, `user.id`, `host.id`, and any recovered artifact or destination pattern. Avoid exceptions on lure text, "explorer.exe", `process.name`, or a user alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and record the command, process identity, parent context, `user.id`, `host.id`, and recovered supporting evidence that proved the authorized simulation or lab workflow. Create an exception only when that exact workflow recurs.
+- If suspicious but unconfirmed, export the alert, process tree, `process.entity_id`, `process.command_line`, child command lines, volatile state, and any recovered artifact paths, domains, IPs, or ports before containment. Apply reversible controls first, such as temporary destination blocks, browser-session reset, heightened monitoring, or endpoint isolation when retrieval, staging, or second-stage execution makes continued connectivity risky.
+- If confirmed malicious, isolate the host when command intent plus child, artifact, or destination evidence establishes compromise. Terminate the malicious shell, "mshta.exe", or follow-on children only after evidence is recorded, then block confirmed domains, IPs, hashes, or URLs and reset credentials only if the investigation shows account misuse.
+- Eradicate only the staged scripts, HTAs, archives, payloads, or persistence artifacts found during the investigation, then remediate the web, chat, mail, or download path that led the user to run the lure.
+- Post-incident hardening: retain process, file, and network telemetry needed for future clickfix triage; review browser protections, clipboard/paste execution controls, and user-awareness coverage; record the confirmed lure wording and paste-run chain in the case notes.
+
+
+==== 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", "cmd.exe", "mshta.exe") and process.parent.name : "explorer.exe" and
+ process.command_line : ("*recaptcha *", "*CAPTCHA Verif*", "*complete verification*", "*Verification ID*", "*Verification Code*", "*Verification UID*",
+                         "*hυmаn vаlіdаtiοn*", "*human ID*", "*Action Identificator*", "*not a robot*", "*Click OK to*", "*anti-robot test*",
+                         "*Cloudflare ID*")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
+* Sub-technique:
+** Name: Windows Command Shell
+** ID: T1059.003
+** Reference URL: https://attack.mitre.org/techniques/T1059/003/
+* Technique:
+** Name: User Execution
+** ID: T1204
+** Reference URL: https://attack.mitre.org/techniques/T1204/
+* Sub-technique:
+** Name: Malicious Copy and Paste
+** ID: T1204.004
+** Reference URL: https://attack.mitre.org/techniques/T1204/004/
+* 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: Mshta
+** ID: T1218.005
+** Reference URL: https://attack.mitre.org/techniques/T1218/005/
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Drive-by Compromise
+** ID: T1189
+** Reference URL: https://attack.mitre.org/techniques/T1189/
+* 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-foxmail-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-foxmail-exploitation.asciidoc
new file mode 100644
index 0000000000..301b69f8b5
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-foxmail-exploitation.asciidoc
@@ -0,0 +1,179 @@
+[[prebuilt-rule-8-19-24-potential-foxmail-exploitation]]
+=== Potential Foxmail Exploitation
+
+Identifies the Foxmail client spawning a child process with arguments pointing to user-profile AppData paths or remote shares. This may indicate exploitation of a Foxmail vulnerability for initial access and execution via a malicious email.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://mp.weixin.qq.com/s/F8hNyESBdKhwXkQPgtGpew
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Initial Access
+* Tactic: Execution
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Windows Security Event Logs
+* Data Source: Elastic Endgame
+* Data Source: SentinelOne
+* Data Source: Microsoft Defender XDR
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 209
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Foxmail Exploitation*
+
+
+
+*Possible investigation steps*
+
+
+- What exact Foxmail child execution did the alert capture?
+  - Why: Foxmail exploit attempts execute code in the user's client context; the child process and path argument distinguish payload execution from routine file handling.
+  - Focus: `process.parent.name`, `process.parent.executable`, child `process.executable`, `process.command_line`, and `process.args`.
+  - Implication: escalate when Foxmail.exe launches a script host, LOLBin, interpreter, archive utility, installer, or payload from a user-writable or remote-share path; lower suspicion only when the child is a recognized signed Foxmail component with the expected path, argument pattern, and no contradictory process evidence.
+
+- Does the Foxmail parent match the installed mail client and user launch context?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.code_signature.subject_name`, and `process.parent.code_signature.trusted`.
+  - Implication: escalate when Foxmail runs from a user-writable or portable path, has an unexpected signer or trust state, or appears under an abnormal launch chain; lower suspicion when parent identity and user context match a recognized installed Foxmail workflow. Parent identity never clears the child behavior by itself.
+
+- What does the child command line say it was trying to execute or open?
+  - Why: the user-writable or remote path string in `process.args` is the rule-specific payload anchor; interpret it before relying on broader pivots.
+  - Focus: `process.executable`, `process.command_line`, `process.args`, and `process.code_signature.subject_name`. !{investigate{"description":"","label":"Events for the Foxmail child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the child runs executable or scriptable content from a user-writable path, mounted archive, or remote share, especially through a LOLBin or interpreter; lower suspicion when signed child, arguments, and path pattern match a locally confirmed Foxmail file-handling action.
+
+- Did the Foxmail child launch descendants that change impact or confirm execution?
+  - Focus: process starts on the same `host.id` where `process.parent.entity_id` matches the child `process.entity_id`, or `process.parent.pid` matches `process.pid` in the alert window; review descendant `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child processes launched by the Foxmail child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: prefer entity match; use PID only inside the alert window.
+  - Implication: escalate when descendants include payload staging, scripting, installers, persistence tooling, or commands unrelated to Foxmail; lower suspicion when there are no descendants and the child command from the prior step already matches a recognized helper workflow.
+
+- What delivery clue is embedded in the user-writable or remote path argument?
+  - Focus: file name, extension, UNC host/share, and directory pattern visible in `process.args`, scoped to `host.name` and `user.id`.
+  - Implication: escalate or broaden when the path suggests executable content, a deceptive attachment-like name, or a remote share that can execute content without local provenance; lower suspicion only as corroboration when the path shape fits a recognized Foxmail file-handling workflow supported by child identity and descendant evidence.
+
+- Does related activity history show the same child/path pattern beyond this process?
+  - Focus: related records for the same `user.id`; compare child `process.executable`, parent-child pair, and distinctive `process.args` fragments. !{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: use same-asset related records to separate one user's repeat workflow from multiple users on one host. !{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 the same child binary, remote share, or path fragment appears on unrelated users or hosts; keep response local when related records are absent and local process evidence already proves one recognized workflow.
+
+- Based on the Foxmail parent, child command, argument path, descendants, and related activity, what disposition is supported?
+  - Escalate for suspicious child intent, unexplained descendants, or the same pattern on multiple users or hosts; close only when process evidence and supported recovery prove one exact recognized Foxmail workflow on this host; preserve and escalate mixed, missing, or contradictory evidence, using outside confirmation only to corroborate details telemetry cannot prove.
+
+
+*False positive analysis*
+
+
+- Signed Foxmail child processes used for update or file handling and authorized internal tests are plausible benign candidates, but the label is not clearance. Confirm parent path/signer, child path/signer, `process.args`, `host.id`, and `user.id` all align with one workflow or exact test file/share, and verify no suspicious descendants; use prior alerts only to tune a durable exception, not to close the single alert by recurrence alone.
+- If test records are unavailable, use the process timeline, path shape, and user/host scope as fallback corroboration; do not close on owner confirmation alone when process evidence remains unexplained.
+- Before creating an exception, require stable anchors such as `process.parent.executable`, `process.executable`, `process.code_signature.subject_name`, the user-writable or remote path pattern in `process.args`, `host.id`, and `user.id`. Avoid exceptions on "Foxmail.exe" alone, temp-path strings alone, or `process.name` alone because exploit chains and benign components can share those surface features.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse any temporary containment and document the recognized Foxmail component, file-handling, or test workflow, including the expected parent-child pair, signer, path pattern, `host.id`, and `user.id`. Create a narrow exception only when those anchors are stable enough to avoid suppressing lookalike exploit chains.
+- If suspicious but unconfirmed, preserve the alert record, parent and child command lines, `process.entity_id`, `process.pid`, `process.args`, referenced user-writable or remote paths, descendant process identifiers, and case records that identify the delivery path before containment. Apply reversible containment such as temporary quarantine of the referenced artifact, temporary outbound restrictions for the affected host when remote retrieval is indicated, or heightened monitoring on the affected `host.id` and `user.id`; escalate to host isolation only if follow-on execution, staging, or wider compromise appears and the host role can tolerate it.
+- If confirmed malicious, isolate the host and terminate the Foxmail child or descendant payloads only after recording the relevant process identifiers, command lines, path strings, and delivery-path evidence; if direct endpoint response is unavailable, escalate with those preserved artifacts to the team that can act. Quarantine the referenced attachment or payload, block confirmed malicious indicators, and review other recipients, hosts, and users for the same attachment, remote path, or child-process pattern before deleting evidence or resetting accounts.
+- Eradicate only the payloads, persistence mechanisms, or configuration changes identified in the same chain after scoping affected recipients and hosts. Remediate the message source, attachment workflow, or remote share that led to the Foxmail launch.
+- Post-incident hardening: update Foxmail to a current vendor-fixed release, retain endpoint process telemetry and any mail or artifact telemetry used in this case, and document adjacent exploit-chain findings for the detection engineering team.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/crowdstrike-integration[CrowdStrike]
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+- https://ela.st/audit-process-creation[Windows Process Creation Logs]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+ process.parent.name : "Foxmail.exe" and process.args : ("?:\\Users\\*\\AppData\\*", "\\\\*")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Exploitation for Client Execution
+** ID: T1203
+** Reference URL: https://attack.mitre.org/techniques/T1203/
+* 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-kubeletctl-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-kubeletctl-execution.asciidoc
new file mode 100644
index 0000000000..73cc1ce101
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-kubeletctl-execution.asciidoc
@@ -0,0 +1,132 @@
+[[prebuilt-rule-8-19-24-potential-kubeletctl-execution]]
+=== Potential Kubeletctl Execution
+
+Detects the execution of kubeletctl on Linux hosts. Kubeletctl is a command-line tool that can be used to interact with the Kubelet API directly, simplifying access to Kubelet endpoints that can be used for discovery and, in some cases, lateral movement within Kubernetes environments.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* auditbeat-*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster
+* https://github.com/cyberark/kubeletctl
+
+*Tags*: 
+
+* Domain: Endpoint
+* Domain: Container
+* Domain: Kubernetes
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Execution
+* Tactic: Discovery
+* Data Source: Elastic Defend
+* 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 Potential Kubeletctl Execution*
+
+
+This alert flags kubeletctl execution on a Linux host. Kubeletctl provides direct access to the node’s Kubelet API and can
+be used to enumerate pods and nodes and attempt actions such as exec/attach/portForward. A common attacker pattern is
+running `kubeletctl scan` to find reachable Kubelet endpoints, then using `pods` or `exec/attach` for follow-on access.
+
+
+*Possible investigation steps*
+
+
+- Review the full command line to identify the intended operation (scan/pods/exec/attach/portForward) and the target
+  Kubelet endpoint (node IP/hostname and port via `-s`/`--server`).
+- Correlate with host and container telemetry for connections to Kubelet ports (commonly 10250/10255) and look for
+  scanning patterns across multiple nodes.
+- Check whether Kubernetes credentials were accessed or used (service account tokens, kubeconfigs, client certs) and
+  correlate with Kubernetes audit logs for follow-on actions.
+
+
+*False positive analysis*
+
+
+- Approved operational debugging or incident response activity that uses kubeletctl for diagnostics.
+
+
+*Response and remediation*
+
+
+- Restrict access to Kubelet ports at the network layer and harden Kubelet authentication/authorization.
+- Rotate/revoke any exposed Kubernetes credentials and investigate for follow-on discovery or execution attempts.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "executed") and 
+(
+  process.name == "kubeletctl" or
+  (process.args in ("run", "exec", "scan", "pods", "runningpods", "attach", "portForward", "cri", "pid2pod") and process.args:("*:10250*", "*:10255*"))
+)
+
+----------------------------------
+
+*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/
+* 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/
+* Technique:
+** Name: Container Administration Command
+** ID: T1609
+** Reference URL: https://attack.mitre.org/techniques/T1609/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-macos-ssh-brute-force-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-macos-ssh-brute-force-detected.asciidoc
new file mode 100644
index 0000000000..f6895a2d63
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-macos-ssh-brute-force-detected.asciidoc
@@ -0,0 +1,158 @@
+[[prebuilt-rule-8-19-24-potential-macos-ssh-brute-force-detected]]
+=== Potential macOS SSH Brute Force Detected
+
+Identifies a high number of inbound SSH login attempts on a macOS host within a short time window. On macOS, each inbound SSH authentication attempt spawns the sshd-keygen-wrapper process once, whether the login succeeds or fails. Adversaries may perform password brute force or password spraying against exposed SSH services to obtain unauthorized access.
+
+*Rule type*: threshold
+
+*Rule indices*: 
+
+* logs-endpoint.events.*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://themittenmac.com/detecting-ssh-activity-via-process-monitoring/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: macOS
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 113
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Potential macOS SSH Brute Force Detected*
+
+
+SSH (Secure Shell) is a protocol used to securely access remote systems. On macOS, each inbound SSH authentication attempt spawns
+`sshd-keygen-wrapper` once before handing off to `sshd`, regardless of whether the login succeeds or fails. This rule uses that
+1:1 relationship as a proxy for high inbound SSH login attempt volume on a host. It does not detect SSH key generation or
+key-based brute force activity.
+
+
+*Possible investigation steps*
+
+
+- Review alert details for `host.os.type:macos`, `process.name:sshd-keygen-wrapper`, and `process.parent.name:launchd`.
+- Examine the frequency and timing of `sshd-keygen-wrapper` process starts to determine if they suggest automated login attempts.
+- Review SSH authentication logs on the affected host for failed and successful logins, source IP addresses, and targeted usernames.
+- Determine whether Remote Login is expected to be enabled on this host (for example, build servers or developer workstations).
+- Correlate the activity with other alerts or logs from the same host to identify additional indicators of compromise.
+- Review user account activity on the host to determine if any accounts were accessed or modified unexpectedly.
+
+
+*False positive analysis*
+
+
+- Build servers, developer workstations, or CI/CD pipelines that receive many legitimate inbound SSH connections may trigger this rule. Exclude known hosts or maintenance windows if the activity is expected.
+- Automated deployment or configuration management tools that open many SSH sessions in a short period can cause false positives.
+- Internet-facing SSH services may receive high volumes of scanning or credential-stuffing traffic from unrelated sources.
+- Security scanners or health checks that repeatedly test SSH connectivity may generate elevated `sshd-keygen-wrapper` activity.
+
+
+*Response and remediation*
+
+
+- Review SSH authentication logs to identify source IPs, targeted accounts, and whether any logins succeeded.
+- If unauthorized access is suspected, isolate the affected macOS host from the network.
+- Implement IP blocking or rate limiting on the SSH service to reduce further login attempts.
+- Review and reset credentials for affected user accounts if compromise is confirmed.
+- Conduct a thorough review of the host's SSH configuration and enabled Remote Login settings.
+- Escalate to the security operations team if additional hosts show similar patterns.
+- Enhance monitoring for SSH authentication anomalies across the environment.
+
+==== 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]
+----------------------------------
+event.category:process and host.os.type:macos and event.type:start and process.name:"sshd-keygen-wrapper" and process.parent.name:launchd
+
+----------------------------------
+
+*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/
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: External Remote Services
+** ID: T1133
+** Reference URL: https://attack.mitre.org/techniques/T1133/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-malicious-powershell-based-on-alert-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-malicious-powershell-based-on-alert-correlation.asciidoc
new file mode 100644
index 0000000000..2324cdb193
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-malicious-powershell-based-on-alert-correlation.asciidoc
@@ -0,0 +1,155 @@
+[[prebuilt-rule-8-19-24-potential-malicious-powershell-based-on-alert-correlation]]
+=== Potential Malicious PowerShell Based on Alert Correlation
+
+Identifies PowerShell script blocks linked to multiple distinct PowerShell detections via the same ScriptBlock ID, indicating compound suspicious behavior. Attackers often chain obfuscation, decoding, and execution within a single script block.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Execution
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+
+*Version*: 7
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Malicious PowerShell Based on Alert Correlation*
+
+
+
+*Possible investigation steps*
+
+
+- What does the ES|QL grouped alert preserve about the suspicious PowerShell mix?
+  - Focus: treat `Esql.script_block_id`, `Esql.kibana_alert_rule_name_values`, `Esql._id_values`, preserved `host.id` / `user.id`, and `Esql.kibana_alert_rule_name_count_distinct` as search clues, not evidence.
+  - Implication: escalate if rule names span obfuscation, download, execution, persistence, credential access, or defense evasion for one host/user; lower suspicion only when recovered source alerts/events show one recognized detection-validation script or controlled encoded-content automation pattern.
+
+- Do the contributing alerts bind the summary to one script execution?
+  - Focus: recover contributing alerts around grouped-alert time using preserved host/user, `Esql.kibana_alert_rule_name_values`, and script-block ID; use `Esql._id_values` only when alert search supports those IDs.
+  - Hint: recover contributing alerts before interpreting grouped behavior; ES|QL grouped alerts lack member-event Timeline pivots and reliable source-event time, PID, or entity anchors.
+  - Implication: treat as one execution chain only when source alerts and events align to one host, one user, one source-event window, and one script-block ID; keep unresolved if timestamps, script evidence, PID reuse risk, or entity scope conflict.
+
+- Can you reconstruct and interpret the source PowerShell script block?
+  - Focus: using recovered source-event host, process, and time, query PowerShell 4104 or source events; match `powershell.file.script_block_id`, order `powershell.sequence` / `powershell.total`, and read script-block text.
+  - Implication: escalate when reconstructed text shows encoded/decoded stages, download cradles, reflection, hosted System.Management.Automation execution, credential access, persistence, or defense evasion; missing fragments or source PowerShell telemetry are unresolved, not benign.
+
+- Which process and launch chain executed the script block?
+  - Focus: use recovered time, `host.id`, and process identifiers to find the process start; collect `process.entity_id`, `process.command_line`, `process.parent.command_line`, and `process.Ext.authentication_id`.
+  - Hint: if no process start appears, expand time first; if still missing, scope later file, registry, and network review to recovered source-event host/user/process/time.
+  - Implication: escalate when the launcher is a document, browser, remote-management tool, scheduled task, unexpected script or .NET host, or command line with encoded, hidden, bypass, download, or dynamic evaluation; lower suspicion only when the same parent, command, user, and host bind to the exact recovered benign workflow.
+
+- Did the process stage payloads, persistence, or security-impacting changes?
+  - Focus: scope file and registry events to recovered `process.entity_id` or fallback source-event host/PID/time context; review `file.path`, `file.origin_url`, `registry.path`, `registry.value`, and `registry.data.strings`.
+  - Implication: escalate when the script writes executable or scriptable content to user-writable or startup paths, leaves internet provenance, modifies persistence or security keys, or later executes staged content; lower suspicion only when artifacts stay inside the exact recovered benign workflow. Missing file or registry telemetry does not clear the alert.
+
+- Did network or session evidence fit offensive PowerShell use?
+  - Focus: scope DNS/connections to recovered `process.entity_id` or source-event host/PID/time context; read `dns.question.name`, `destination.ip`, and `destination.port`; when origin matters, bridge `process.Ext.authentication_id` to `winlog.event_data.TargetLogonId`.
+  - Implication: escalate when the script reaches rare or public destinations, pulls content, contacts infrastructure unrelated to the recovered workflow, or runs from an unexpected remote session; missing network or Windows Security telemetry is unresolved, not benign.
+
+- If local evidence is suspicious or unresolved, does the same pattern recur elsewhere enough to change scope?
+  - Focus: related alerts for preserved `user.id` over 48 hours, looking for the same `Esql.kibana_alert_rule_name_values`, reconstructed script fragment, launch context, or extracted indicators. !{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 user-scoped alerts are quiet or ambiguous, compare related alerts for preserved `host.id` over 48 hours. !{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 response when the same script body, rule-name mix, or indicators appear on unrelated hosts or users; keep scope local when recurrence stays on the host under review, but do not close from recurrence alone.
+
+- Weigh contributing-alert alignment, reconstructed script, launch chain, artifacts, destinations, and host/user scope; escalate for offensive tooling, unauthorized execution, staged payloads, persistence, or suspicious destinations; close only when source evidence binds to one exact benign workflow, using outside confirmation only for facts telemetry cannot prove; preserve artifacts and escalate on conflicts or missing telemetry.
+
+
+*False positive analysis*
+
+
+- Authorized red-team, lab, or detection-validation can trigger several PowerShell rules on one script. Confirm alert mix, reconstructed script, launch chain, `user.id`, and `host.id` match exact test scope; if records are unavailable, recurrence can support scoping but cannot close the alert.
+- Endpoint management or deployment automation can trigger multiple detections through encoded content, dynamic script generation, or controlled downloads. Confirm `powershell.file.script_block_text`, parent/child command lines, artifacts, and destinations align with one managed workflow. If script body, destinations, or follow-on artifacts diverge, do not close as benign.
+- Before an exception, validate stable benign anchors: `user.id`, `host.id`, parent/child command lines, script fragment, and destination or artifact pattern. Avoid exceptions on ES|QL summary fields or `Esql.script_block_id`; they are alert-local or execution-specific.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, document the alert mix, reconstructed script, launch chain, and recovered host/user context before reversing containment. Build exceptions from stable recovered workflow anchors, not ES|QL summary fields alone.
+- If suspicious but unconfirmed, preserve contributing alerts, `Esql._id_values`, `Esql.script_block_id`, rule-name values, reconstructed script text, recovered parent/child command lines, file/registry paths, and DNS/destination indicators before cleanup. Apply reversible containment first, such as temporary destination restrictions or heightened monitoring on recovered `host.id` and `user.id`; isolate or strengthen account action only if the script is still executing, staging payloads, or reaching suspicious destinations and host role allows.
+- If confirmed malicious, record entity IDs, command lines, and indicators, then isolate the host when lateral-movement or active-payload risk is present. Stop the PowerShell process or descendants only after preserving evidence; if direct response is unavailable, escalate with the evidence set. Block confirmed malicious destinations, URLs, hashes, and script paths; eradicate only tied files, registry changes, tasks, services, and payloads; remediate the launch path; and review related hosts/users before destructive cleanup.
+- Post-incident hardening: preserve or expand PowerShell 4104 logging, source-alert retention, endpoint process telemetry, and Windows Security logs when gaps limited recovery; where operations allow, restrict high-risk PowerShell through signed scripts, Constrained Language Mode, JEA, or WinRM controls. Document the rule-name mix, observables, and adjacent variants such as indirect System.Management.Automation execution.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from .alerts-security.* metadata _id
+
+// Filter for PowerShell related alerts
+| where kibana.alert.rule.name like "*PowerShell*"
+
+// as alerts don't have non-ECS fields, parse the script block ID using grok
+| grok message "ScriptBlock ID: (?<Esql.script_block_id>.+)"
+| where Esql.script_block_id is not null
+
+// keep relevant fields for further processing
+| keep kibana.alert.rule.name, Esql.script_block_id, _id, user.id, process.pid, host.id
+
+// count distinct alerts and filter for matches above the threshold
+| stats
+    Esql.kibana_alert_rule_name_count_distinct = count_distinct(kibana.alert.rule.name),
+    Esql.kibana_alert_rule_name_values = values(kibana.alert.rule.name),
+    Esql._id_values = values(_id),
+    Esql.user_id_values = values(user.id),
+    Esql.process_pid_values = values(process.pid),
+    Esql.host_id_values = values(host.id)
+  by Esql.script_block_id
+
+// Apply detection threshold
+| where Esql.kibana_alert_rule_name_count_distinct >= 5
+| eval user.id = MV_MIN(Esql.user_id_values),
+       process.pid = MV_MIN(Esql.process_pid_values),
+       host.id = MV_MIN(Esql.host_id_values)
+| keep host.id, user.id, process.pid, Esql.*
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-modification-of-accessibility-binaries.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-modification-of-accessibility-binaries.asciidoc
new file mode 100644
index 0000000000..b6da82a7ee
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-modification-of-accessibility-binaries.asciidoc
@@ -0,0 +1,204 @@
+[[prebuilt-rule-8-19-24-potential-modification-of-accessibility-binaries]]
+=== Potential Modification of Accessibility Binaries
+
+Windows contains accessibility features that may be launched with a key combination before a user has logged in. An adversary can modify the way these programs are launched to get a command prompt or backdoor without logging in to the system.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-endpoint.events.process-*
+* logs-windows.sysmon_operational-*
+* endgame-*
+* 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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.elastic.co/blog/practical-security-engineering-stateful-detection
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Resources: Investigation Guide
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Microsoft Defender XDR
+
+*Version*: 218
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Modification of Accessibility Binaries*
+
+
+*Possible investigation steps*
+
+
+- Does the alert show an accessibility-feature launch path running a different binary identity?
+  - Focus: `process.parent.name`, `user.name`, `process.args`, and `process.pe.original_file_name`.
+  - Implication: escalate when the logon accessibility path starts a SYSTEM process whose PE original name does not fit the requested feature; lower initial concern only when this exact host and binary match a narrow exception from prior verified testing. Otherwise, the mismatch stays suspicious.
+
+- What binary actually ran from the accessibility launch?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the executable is a shell, scripting or administration tool, user-writable copy, unsigned or unexpectedly signed binary, or rare hash for the host; stable hash or trusted signer lowers identity concern but does not clear the SYSTEM accessibility mismatch.
+
+- Did the launched binary create a SYSTEM follow-on process?
+  - Focus: process starts on the same `host.id` where `process.parent.entity_id` matches `process.entity_id`, checking `process.executable`, `process.args`, and `user.name`. !{investigate{"description":"","label":"Child process starts from the accessibility binary","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when follow-on activity opens a shell, scripting engine, remote-access tool, credential or account utility, or long-lived SYSTEM process; no children lowers follow-on severity only, not the accessibility mismatch.
+  - Hint: if `process.entity_id` is missing, use `host.id`, `process.pid`, and a tight alert-time window as a weaker fallback.
+
+- Do surrounding process starts show preparation, replacement, or cleanup?
+  - Focus: same-`host.id` process starts in a tight alert-time window, prioritizing parent or child links to the alerting process, then same `user.id`; check `process.name`, `process.args`, and `process.parent.name`. !{investigate{"description":"","label":"Process starts on the host near the alert","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when takeown, icacls, copy, robocopy, reg, PowerShell, cmd, or service-control activity surrounds the accessibility launch; absence of setup or cleanup reduces preparation evidence only, not the mismatch.
+  - Why: runtime evidence may not show whether abuse used binary replacement or IFEO/debugger redirection, so surrounding process starts can expose the setup path to preserve or restore.
+
+- If local evidence is suspicious or unresolved, is this a local one-off or repeated accessibility-hijack pattern?
+  - Focus: prior alerts and process starts for the same `host.id`, then the same `process.hash.sha256`, `process.executable`, or `process.pe.original_file_name` across other hosts.
+    - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Process events with the same SHA-256","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate scope when the same binary identity or PE mismatch appears on additional hosts, recurs after attempted cleanup, or clusters outside a recognized validation cohort; no recurrence lowers scope only. Do not close on absence or recurrence alone.
+
+- Escalate for suspicious binary identity, SYSTEM follow-on activity, preparation or cleanup, or unexplained recurrence. Close only when process evidence matches a preexisting narrow exception for one controlled test on this host; if absent or mixed, preserve the binary, process tree, and alert records and escalate.
+
+
+*False positive analysis*
+
+
+- Accessibility-feature hijacking is an operational anti-pattern. The main benign path is a preexisting, narrow security-test exception for this exact behavior. Compare the alert to stable exception anchors: `host.id`, `process.hash.sha256`, `process.executable`, `process.args`, `process.pe.original_file_name`, parent context, and child-process evidence; contradictions prevent benign closure.
+- Without a preexisting exception, do not close from recurrence alone. Treat stable recurrence as candidate exception evidence and keep the case open or escalated until the exact activity is verified.
+- Build exceptions only from stable test anchors: `process.hash.sha256`, signer identity, `process.args`, `process.pe.original_file_name`, and `host.id` or a tightly managed test cohort. Avoid exceptions on `process.name`, accessibility filenames, parent name, or `user.name` alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign:
+  - Record the exact evidence that confirmed the test: host, binary hash and signer, accessibility target, parent context, and absence of suspicious child or surrounding process activity.
+  - Reverse temporary containment after the evidence record is complete.
+  - Create a narrow exception only after the same test pattern is stable across prior alerts and limited to the validated cohort.
+- If suspicious but unconfirmed:
+  - Preserve the alert record, process tree, executable copy, hash, signature details, child-process events, and surrounding process events before containment.
+  - Apply reversible containment tied to the findings, such as temporary host isolation, restricted remote access, or increased monitoring on the affected host, and avoid deleting binaries or restoring system state until evidence is preserved.
+- If confirmed malicious:
+  - Record `process.entity_id`, `process.pid`, command arguments, executable path, hash, signer, and any child process identifiers before containment, termination, or cleanup.
+  - Contain the endpoint based on the binary identity, SYSTEM lineage, follow-on process activity, and recurrence scope that established malicious use.
+  - Block confirmed malicious hashes or binaries, then terminate active shells or backdoors.
+  - Restore affected accessibility binaries to known-good state, validate the accessibility launch path no longer starts the suspicious binary, and remediate the account, deployment tool, or remote-access path that allowed the change.
+  - Reset credentials only when follow-on activity or separate identity evidence shows account misuse.
+- Post-incident hardening:
+  - Restrict local administrator paths that can replace or redirect Windows accessibility features, and enforce application control for accessibility-feature execution where feasible.
+  - Ensure Remote Desktop exposure uses gateway controls and Network Level Authentication so remote users authenticate before the login screen path can be abused.
+  - Document the confirmed test pattern or malicious artifact set so future analysts can separate repeat validation from repeat abuse.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+ process.parent.name : ("Utilman.exe", "winlogon.exe") and user.name == "SYSTEM" and
+ process.pe.original_file_name : "?*" and
+ process.args :
+    (
+    "C:\\Windows\\System32\\osk.exe",
+    "C:\\Windows\\System32\\Magnify.exe",
+    "C:\\Windows\\System32\\Narrator.exe",
+    "C:\\Windows\\System32\\Sethc.exe",
+    "utilman.exe",
+    "ATBroker.exe",
+    "DisplaySwitch.exe",
+    "sethc.exe"
+    )
+ and not process.pe.original_file_name in
+    (
+    "osk.exe",
+    "sethc.exe",
+    "utilman2.exe",
+    "DisplaySwitch.exe",
+    "atbroker.exe",
+    "ATBroker.exe",
+    "ScreenMagnifier.exe",
+    "SR.exe",
+    "Narrator.exe",
+    "magnify.exe",
+    "MAGNIFY.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: Accessibility Features
+** ID: T1546.008
+** Reference URL: https://attack.mitre.org/techniques/T1546/008/
+* 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: Accessibility Features
+** ID: T1546.008
+** Reference URL: https://attack.mitre.org/techniques/T1546/008/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-notepad-markdown-rce-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-notepad-markdown-rce-exploitation.asciidoc
new file mode 100644
index 0000000000..94ba220b48
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-notepad-markdown-rce-exploitation.asciidoc
@@ -0,0 +1,179 @@
+[[prebuilt-rule-8-19-24-potential-notepad-markdown-rce-exploitation]]
+=== Potential Notepad Markdown RCE Exploitation
+
+Identifies a process started by Notepad after opening a Markdown file. This may indicate successful exploitation of a Notepad markdown parsing vulnerability (CVE-2026-20841) that can lead to arbitrary code execution.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* endgame-*
+* logs-endpoint.events.process-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-windows.sysmon_operational-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20841
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Execution
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Microsoft Defender XDR
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Resources: Investigation Guide
+
+*Version*: 5
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Notepad Markdown RCE Exploitation*
+
+
+
+*Possible investigation steps*
+
+
+- What exact Notepad-to-child path did the alert preserve?
+  - Why: CVE-2026-20841 abuse centers on Markdown link handling that invokes unsafe protocol handlers, so the launched child and target are decisive.
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.args`, child `process.executable`, and child `process.command_line`.
+  - Implication: escalate when Notepad opened Markdown and launched a shell, script host, downloader, browser, archive handler, installer, or custom protocol handler with a URL, UNC path, file URI, app installer URI, or staged payload; lower suspicion only when child and target match a confirmed validation workflow.
+
+- What does child binary identity add to command intent?
+  - Focus: child `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.pe.original_file_name`.
+  - Implication: escalate when the child is unsigned, user-writable, signer/name-mismatched, or unusual for Markdown link handling; reduce suspicion only when signer, path, hash history, and command target all fit the same confirmed validation workflow.
+
+- Does parent launch context point to lure delivery or controlled use?
+  - Focus: Markdown path from `process.parent.args`, `process.parent.command_line`, `user.id`, `host.id`, and `host.name`.
+  - Implication: escalate when the path is in downloads, mail or chat caches, temp, removable media, network shares, or lure-like filenames; lower suspicion only when source path and child target match a confirmed validation case for the same user or host.
+
+- Did the child start more exploit-chain processes?
+  - Focus: process events on `host.id` where `process.parent.entity_id` links to `process.entity_id`, recording descendant `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child process events for the Notepad-spawned child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: prefer entity ID-linked descendants; treat PID-only matches as candidates tightly anchored to `@timestamp`. Inspect `process.Ext.ancestry` only when direct lineage is incomplete.
+  - Implication: escalate for descendant shells, script interpreters, LOLBins, installers, payload runners, or browser-to-download chains; no descendants limits process scope but does not clear the Notepad launch.
+
+- Did the child stage artifacts for later execution?
+  - Focus: if file telemetry exists, review process-scoped `file.path`, `file.Ext.original.path`, and later `process.executable` reuse of a written path. !{investigate{"description":"","label":"File events for the same child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: recover with `host.id` + `process.entity_id`; if unavailable, use `host.id` + `process.pid` + a tight alert window. Missing file telemetry is unresolved, not benign.
+  - Implication: escalate when the child writes executables, scripts, shortcuts, archives, or renamed payloads to user-writable paths, or a written artifact later runs; clean available file telemetry means staging is not corroborated, not that the alert is benign.
+
+- Did the child contact payload-delivery destinations?
+  - Focus: if DNS or connection telemetry exists, review `dns.question.name`, `destination.ip`, and `destination.port`. !{investigate{"description":"","label":"Network events for the same child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: recover with `host.id` + `process.entity_id`; if unavailable, use `host.id` + `process.pid` + a tight alert window. Missing DNS or connection telemetry is unresolved, not benign.
+  - Implication: escalate when the child resolves or connects to rare, external, newly introduced, or delivery-oriented destinations outside its role; clean available network telemetry removes one corroborator but cannot override suspicious alert-local execution.
+
+- If local evidence is suspicious or unresolved, does the pattern change scope?
+  - Focus: related alerts for the same `user.id` over 48 hours, comparing child `process.executable`, child `process.command_line`, and source-path patterns from `process.parent.args` when present. !{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 user view is empty or ambiguous, compare related alerts for the same `host.id` over 48 hours before broadening. !{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 related alerts show the same Notepad-child pattern, source-path family, or delivery indicator across unrelated users or hosts; use recurrence for scope only, not benign closure.
+
+- Escalate when child intent, descendant lineage, artifact staging, or destinations point to payload delivery, even if one conditional telemetry family is absent; close only when source path, child identity, command target, and `user.id`/`host.id` context prove one benign workflow; preserve evidence and escalate when telemetry is missing or contradictory.
+
+
+*False positive analysis*
+
+
+- Authorized CVE validation, QA, or security lab activity can trigger this rule when controlled Markdown samples intentionally launch a stable helper. Confirm `process.parent.args`, child `process.executable`, child hash or signer, child `process.command_line`, and `user.id`/`host.id` cohort all match the same validation workflow; prior alerts support stability only after those anchors align.
+- Before creating an exception, validate stability for the same child identity, child command-target pattern, Markdown path family from `process.parent.args`, and `user.id` or `host.id` scope. Avoid exceptions on `process.parent.name`, `process.name`, or Notepad alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign:
+  - Reverse temporary containment and record the Markdown path, child process identity, command target, and cohort evidence that confirmed the benign workflow. Build an exception only for the same stable `user.id` or `host.id` scope and child identity.
+- If suspicious but unconfirmed:
+  - Preserve the triggering Markdown file, parent `process.parent.command_line`, child `process.entity_id`, child `process.command_line`, descendant process identifiers, written artifact paths, and DNS or IP indicators before cleanup.
+  - Apply reversible containment tied to observed indicators, such as temporary restriction of the observed destination or heightened monitoring on the affected `host.id` and `user.id`.
+  - Escalate to host isolation if the child continues spawning payloads, downloading content, or contacting suspicious destinations after preservation.
+- If confirmed malicious:
+  - Isolate the host first, then stop the malicious child and descendant `process.entity_id` values after recording `process.entity_id`, `process.command_line`, the Markdown path from `process.parent.args`, and related artifact or destination indicators. If direct response is unavailable, hand off the preserved evidence set to the containment team.
+  - Block confirmed malicious domains, IPs, URLs, hashes, and child process paths identified during the investigation.
+  - Eradicate only the dropped files, startup artifacts, scheduled tasks, registry changes, and payload runners tied to the exploit chain, then quarantine the triggering Markdown file and remediate its delivery path.
+- Post-incident hardening:
+  - Update the Windows Notepad App to a version that remediates CVE-2026-20841, and restrict unsafe protocol-handler launch exposure for Markdown viewers where enterprise controls support it.
+  - Preserve or expand file and network telemetry if missing visibility prevented confirmation of Markdown source, payload staging, or destination activity.
+  - Record the Markdown delivery path, child-process pattern, and adjacent protocol-handler or payload variants in the case notes.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+  process.parent.name : "notepad.exe" and process.parent.args : "*.md" and
+  not process.executable : "C:\\Program Files\\WindowsApps\\Microsoft.WindowsNotepad_*\\Notepad\\Notepad.exe"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Exploitation for Client Execution
+** ID: T1203
+** Reference URL: https://attack.mitre.org/techniques/T1203/
+* 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-24/prebuilt-rule-8-19-24-potential-powershell-hacktool-script-by-author.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-powershell-hacktool-script-by-author.asciidoc
new file mode 100644
index 0000000000..2da4fff3f6
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-powershell-hacktool-script-by-author.asciidoc
@@ -0,0 +1,185 @@
+[[prebuilt-rule-8-19-24-potential-powershell-hacktool-script-by-author]]
+=== Potential PowerShell HackTool Script by Author
+
+Identifies PowerShell script block content containing known offensive-tool author handles or attribution strings (for example, public tool author names). Attackers often run public PowerShell tooling with minimal changes, leaving author artifacts in comments or headers.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-windows.powershell*
+* 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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Execution
+* Data Source: PowerShell Logs
+* Resources: Investigation Guide
+
+*Version*: 110
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential PowerShell HackTool Script by Author*
+
+
+
+*Possible investigation steps*
+
+
+- What did the alert-local author match show?
+  - Focus: `powershell.file.script_block_text`, `powershell.file.script_block_length`, `file.path`, and `user.id` on `host.id`.
+  - Implication: escalate when the handle appears beside executable functions, encoded strings, download, credential, discovery, remote-execution, or persistence logic; lower suspicion when it is only an inert header or comment in a recognized lab, test, or community-module path with harmless surrounding code.
+
+- Can you reconstruct the complete script block before judging intent?
+  - Focus: collect and order fragments on `host.id` with `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and `powershell.file.script_block_text`. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when reconstruction reveals hidden stages, helper functions, obfuscation, decoding, or payload logic; keep unresolved if fragments are missing because they can hide decisive code.
+
+- Was the script file-backed or fileless, and what does that say about delivery?
+  - Focus: `file.path`, `file.directory`, and `file.name` when present; absent `file.path` suggests inline, generated, or interactive execution.
+  - Implication: escalate when fileless execution, user-writable paths, shares, temp or staging folders, or suspicious names pair with hacktool code; lower suspicion when a stable repository, lab path, or community-module path matches benign content.
+
+- Can you recover the PowerShell process and explain launch?
+  - Focus: With endpoint process telemetry, recover the matching process via `host.id + process.pid` before interpreting `process.*` or `process.parent.*`. Capture `process.entity_id`, `process.command_line`, `process.parent.executable`, and `process.parent.command_line`. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: confirm timestamps to reduce PID-reuse ambiguity; if no process start event appears, expand time before falling back to `host.id`, `user.id`, and alert time.
+  - Implication: escalate when a document, browser, chat client, remote-management tool, scheduled task, service, or unexpected script host launched the code without matching lab, assessment, support, or deployment evidence; lower suspicion when lineage matches the exact workflow proven by script content.
+
+- What capability or observables move this beyond attribution text?
+  - Focus: reconstructed script for credential access, discovery, remote execution, payload delivery, persistence, AMSI or logging tampering, reflection, or decode-and-execute logic; extract domains, IPs, URLs, paths, accounts, registry targets, and reusable function or module names.
+  - Implication: escalate when the body implements offensive capability or yields high-signal observables; lower suspicion only when it remains benign utility logic tied to a recognized workflow.
+
+- Did script-extracted file or registry targets appear on the host?
+  - Focus: With file or registry telemetry, search same-PID events around `@timestamp` for extracted `file.path`, `registry.path`, `registry.value`, or `registry.data.strings`. !{investigate{"description":"","label":"File and registry events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when extracted payload paths are created or executed, or registry targets indicate persistence or security changes; missing artifact or configuration telemetry is unresolved, not benign.
+
+- Did extracted network or identity observables confirm active offensive use?
+  - Focus: With network telemetry, search same-PID DNS and connection events for extracted domains in `dns.question.name` or `dns.resolved_ip` and IPs in `destination.ip`. !{investigate{"description":"","label":"Network and DNS events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} Review Windows 4624 or 4648 with `winlog.event_data.TargetUserName` and `winlog.event_data.SubjectUserName` for extracted accounts.
+  - Implication: escalate when the host contacts extracted infrastructure, downloads content, or shows remote, credential, or lateral-use evidence. Missing network or authentication telemetry is unresolved, not benign.
+
+- If the script content or launch chain remains suspicious or unresolved, does recurrence change scope?
+  - Focus: related alerts for `user.id` in the last 48 hours, comparing author string, reconstructed script body, file source, launch pattern, and extracted observables. !{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 user view is quiet or ambiguous, compare related alerts for `host.id` in the last 48 hours. !{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 the same script body or extracted observables reach unrelated users or hosts; keep local when recurrence stays within the same lab, assessment, support, or deployment host/user cohort. Do not close on recurrence alone if script content or recovery remains unresolved.
+
+- Escalate on reconstructed capability, unauthorized launch, follow-on evidence, or missing/conflicting required telemetry; close only when the author match, reconstructed script, source path, launch context, observables, and `user.id` or `host.id` scope bind one exact benign workflow, with outside confirmation when telemetry cannot verify it.
+
+
+*False positive analysis*
+
+
+- Authorized testing, red-team, malware-analysis, validation, community-module, or admin scripts can retain author strings. Confirm the reconstructed body, exact `user.id` and `host.id` scope, `file.path` or launch context, recognized test or lab records when telemetry cannot prove legitimacy, and no contradictory observables or follow-on activity.
+- Before creating an exception, validate recurrence of the same benign workflow with the same `powershell.file.script_block_text` fragment, `file.path` or launch source, and `user.id` or `host.id` scope. Avoid author-string-only exceptions because unrelated offensive scripts can reuse the same handle.
+
+
+*Response and remediation*
+
+
+- If confirmed benign:
+  - Reverse temporary containment and document the reconstructed script, source path, launch context, `user.id`, and `host.id` evidence confirming the legitimate workflow. Build an exception only for that exact workflow and scope.
+- If suspicious but unconfirmed:
+  - Preserve or export alert details, reconstructed script with fragment metadata, process PID, source path, extracted indicators, and recovered launch details before containment or cleanup.
+  - Apply reversible containment tied to the evidence, such as temporary restrictions for extracted destinations or heightened monitoring on affected `host.id` and `user.id`.
+  - Escalate to host isolation or stronger account action only if the script is still executing, staging payloads, reaching suspicious destinations, or showing credential or lateral-use evidence, and the host role tolerates isolation.
+- If confirmed malicious:
+  - Preserve the reconstructed script, recovered process entity ID and launch details, extracted indicators, staged artifacts, and timeline before isolation, process termination, or cleanup.
+  - Isolate the host when script capability, launch context, follow-on artifacts, or destination evidence confirms unauthorized activity and the host role tolerates isolation.
+  - Block confirmed malicious destinations, URLs, file hashes, and script paths found during triage.
+  - Eradicate only dropped files, registry changes, scheduled tasks, services, and follow-on payloads tied to this script, then remediate the path that delivered or launched it.
+  - Review related hosts and users for the same author string, reconstructed script body, or extracted indicators before destructive cleanup so scoping is complete.
+- Post-incident hardening:
+  - Verify PowerShell 4104 logging coverage and retention are sufficient to reconstruct multi-part scripts and preserve process recovery context.
+  - Restrict authorized testing of public offensive PowerShell tooling to controlled hosts and identities.
+  - Document matched author strings, extracted observables, and author-stripped or rebranded variants surfaced during triage for future analyst reference.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).
+Setup instructions: https://ela.st/powershell-logging-setup
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+host.os.type:windows and event.category:process and
+  powershell.file.script_block_text : (
+      "mattifestation" or "JosephBialek" or
+      "harmj0y" or "ukstufus" or
+      "SecureThisShit" or "Matthew Graeber" or
+      "secabstraction" or "mgeeky" or
+      "oddvarmoe" or "am0nsec" or
+      "obscuresec" or "sixdub" or
+      "darkoperator" or "funoverip" or
+      "rvrsh3ll" or "kevin_robertson" or
+      "dafthack" or "r4wd3r" or
+      "danielhbohannon" or "OneLogicalMyth" or
+      "cobbr_io" or "xorrior" or
+      "PetrMedonos" or "citronneur" or
+      "eladshamir" or "RastaMouse" or
+      "enigma0x3" or "FuzzySec" or
+      "424f424f" or "jaredhaight" or
+      "fullmetalcache" or "Hubbl3" or
+      "curi0usJack" or "Cx01N" or
+      "itm4n" or "nurfed1" or
+      "cfalta" or "Scott Sutherland" or
+      "_nullbind" or "_tmenochet" or
+      "jaredcatkinson" or "ChrisTruncer" or
+      "monoxgas" or "TheRealWover" or
+      "splinter_code" or "samratashok" or
+      "leechristensen" or "nikhil_mitt"
+  ) and
+  not powershell.file.script_block_text : ("Get-UEFIDatabaseSigner" or "Posh-SSH")
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-in-container-via-runc-init.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-in-container-via-runc-init.asciidoc
new file mode 100644
index 0000000000..a4705a7c49
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-in-container-via-runc-init.asciidoc
@@ -0,0 +1,136 @@
+[[prebuilt-rule-8-19-24-potential-privilege-escalation-in-container-via-runc-init]]
+=== Potential Privilege Escalation in Container via Runc Init
+
+Identifies audit events for runc init child processes where the effective user is root and the login user ID is not root. This pattern can indicate privilege escalation or credential separation abuse inside container runtimes, where a process executes with elevated effective privileges while retaining a non-root audit identity.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* auditbeat-*
+* logs-auditd_manager.auditd-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1611/
+* https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation
+
+*Tags*: 
+
+* Domain: Endpoint
+* Domain: Container
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Resources: Investigation Guide
+* Data Source: Auditd Manager
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Privilege Escalation in Container via Runc Init*
+
+
+runc is the low-level container runtime used by Docker, containerd, and others. The runc init process initializes the
+container environment. A mismatch between effective root (user.effective.id 0) and a non-root user.id in audit
+telemetry can reflect namespace or capability transitions worth validating in your environment.
+
+
+*Possible investigation steps*
+
+
+- Confirm the host is running containers and identify which workload invoked runc (orchestrator, image, namespace).
+- Review full audit fields for the event: process, process.parent, user.*, and any container or cgroup metadata
+  available in your auditd_manager pipeline.
+- Correlate with other alerts on the same host (namespace changes, mounts, unshare, nsenter, suspicious image pulls).
+- Validate whether the pattern matches expected behavior for your container stack (e.g. specific init or security
+  profiles) before treating as malicious.
+
+
+*False positive analysis*
+
+
+- Some legitimate container or CRI configurations may produce effective UID 0 with a non-root login UID in audit records.
+  Tune with host, image, or process ancestry exclusions after baseline review.
+
+
+*Response and remediation*
+
+
+- If abuse is confirmed: isolate the node or workload, rotate credentials exposed to that container, and rebuild from a
+  trusted image after forensic capture.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires Linux audit events from the **Auditd Manager** integration.
+
+
+*Auditd Manager integration*
+
+
+Auditd Manager simplifies configuring and monitoring the Linux audit subsystem via Fleet. Administrators define audit
+rules, collect events, and forward them to Elasticsearch.
+
+
+*Steps to deploy Auditd Manager*
+
+
+- In Kibana, go to **Integrations** and search for **Auditd Manager**.
+- Add the integration to an Elastic Agent policy that covers your Linux hosts.
+- Configure audit rules appropriate for your environment so execve and identity-related fields are captured where
+  needed for this detection.
+
+For more details, see the https://docs.elastic.co/integrations/auditd_manager[Auditd Manager integration documentation].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+host.os.type:linux and event.category:process and 
+event.action:(executed or exec) and 
+process.title:"runc init" and user.effective.id:0 and user.id:(* and not 0)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Escape to Host
+** ID: T1611
+** Reference URL: https://attack.mitre.org/techniques/T1611/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-cve-2022-38028.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-cve-2022-38028.asciidoc
new file mode 100644
index 0000000000..bcd4407ce3
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-cve-2022-38028.asciidoc
@@ -0,0 +1,184 @@
+[[prebuilt-rule-8-19-24-potential-privilege-escalation-via-cve-2022-38028]]
+=== Potential privilege escalation via CVE-2022-38028
+
+Identifies a potential privilege escalation attempt via CVE-2022-38028 through modification of the protected Print to PDF MPDW constraints script.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.file-*
+* logs-windows.sysmon_operational-*
+* endgame-*
+* winlogbeat-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-crowdstrike.fdr*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.microsoft.com/en-us/security/blog/2024/04/22/analyzing-forest-blizzards-custom-post-compromise-tool-for-exploiting-cve-2022-38028-to-obtain-credentials/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Microsoft Defender XDR
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 211
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential privilege escalation via CVE-2022-38028*
+
+
+
+*Possible investigation steps*
+
+
+- Does the alert show protected-path MPDW-constraints.js placement outside Windows servicing?
+  - Why: the rule proves a Print to PDF constraints-script write, not Print Spooler execution of the modified script.
+  - Focus: confirm `file.path` is DriverStore or Print to PDF WinSxS for MPDW-constraints.js, then read `process.executable`, `process.command_line`, `process.parent.executable`, and `process.parent.command_line`. !{investigate{"description":"","label":"File events for the same suspicious JavaScript path","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-2h","relativeTo":"now"}}
+  - Implication: escalate when the target is protected DriverStore or WinSxS and the writer is not Windows setup, repair, or print-component servicing; lower suspicion only when path, writer, parent, and surrounding servicing files match the same recognized OS or Print to PDF repair activity.
+- Does the writer process look like GooseEgg staging rather than servicing?
+  - Why: Microsoft observed GooseEgg launchers and batch scripts before Print Spooler redirection; writer identity and parentage separate servicing from exploit staging.
+  - Focus: recover the writer start event with `process.entity_id`; compare `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.parent.executable`, and `process.parent.command_line`.
+  - Implication: escalate when writer or parent is a batch/script host, user-writable or renamed binary, known GooseEgg launcher, or unsigned/unrecognized executable; lower suspicion when identity and lineage remain signed Windows servicing or recognized print-management tooling.
+- Did the same writer stage GooseEgg files or copied driver-store content?
+  - Why: published GooseEgg examples stage batch files, wayzgoose*.dll, and copied print-driver directories under version-like C:\ProgramData\<vendor>\v#.#.# paths.
+  - Focus: same `host.id` and `process.entity_id` file events: `file.path`, `file.name`, `file.Ext.original.path`, and `file.Ext.header_bytes` for staging, rename, or content clues. !{investigate{"description":"","label":"File events from the writer process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-2h","relativeTo":"now"}}
+  - Implication: escalate when those filenames, ProgramData version paths, copied driver-store directories, .save / .zip hive outputs, or rename chains appear around the writer; lower suspicion when the same-process file set is limited to recognized servicing content and no GooseEgg artifact family appears.
+- If registry telemetry is available, did the writer create GooseEgg protocol or CLSID redirection?
+  - Focus: same `host.id` and `process.entity_id` registry events, especially `registry.path`, `registry.value`, `registry.data.strings`, and `process.executable` for rogue protocol handler, CLSID, or wayzgoose*.dll paths. !{investigate{"description":"","label":"Registry events from the writer process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-2h","relativeTo":"now"}}
+  - Hint: missing registry telemetry is unresolved, not benign; continue with file, process, and spooler evidence.
+  - Implication: escalate when registry changes register the rogue protocol or CLSID or point Print Spooler resolution to actor-controlled ProgramData content; lower suspicion only when available registry data remains recognized print-component configuration and file/process evidence is also clean.
+- Did activation or spooler follow-on show SYSTEM-level execution?
+  - Focus: process starts after the write on `host.id`: `process.name`, `process.parent.name`, `process.parent.executable`, `process.command_line`, and `process.Ext.token.integrity_level_name` for scheduled-task launch, spoolsv.exe, PrintIsolationHost.exe, or SYSTEM command tests. !{investigate{"description":"","label":"Process events after the protected file write","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}}
+  - Hint: with library telemetry, check `dll.name` and `dll.path` for wayzgoose*.dll or loads from the written driver-store path; missing library telemetry is unresolved for load proof, not benign.
+  - Implication: escalate when the host shows scheduled-task activation as SYSTEM, spooler or print isolation child processes, a SYSTEM whoami test, or a wayzgoose*.dll load after the write; absence is no execution proof, not proof the write was benign.
+- Does the suspicious artifact set recur enough to change scope?
+  - Focus: after suspicious or unresolved local evidence, review recent alerts for `host.id`, then search `file.path`, suspicious `process.hash.sha256`, and GooseEgg filenames across hosts. !{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 containment and hunting when the same writer hash, ProgramData version path, wayzgoose*.dll, or protected MPDW-constraints.js placement appears on other hosts or pairs with spooler/privilege-escalation alerts; keep scope local when recurrence is absent and local evidence resolves to one recognized workflow.
+- Escalate when protected-path placement aligns with non-servicing lineage or any GooseEgg, registry, scheduled-task, or spooler corroborator; close only when path, writer, parent, file set, user/host scope, and recovery bind to one recognized servicing or print workflow; preserve artifacts and escalate when evidence is mixed, missing, or contradictory.
+
+
+*False positive analysis*
+
+
+- Windows servicing, Print to PDF repair, printer-driver packaging, image-build, or print-management workflows can touch these paths. Confirm `file.path`, writer, parent, signer, `host.id` cohort, surrounding file set, and spooler follow-on all bind to one such workflow, with no GooseEgg artifacts, rogue registry evidence, or spooler child-process anomalies. Change records, patch windows, build records, or management tickets can corroborate; if unavailable, close only when telemetry independently proves the bounded workflow.
+- Before creating an exception, validate a stable benign workflow across prior alerts: keep writer identity, `process.parent.executable`, `file.path`, `host.id` cohort, and bounded file set stable. Avoid exceptions on MPDW-constraints.js alone, DriverStore or WinSxS paths alone, or spoolsv.exe activity alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and record the `file.path`, writer identity, parent lineage, `host.id` cohort, and servicing or print-management file pattern that justified closure. Create an exception only for that recurring workflow.
+- If suspicious but unconfirmed, preserve the written MPDW-constraints.js, its path and hash when available, the writer `process.entity_id`, `process.executable`, `process.command_line`, parent lineage, `user.id`, GooseEgg scripts or DLLs, ProgramData staging directories, scheduled-task evidence, and any registry or library corroboration before cleanup. Apply reversible containment first, such as pausing nonessential printing, limiting print-management access, isolating the host when business impact permits, or increasing monitoring. Avoid deleting files, stopping spoolsv.exe, or restoring registry state until the evidence is preserved.
+- If confirmed malicious, preserve the same file, process, registry, library, scheduled-task, and spooler evidence first, then isolate the host through endpoint response when available and proportionate to host criticality. If direct response is unavailable, escalate with the preserved `file.path`, writer lineage, staging directory, registry redirection, and spooler follow-on evidence to the team that can act. After scope is clear, remove the malicious JavaScript, GooseEgg scripts, wayzgoose*.dll, ProgramData staging directory, scheduled task, and rogue registry/protocol state; restore affected print configuration, close the staging mechanism, and rotate credentials only for accounts or hives exposed by collected evidence.
+- Post-incident hardening: apply the Microsoft security update for CVE-2022-38028, disable Print Spooler on systems that do not need it, restrict print-management rights, retain file/process coverage plus registry or library telemetry where it limited the investigation, and document the confirmed MPDW-constraints.js, ProgramData, wayzgoose, or scheduled-task pattern 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/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.name : "MPDW-constraints.js" and
+    file.path : (
+        "?:\\*\\Windows\\system32\\DriverStore\\FileRepository\\*\\MPDW-constraints.js",
+        "?:\\*\\Windows\\WinSxS\\amd64_microsoft-windows-printing-printtopdf_*\\MPDW-constraints.js", 
+        "\\Device\\HarddiskVolume*\\*\\Windows\\system32\\DriverStore\\FileRepository\\*\\MPDW-constraints.js",
+        "\\Device\\HarddiskVolume*\\*\\Windows\\WinSxS\\amd64_microsoft-windows-printing-printtopdf_*\\MPDW-constraints.js"
+    ) and
+    not process.executable : (
+          "?:\\$WINDOWS.~BT\\Sources\\SetupHost.exe",
+          "?:\\Windows\\System32\\taskhostw.exe"
+    ) and
+    not file.path : (
+        "?:\\$WINDOWS.~BT\\NewOS\\Windows\\WinSxS\\*\\MPDW-constraints.js",
+        "\\Device\\HarddiskVolume*\\$WINDOWS.~BT\\NewOS\\Windows\\WinSxS\\*\\MPDW-constraints.js"
+    )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Exploitation for Privilege Escalation
+** ID: T1068
+** Reference URL: https://attack.mitre.org/techniques/T1068/
+* Technique:
+** Name: Hijack Execution Flow
+** ID: T1574
+** Reference URL: https://attack.mitre.org/techniques/T1574/
+* Sub-technique:
+** Name: Services File Permissions Weakness
+** ID: T1574.010
+** Reference URL: https://attack.mitre.org/techniques/T1574/010/
+* 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-installerfiletakeover.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-installerfiletakeover.asciidoc
new file mode 100644
index 0000000000..4b71d3dbde
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-installerfiletakeover.asciidoc
@@ -0,0 +1,163 @@
+[[prebuilt-rule-8-19-24-potential-privilege-escalation-via-installerfiletakeover]]
+=== Potential Privilege Escalation via InstallerFileTakeOver
+
+Identifies a potential exploitation of InstallerTakeOver (CVE-2021-41379) default PoC execution. Successful exploitation allows an unprivileged user to escalate privileges to SYSTEM.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/klinix5/InstallerFileTakeOver
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Resources: Investigation Guide
+* Use Case: Vulnerability
+* Data Source: Elastic Defend
+
+*Version*: 116
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Privilege Escalation via InstallerFileTakeOver*
+
+
+
+*Possible investigation steps*
+
+
+- Which alert path fired: a suspect service binary or a service-spawned child?
+  - Focus: alert-local `process.name`, `process.executable`, `process.command_line`, `process.parent.executable`, and `process.Ext.token.integrity_level_name`.
+  - Implication: escalate when SYSTEM "elevation_service.exe" runs outside "%ProgramFiles% or %ProgramFiles(x86)%\Microsoft\Edge\Application\<version>\elevation_service.exe" or starts "cmd.exe", "powershell.exe", or "rundll32.exe"; lower suspicion only for a genuine Edge service start with no shell child.
+- Is the elevation service binary genuine Microsoft content?
+  - Focus: compare service `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`; for child alerts, recover the parent service start on `host.id` with `process.parent.entity_id` and compare those fields there.
+  - Hint: if a child alert lacks parent hash or signer details, recover the parent service process start with entity or PID fallback. !{investigate{"description":"","label":"Parent elevation service process start","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when original filename is not "elevation_service.exe", signer is not Microsoft, trust fails, or the same hash appears from a user-writable path; lower suspicion only when path, filename, signer, trust, and hash history fit the expected Microsoft Edge service.
+- Does lineage show Windows Installer takeover rather than normal Edge servicing?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.code_signature.subject_name`, `process.parent.code_signature.trusted`, and broader process lineage when needed.
+  - Implication: escalate when an MSI, temp, or user-session chain leads to the SYSTEM service or shell; lower suspicion when Microsoft-signed Edge installer or updater lineage starts the genuine service with servicing arguments and no shell.
+- Do recovered file events show service overwrite or PoC staging artifacts?
+  - Focus: if file telemetry exists, open host-scoped file events, then filter to the recovered service or child `process.entity_id`; if entity IDs are absent, use `host.id` plus service `process.pid` or `process.parent.pid` and the alert window. Review `file.path`, `file.Ext.original.path`, and writing `process.executable`. !{investigate{"description":"","label":"File events on this host near the alert","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Range: start 30 minutes before the alert because MSI administrative-install staging can precede service execution.
+  - Implication: escalate when the Edge service path is overwritten or PoC artifacts such as the "microsoft plz" temp folder, temp MSI, or "elevation_service.exe" file creation cluster around the alert; treat those names as corroborators, not required evidence. Missing file telemetry is unresolved, not benign.
+  - Hint: modified variants may omit PoC names; keep this centered on service replacement and MSI staging when names differ.
+- What did the SYSTEM service or spawned child do next?
+  - Focus: descendant process starts on the same `host.id` from `process.entity_id` or `process.parent.entity_id`, especially `process.name`, `process.command_line`, and `process.Ext.token.integrity_level_name`. !{investigate{"description":"","label":"Child process starts from the alert process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when SYSTEM context launches credential-access, persistence, payload staging, or remote-execution tooling; keep scope near the privilege-escalation event only when the service or shell produces no follow-on SYSTEM activity.
+- If local findings remain suspicious or unresolved, do related alerts show broader exploitation?
+  - Focus: related alerts for the same `host.id` in the last 48 hours, especially service tampering, suspicious MSI, credential access, or follow-on execution. !{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"}}
+  - Hint: compare `user.id` only when it identifies a non-SYSTEM actor; otherwise keep broadened review host-scoped and use lineage to avoid over-attributing the operator. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden response when the same host or user shows privilege-escalation or post-exploitation alerts; quiet related-alert review does not close unresolved local evidence.
+- Escalate on identity mismatch, MSI/user lineage, service overwrite, SYSTEM shell, or follow-on activity; close only when all evidence fits genuine Microsoft Edge service identity with no shell behavior or verified validation/detonation; preserve artifacts and escalate when evidence is mixed or telemetry is missing.
+
+
+*False positive analysis*
+
+
+- Authorized exploit validation, red-team work, detection-content testing, malware research, or incident-response detonation can trigger this rule on lab or disposable analysis hosts. Confirm `process.hash.sha256`, service `process.executable`, parent `process.parent.executable`, child `process.command_line`, recovered temp-artifact pattern, and bounded `host.id` cohort match the same test kit or analysis-host cohort. If change, test, or sandbox records are unavailable, require the same telemetry pattern across prior alerts from this rule before closing as benign.
+- Before creating an exception, keep `process.hash.sha256`, `process.executable`, `process.parent.executable`, child `process.command_line`, `host.id`, and the recovered temp-artifact pattern stable across prior alerts from this rule. Avoid exceptions on `process.name`, `process.parent.name`, or "elevation_service.exe" alone because those values overlap real service abuse.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and record the validation or analysis workflow that matched the alert, including the stable `process.hash.sha256`, service `process.executable`, parent `process.parent.executable`, child `process.command_line`, recovered artifact pattern, and bounded `host.id` cohort. Create an exception only after the same pattern recurs across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve the case export, process tree with service and child entity IDs, service binary and hash identity, spawned-shell command line, and recovered service-overwrite or temp-artifact timeline before containment or cleanup. Apply reversible containment first, such as heightened monitoring or host isolation when the asset role permits it; terminate the spawned shell only after capture, and escalate to isolation if follow-on SYSTEM activity or spread appears.
+- If confirmed malicious, use the preserved identity, lineage, artifact, and follow-on evidence to isolate the endpoint or escalate to the team that can contain it. Before replacing or deleting files, collect the overwritten service binary, temp MSI or recovered PoC artifacts, and spawned-shell timeline. Review related hosts and users for the same hash or service-path pattern, then restore the genuine Edge elevation service binary and remove only attacker payloads, persistence, or configuration changes identified during scoping.
+- Post-incident hardening: verify Windows Installer and Edge components are patched, restrict unnecessary MSI administrative-install paths where possible, retain process and file telemetry long enough to reconstruct service replacement, and record the service-path, temp-artifact, and child-shell pattern for future response.
+
+
+==== 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]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+    process.Ext.token.integrity_level_name : "System" and
+    (
+      (process.name : "elevation_service.exe" and
+       not process.pe.original_file_name == "elevation_service.exe") or
+      
+      (process.name : "elevation_service.exe" and
+       not process.code_signature.trusted == true) or
+
+      (process.parent.name : "elevation_service.exe" and
+       process.name : ("rundll32.exe", "cmd.exe", "powershell.exe"))
+    ) and
+    not
+    (
+      process.name : "elevation_service.exe" and process.code_signature.trusted == true and
+      process.pe.original_file_name == null
+    )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Exploitation for Privilege Escalation
+** ID: T1068
+** Reference URL: https://attack.mitre.org/techniques/T1068/
+* Technique:
+** Name: Hijack Execution Flow
+** ID: T1574
+** Reference URL: https://attack.mitre.org/techniques/T1574/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Masquerading
+** ID: T1036
+** Reference URL: https://attack.mitre.org/techniques/T1036/
+* Sub-technique:
+** Name: Match Legitimate Resource Name or Location
+** ID: T1036.005
+** Reference URL: https://attack.mitre.org/techniques/T1036/005/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-suid-sgid.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-suid-sgid.asciidoc
new file mode 100644
index 0000000000..d55204548f
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-suid-sgid.asciidoc
@@ -0,0 +1,114 @@
+[[prebuilt-rule-8-19-24-potential-privilege-escalation-via-suid-sgid]]
+=== Potential Privilege Escalation via SUID/SGID
+
+Detects potential privilege escalation under the root effective user when the real user and parent user are not root, indicative of the execution of binaries with SUID or SGID bits set.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1548/
+
+*Tags*: 
+
+* Data Source: Elastic Defend
+* Domain: Endpoint
+* OS: Linux
+* 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 Potential Privilege Escalation via SUID/SGID*
+
+
+Adversaries exploit misconfigured SUID/SGID binaries to gain elevated access or persistence. This rule identifies processes running with root privileges but initiated by non-root users, flagging potential misuse of SUID/SGID permissions.
+
+
+*Possible investigation steps*
+
+
+- Inspect `process.parent.command_line` and working directory for obfuscation or one-liners.
+- Check authentication and sudoers policy for the user.
+- Pivot on the host for additional privilege escalation or persistence in the same session.
+
+
+*Response and remediation*
+
+
+- If unauthorized, contain the session, revoke elevated access, and review sudoers and polkit policy for tampering.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
+  (process.user.id == "0" and process.real_user.id != "0" and process.parent.user.id != "0") or
+  (process.group.id == "0" and process.real_group.id != "0" and process.parent.group.id != "0")
+) and
+(
+  startsWith(process.executable, process.command_line) or
+  startsWith(process.name, process.command_line)
+) and
+(
+  process.parent.name like (".*", "python*", "perl*", "ruby*", "lua*", "php*", "node", "deno", "bun", "java") or
+  process.parent.executable like ("./*", "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/user/*", "/var/run/user/*", "/home/*/*") or
+  (
+    process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh") and
+    process.parent.args in ("-c", "-cl", "-lc", "--command", "-ic", "-ci", "-bash", "-sh", "-zsh", "-dash", "-fish", "-ksh", "-mksh") and
+    process.parent.args_count <= 4
+  )
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Abuse Elevation Control Mechanism
+** ID: T1548
+** Reference URL: https://attack.mitre.org/techniques/T1548/
+* Sub-technique:
+** Name: Setuid and Setgid
+** ID: T1548.001
+** Reference URL: https://attack.mitre.org/techniques/T1548/001/
+* Sub-technique:
+** Name: Sudo and Sudo Caching
+** ID: T1548.003
+** Reference URL: https://attack.mitre.org/techniques/T1548/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-unshare-and-uid-change.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-unshare-and-uid-change.asciidoc
new file mode 100644
index 0000000000..0b92876fb8
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-unshare-and-uid-change.asciidoc
@@ -0,0 +1,154 @@
+[[prebuilt-rule-8-19-24-potential-privilege-escalation-via-unshare-and-uid-change]]
+=== Potential Privilege Escalation via unshare and UID Change
+
+Identifies potentially suspicious use of unshare to create a user namespace context followed by a UID change event indicating a transition to root. Adversaries may use unshare-based primitives as part of local privilege escalation chains. This rule is intentionally generic and can surface multiple local privesc patterns beyond a single CVE.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.wiz.io/blog/ubuntu-overlayfs-vulnerability
+* https://twitter.com/liadeliyahu/status/1684841527959273472
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Use Case: Vulnerability
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 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 Potential Privilege Escalation via unshare and UID Change*
+
+
+The unshare utility can create new namespaces, including user namespaces. In some exploit chains, an attacker uses
+unshare (often with user namespace flags) as a precursor step and then achieves a transition to root. This rule detects
+a short sequence where a non-root user executes unshare with user-namespace related arguments and a subsequent uid_change
+event indicates the user became root, which can represent a successful local privilege escalation attempt.
+
+
+*Possible investigation steps*
+
+
+- Review unshare arguments in the first event to confirm user namespace related flags were used (for example -U/--user or -r).
+- Check the process tree and parent context (process.parent.entity_id) to understand what launched unshare and whether it originated from an interactive session or user-writable path.
+- Confirm whether the uid_change corresponds to the same activity and identify the first root process spawned after the uid_change event.
+- Review other host signals around the same time for exploit activity such as compilation in /tmp, suspicious downloads, or execution of unusual binaries.
+
+
+*False positive analysis*
+
+
+- Legitimate sandboxing or container tooling may use unshare and then legitimately trigger uid_change events; validate the parent process and user context.
+- Security testing, exploit validation, or developer environments may intentionally exercise namespace-related behavior; tune by users, hosts, or maintenance windows.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected host to prevent further privilege abuse or lateral movement.
+- Terminate suspicious processes and collect forensic data (process tree, binaries, and relevant files in temp locations).
+- Patch and harden the host; review policies that allow unprivileged user namespaces if not required in your environment.
+- Escalate for incident response when root access is confirmed and scope for follow-on persistence.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from Elastic Defend.
+
+
+*Elastic Defend Integration Setup*
+
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+
+
+*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide].
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide].
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by process.parent.entity_id, host.id with maxspan=60s
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+    process.name == "unshare" and process.args : ("-r", "-rm", "m", "-U", "--user") and user.id != "0"]
+  [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and
+    user.id == "0"]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Exploitation for Privilege Escalation
+** ID: T1068
+** Reference URL: https://attack.mitre.org/techniques/T1068/
+* Technique:
+** Name: Abuse Elevation Control Mechanism
+** ID: T1548
+** Reference URL: https://attack.mitre.org/techniques/T1548/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-unshare-followed-by-root-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-unshare-followed-by-root-process.asciidoc
new file mode 100644
index 0000000000..e9e9a9352a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privilege-escalation-via-unshare-followed-by-root-process.asciidoc
@@ -0,0 +1,146 @@
+[[prebuilt-rule-8-19-24-potential-privilege-escalation-via-unshare-followed-by-root-process]]
+=== Potential Privilege Escalation via unshare Followed by Root Process
+
+Detects a short sequence where a non-root user performs unshare-related namespace activity (often associated with user namespace privilege escalation primitives) and then a root process is executed shortly after. This can indicate a successful local privilege escalation attempt or suspicious namespace manipulation captured in Auditd Manager telemetry.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* auditbeat-*
+* logs-auditd_manager.auditd-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.elastic.co/integrations/auditd_manager
+* https://attack.mitre.org/techniques/T1068/
+
+*Tags*: 
+
+* Data Source: Auditd Manager
+* Domain: Endpoint
+* OS: Linux
+* 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 Potential Privilege Escalation via unshare Followed by Root Process*
+
+
+Validate that the initiating user and parent process should be using unshare. Then confirm whether the subsequent root
+process aligns with an approved administrative workflow or represents an unexpected transition to root.
+
+
+*Possible investigation steps*
+
+
+- Review auditd.data.* (syscall, class, and a0) and process args to understand the unshare intent.
+- Identify the first root process spawned and its command line, then look for follow-on persistence or credential access.
+- Correlate with recent downloads/compilation in temp directories and other local privesc indicators on the host.
+
+
+*Response and remediation*
+
+
+- If unauthorized, isolate the host, capture forensic artifacts, and patch/harden user namespace settings as appropriate.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule relies on Auditd Manager (or Auditbeat) process telemetry that captures:
+
+- Process execution events (execve/execveat) to populate process.name, process.args, and process.parent.pid
+- Namespace-related activity to populate auditd.data.syscall, auditd.data.class, and auditd.data.a0 for unshare calls
+- Privilege transitions so processes started as root can be correlated after the namespace action
+
+Ensure your auditd ruleset includes coverage for unshare and exec-related syscalls and that arguments are collected. If
+your environment does not populate auditd.data.class/a0 for unshare, keep the process-based fallback branch (process.name
+== unshare with -U/--user/-r args) enabled and consider extending auditing to enrich those auditd.data fields.
+
+
+*Example auditd rules*
+
+
+The following example syscall rules are commonly used to capture the signals required by this detection. Adjust keys and
+scope to your environment (these examples are intentionally broad).
+
+- Capture unshare (namespace activity):
+  -a always,exit -F arch=b64 -S unshare -k namespace
+  -a always,exit -F arch=b32 -S unshare -k namespace
+
+- Capture process execution (argv collection depends on your auditd/auditbeat pipeline configuration):
+  -a always,exit -F arch=b64 -S execve -S execveat -k exec
+  -a always,exit -F arch=b32 -S execve -S execveat -k exec
+
+- Capture UID transition syscalls often associated with privilege changes:
+  -a always,exit -F arch=b64 -S setuid -S setreuid -S setresuid -S setfsuid -k uid_change
+  -a always,exit -F arch=b32 -S setuid -S setreuid -S setresuid -S setfsuid -k uid_change
+
+See https://docs.elastic.co/integrations/auditd_manager
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by host.id, process.parent.pid with maxspan=30s
+ [process where host.os.type == "linux" and 
+  (
+   (auditd.data.syscall == "unshare" and auditd.data.class == "namespace" and auditd.data.a0 in ("10000000", "50000000", "70000000", "10020000", "50020000", "70020000")) or 
+
+   (process.name == "unshare" and  
+    (process.args in ("--user", "--map-root-user", "--map-current-user") or process.args like ("-*U*", "-*r*")))
+   ) and user.id != "0" and user.id != null]
+ [process where host.os.type == "linux" and 
+  user.id == "0" and user.id != null and 
+  (
+   process.name in ("su", "sudo", "pkexec", "passwd", "chsh", "newgrp", "doas", "run0", "sg", "dash", "sh", "bash", "zsh", "fish", 
+                    "ksh", "csh", "tcsh", "ash", "mksh", "busybox", "rbash", "rzsh", "rksh", "tmux", "screen", "node") or 
+   process.name like ("python*", "perl*", "ruby*", "php*", "lua*")
+  )]
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc
new file mode 100644
index 0000000000..5e8f5b7ddb
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc
@@ -0,0 +1,170 @@
+[[prebuilt-rule-8-19-24-potential-privileged-escalation-via-samaccountname-spoofing]]
+=== Potential Privileged Escalation via SamAccountName Spoofing
+
+Identifies a suspicious computer account name rename event, which may indicate an attempt to exploit CVE-2021-42278 to elevate privileges from a standard domain user to a user with domain admin privileges. CVE-2021-42278 is a security vulnerability that allows potential attackers to impersonate a domain controller via samAccountName attribute spoofing.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://support.microsoft.com/en-us/topic/kb5008102-active-directory-security-accounts-manager-hardening-changes-cve-2021-42278-5975b463-4c95-45e1-831a-d120004e258e
+* https://cloudbrothers.info/en/exploit-kerberos-samaccountname-spoofing/
+* https://github.com/cube0x0/noPac
+* https://twitter.com/exploitph/status/1469157138928914432
+* https://exploit.ph/cve-2021-42287-cve-2021-42278-weaponisation.html
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Use Case: Active Directory Monitoring
+* Data Source: Active Directory
+* Use Case: Vulnerability
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 216
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Privileged Escalation via SamAccountName Spoofing*
+
+
+
+*Possible investigation steps*
+
+
+- What computer-account rename did the alert capture?
+  - Focus: `winlog.event_data.OldTargetUserName`, `winlog.event_data.NewTargetUserName`, `winlog.event_data.TargetSid`, `winlog.event_data.TargetDomainName`, and `winlog.computer_name`.
+  - Implication: escalate when one `winlog.event_data.TargetSid` moves from a "$"-suffixed computer name to a name matching or imitating the logging controller or another controller-style identity; lower concern only when the object, names, domain, and controller match a lab or patch-validation object.
+
+- Which account and session initiated the rename?
+  - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, `winlog.event_data.SubjectLogonId`, and `user.id`.
+  - Hint: modifying-session authentication events. !{investigate{"description":"","label":"Authentication events for the modifying session","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate when the modifier is a standard user, non-tier-0 administrator, unexpected service account, or session unrelated to directory management; lower concern only when the SID, account, domain, and logon session match the same recognized test or repair workflow.
+
+- Was the same object restored or prepared with surrounding directory changes?
+  - Why: rename-back on the same object after ticket activity is common noPac-style tradecraft.
+  - Focus: follow-on account-management or directory-change events for `winlog.event_data.TargetSid`, `winlog.event_data.OldTargetUserName`, `winlog.event_data.NewTargetUserName`, `winlog.event_data.AttributeLDAPDisplayName`, and `winlog.event_data.AttributeValue`.
+  - Hint: look for sAMAccountName rewrites, authentication-related attribute changes, and a final return to the expected "$"-suffixed name.
+  - Implication: escalate when the object is restored after suspicious ticket activity, renamed repeatedly, or has authentication-related attribute changes around the rename; lower concern only when the restore is prompt, complete, and tied to the same recognized test or repair workflow.
+
+- Did the spoofed identity request Kerberos tickets or log on after the rename?
+  - Focus: Windows Security authentication events for the spoofed name, especially `winlog.event_data.TargetUserName`, `event.code`, `winlog.event_data.AuthenticationPackageName`, `source.ip`, and `winlog.computer_name`.
+  - Hint: use the alert `@timestamp`, `winlog.computer_name`, and `winlog.event_data.NewTargetUserName` to scope authentication review. !{investigate{"description":"","label":"Authentication events for the spoofed name","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4768","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetUserName","queryType":"phrase","value":"{{winlog.event_data.NewTargetUserName}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4769","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetUserName","queryType":"phrase","value":"{{winlog.event_data.NewTargetUserName}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetUserName","queryType":"phrase","value":"{{winlog.event_data.NewTargetUserName}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} Missing Kerberos or logon coverage is unresolved, not benign.
+  - Implication: escalate when the new name requests Kerberos tickets, authenticates from an unexpected `source.ip`, or appears in privileged access flows; lack of follow-on use lowers concern only when rename and restore evidence fit one confirmed benign workflow.
+
+- If local evidence is suspicious or unresolved, does the same modifier or object appear in related directory abuse?
+  - Focus: related Windows Security events or alerts for the same `winlog.event_data.SubjectUserSid` and `winlog.event_data.TargetSid`, especially Active Directory manipulation, Kerberos abuse, credential access, or privilege-escalation activity.
+  - Hint: modifier-SID related events. !{investigate{"description":"","label":"Events associated with the modifying account","providers":[[{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: renamed-object related events. !{investigate{"description":"","label":"Events associated with the renamed object","providers":[[{"excluded":false,"field":"winlog.event_data.TargetSid","queryType":"phrase","value":"{{winlog.event_data.TargetSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when either SID appears in related directory or privilege-abuse activity; keep localized only when related scope is clean and local evidence supports a confirmed benign workflow.
+
+- Escalate for unauthorized privileged-name spoofing, ticket use, suspicious modifier/session origin, same-object restore, directory-change setup, or related abuse; close only when all evidence binds the rename to one confirmed test or repair workflow with no contradictory Kerberos, directory-change, or related findings; preserve rename and authentication evidence and escalate when visibility is incomplete or findings conflict.
+
+
+*False positive analysis*
+
+
+- Controlled CVE-2021-42278 testing, patch validation, and rare tier-0 directory repair are the realistic benign paths. Confirm that `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectLogonId`, `winlog.event_data.TargetSid`, old/new names, and `winlog.computer_name` match one test or repair path; the same `winlog.event_data.TargetSid` is restored to the expected "$"-suffixed name; and Kerberos/logon events show no spoofed-name use outside that path. Without workflow records or owner confirmation, keep unresolved rather than closing on telemetry shape alone. If the target name, modifier, restore behavior, or follow-on usage drifts, do not close as benign.
+- Before creating an exception, validate that the same subject SID, target SID, old/new names, controller, restore sequence, and no-spoofed-authentication pattern recur across prior alerts from this rule after a benign workflow has been confirmed. Build the exception from that minimum workflow pattern, not `event.action`, `winlog.event_data.NewTargetUserName`, or `winlog.event_data.TargetSid` alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, preserve the evidence set that proved the workflow, then reverse any temporary containment and document the exact subject SID, target SID, old/new name sequence, controller, restore sequence, and follow-on authentication pattern. Create an exception only after the same workflow pattern recurs across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve the alert document, Windows Security rename event, related account-management and directory-change events, Kerberos/logon events for the spoofed name, and related pivots before altering the object. Apply reversible containment only after weighing AD service impact with AD owners, such as temporarily disabling the renamed computer account or restoring the original sAMAccountName after evidence capture.
+- If confirmed malicious, preserve the same rename, controller, directory-change, Kerberos, and source-origin evidence first, then disable the renamed computer object or restore its original sAMAccountName, reset the machine-account secret or re-establish the expected trust path, and contain the modifying account and suspected source host. Escalate to broader account or host containment when ticket use, rename-back staging, or related privilege abuse shows active exploitation.
+- Before destructive cleanup or final object restoration, review the same `winlog.event_data.SubjectUserSid` and `winlog.event_data.TargetSid` across domain-controller Security logs for additional renames, spoofed-name authentication, or related directory abuse so scope is known before evidence changes.
+- If the spoofed identity obtained privileged tickets or was used for directory replication, treat the case as potential domain compromise: review issued Kerberos tickets, reset exposed accounts according to ticket and access evidence, and coordinate domain-recovery actions such as krbtgt rotation only when ticket abuse or replication access is confirmed.
+- Post-incident hardening: patch domain controllers for CVE-2021-42278 and related Kerberos fixes, retain account-management, directory-change, and Kerberos auditing on controllers, and record the final subject SID / target SID / old-new name / restore / follow-on-authentication pattern for future triage.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Audit User Account Management must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-user-account-management
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+iam where host.os.type == "windows" and event.action == "renamed-user-account" and
+  /* machine account name renamed to user like account name */
+  winlog.event_data.OldTargetUserName : "*$" and not winlog.event_data.NewTargetUserName : "*$"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Exploitation for Privilege Escalation
+** ID: T1068
+** Reference URL: https://attack.mitre.org/techniques/T1068/
+* Technique:
+** Name: 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/
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Masquerading
+** ID: T1036
+** Reference URL: https://attack.mitre.org/techniques/T1036/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-ransomware-note-file-dropped-via-smb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-ransomware-note-file-dropped-via-smb.asciidoc
new file mode 100644
index 0000000000..16af649bb0
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-ransomware-note-file-dropped-via-smb.asciidoc
@@ -0,0 +1,165 @@
+[[prebuilt-rule-8-19-24-potential-ransomware-note-file-dropped-via-smb]]
+=== Potential Ransomware Note File Dropped via SMB
+
+Identifies an incoming SMB connection followed by the creation of a file with a name similar to ransomware note files. This may indicate a remote ransomware attack via the SMB protocol.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.file-*
+* logs-endpoint.events.network-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Impact
+* Resources: Investigation Guide
+* Data Source: Elastic Defend
+
+*Version*: 8
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Ransomware Note File Dropped via SMB*
+
+
+
+*Possible investigation steps*
+
+
+- What do the sequence member events show about the accepted SMB session and note-file burst?
+  - Why: this sequence can omit stage-specific values from the combined alert; disposition depends on recovered source events.
+  - Focus: Timeline member events: network-stage `source.ip`, then file-stage `user.id`, `file.path`, `file.name`, and `file.extension`.
+  - Implication: escalate when one remote source is followed within one second by repeated note-like creations under user-profile paths; lower concern only when recovered source, identity, names, and paths form one bounded, neutral file-copy pattern for validation.
+  - Hint: `process.pid` value "4" is target-side kernel SMB I/O, not the remote executable; use `user.name` only as a readable label for the file-stage identity.
+
+- Do recovered `source.ip` and writing identity match a stable SMB pattern for this host?
+  - Why: the target-side kernel process does not identify the remote operator; source and SMB identity carry attribution value.
+  - Focus: surrounding and historical SMB "connection_accepted" events for `host.id` and recovered `source.ip`, plus file-stage `user.id` and `user.name`. !{investigate{"description":"","label":"SMB connection events on the host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"event.action","queryType":"phrase","value":"connection_accepted","valueType":"string"},{"excluded":false,"field":"destination.port","queryType":"phrase","value":"445","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the source is new for this host, appears only in a short burst, or pairs with an unusual SMB identity; lower concern when the same source and identity recur as one bounded backup, migration, or maintenance pattern. Missing SMB history is unresolved, not benign.
+
+- Do created files indicate broad ransom-note staging rather than routine instructions?
+  - Focus: recovered `file.path`, `file.name`, `file.extension`, `file.size`, and `file.Ext.header_bytes`; repeated names across multiple "C:\Users\" profile paths.
+  - Implication: escalate when identical or near-identical note files land in multiple profiles, use ".hta" or HTML variants, or are small text/HTML artifacts meant for user visibility; lower concern when files stay in one bounded application or migration folder and match stable instruction-file naming for the same source.
+
+- Does same-window SMB file activity show broader destructive or staging behavior?
+  - Why: note drops often accompany remote rename, delete, or other drop activity that this rule does not capture directly.
+  - Focus: file events in the same SMB window: `event.action`, `file.path`, `file.extension`, `file.Ext.original.path`, and `file.Ext.original.extension`. !{investigate{"description":"","label":"File events for SMB server writes on this host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the same window shows mass rename, delete, extension-change, or extra drop behavior in user or shared paths; lower concern when activity stays limited to the small note set with no follow-on churn.
+
+- If local SMB evidence remains suspicious or unresolved, does impact context stay local or show source fan-out?
+  - Why: ransomware may place notes apart from encryption or recovery inhibition, and SMB ransomware can fan out with valid accounts or admin shares.
+  - Focus: same-host impact alerts over 48 hours, then other SMB events keyed by recovered `source.ip` with matching note-like `file.name`, `file.path`, or impact `event.action`. !{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: escalate when the host shows rename, shadow-copy, backup-tamper, or destructive alerts, or when one source fans out to multiple hosts with matching note-drop or impact signals; keep the case local only when the source is confined to one bounded file-copy pattern. Missing cross-host SMB telemetry is unresolved, not benign.
+  - Hint: start with `source.ip` plus `destination.port` 445, then join returned hosts to note-like file creations by time.
+
+- What disposition do the recovered SMB source, identity, note pattern, file churn, and scope support?
+  - Escalate for remote note staging plus unexpected SMB identity, destructive file activity, recovery inhibition, or multi-host spread; close only for one stable bounded file-copy pattern with neutral names and no contradictory impact evidence; if purpose still depends on records, preserve artifacts until telemetry resolves it.
+
+
+*False positive analysis*
+
+
+- Bulk backup, migration, or endpoint-management jobs can place repeated text or HTML instruction files over SMB. Confirm the same recovered `source.ip`, `user.id`, `user.name`, neutral `file.name` family, and bounded `file.path` recurs for this `host.id` without rename, delete, shadow-copy, backup-tamper, or cross-host note-drop spread. Change records can corroborate, not replace, telemetry alignment.
+- Case-driven incident response, legal-hold, or notification activity can write readme-style files remotely. Confirm recovered `source.ip`, `user.id`, `user.name`, `file.path`, and `file.extension` stay bounded to intended case or communication folders, use neutral notice/readme naming rather than decrypt, recover, lock, or payment language, and do not coincide with broader rename or delete activity from `process.pid` value "4". If case records are unavailable, require recurrence of the same source, identity, and path family without spread.
+- Before creating an exception, validate recurrence across prior alerts from this rule. Build the exception from the minimum pattern: recovered `source.ip`, `user.id` or `user.name`, representative `file.name`, bounded `file.path` family, and affected host cohort. Avoid exceptions on `file.name`, `host.id`, or `process.pid` alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and record the confirmed `source.ip`, `user.id` or `user.name`, representative `file.name`, and bounded `file.path` pattern. Create an exception only after that same pattern recurs consistently across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve the alert, Timeline member-event export, copies or hashes of representative note files, recovered source and user identifiers, surrounding file-action evidence, and same-host alert identifiers before containment. Apply reversible containment first, such as temporarily blocking SMB from the recovered source to the target or restricting the recovered user for SMB access. Use host isolation only if note drops continue, spread to additional hosts, or the target role can tolerate interruption.
+- If confirmed malicious, isolate the recovered source host when it is managed and the source, SMB identity, note-file pattern, and impact evidence confirm active ransomware behavior. If direct endpoint response is unavailable on the source, hand off the preserved artifacts to the team that can block the SMB path or contain the source system. Before deleting files, terminating processes, or restoring data, export the member events, related impact alerts, note files, and affected host list.
+- After confirmed malicious scoping identifies affected hosts and accounts, rotate or reset the SMB credentials that were used or exposed, review other hosts touched by the same recovered `source.ip`, then remove dropped notes and restore affected data from known-good backups.
+- Post-incident hardening: restrict unnecessary SMB administrative access, protect backup and shadow-copy workflows, retain endpoint network and file telemetry needed to reconstruct remote file activity, and record the confirmed benign workflow or malicious source-and-path pattern for future cases.
+
+
+==== 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=1s
+ [network where host.os.type == "windows" and
+  event.action == "connection_accepted" and destination.port == 445 and source.port >= 49152 and process.pid == 4 and
+  source.ip != "127.0.0.1" and source.ip != "::1" and
+  network.type == "ipv4" and not endswith(source.address, destination.address)]
+ [file where host.os.type == "windows" and event.action == "creation" and
+  process.pid == 4 and user.id : ("S-1-5-21*", "S-1-12-*") and file.extension : ("hta", "txt", "readme", "htm*") and
+  file.path : "C:\\Users\\*" and
+   /* ransom file name keywords */
+    file.name : ("*read*me*", "*lock*", "*@*", "*RECOVER*", "*decrypt*", "*restore*file*", "*FILES_BACK*", "*how*to*")] with runs=3
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Data Destruction
+** ID: T1485
+** Reference URL: https://attack.mitre.org/techniques/T1485/
+* Technique:
+** Name: Data Encrypted for Impact
+** ID: T1486
+** Reference URL: https://attack.mitre.org/techniques/T1486/
+* Technique:
+** Name: Inhibit System Recovery
+** ID: T1490
+** Reference URL: https://attack.mitre.org/techniques/T1490/
+* Tactic:
+** Name: Lateral Movement
+** ID: TA0008
+** Reference URL: https://attack.mitre.org/tactics/TA0008/
+* Technique:
+** Name: Remote Services
+** ID: T1021
+** Reference URL: https://attack.mitre.org/techniques/T1021/
+* Sub-technique:
+** Name: SMB/Windows Admin Shares
+** ID: T1021.002
+** Reference URL: https://attack.mitre.org/techniques/T1021/002/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-remote-desktop-shadowing-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-remote-desktop-shadowing-activity.asciidoc
new file mode 100644
index 0000000000..7f74218f7d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-remote-desktop-shadowing-activity.asciidoc
@@ -0,0 +1,199 @@
+[[prebuilt-rule-8-19-24-potential-remote-desktop-shadowing-activity]]
+=== Potential Remote Desktop Shadowing Activity
+
+Identifies the modification of the Remote Desktop Protocol (RDP) Shadow registry or the execution of processes indicative of an active RDP shadowing session. An adversary may abuse the RDP Shadowing feature to spy on or control other users active RDP sessions.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process-*
+* logs-endpoint.events.registry-*
+* winlogbeat-*
+* logs-windows.sysmon_operational-*
+* endgame-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://blog.bitsadmin.com/spying-on-users-using-rdp-shadowing
+* https://swarm.ptsecurity.com/remote-desktop-services-shadowing/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Lateral Movement
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Microsoft Defender XDR
+* Data Source: SentinelOne
+* Resources: Investigation Guide
+
+*Version*: 316
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Remote Desktop Shadowing Activity*
+
+
+
+*Possible investigation steps*
+
+
+- Which RDP shadowing path fired?
+  - Focus: `event.category`, `process.name`, `process.command_line`, `registry.path`, `registry.data.strings`.
+  - Implication: escalate faster for active "mstsc.exe /shadow" use or a `Shadow` policy value that removes consent; lower suspicion only when alert-local evidence matches recognized helpdesk, training, or policy-setting activity with consent retained.
+- Do process identity and lineage fit RDP shadowing components?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.command_line`.
+  - Hint: for registry alerts, recover same-process starts for lineage or command-line detail. !{investigate{"description":"","label":"Process events for the same process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when "mstsc.exe", "RdpSaUacHelper.exe", or "RdpSaProxy.exe" runs from a user-writable path, has an unexpected signer, or has a parent inconsistent with Remote Desktop Services or a support launcher. A trusted Microsoft binary confirms identity, not authorization.
+- If the `Shadow` registry value fired, did the new setting remove consent or allow control?
+  - Focus: `registry.path`, `registry.data.strings` (decimal or hex: `1`/`0x00000001` = full control with consent, `2`/`0x00000002` = full control without consent, `3`/`0x00000003` = view only with consent, `4`/`0x00000004` = view only without consent), and `process.executable`.
+  - Implication: escalate when `registry.data.strings` is `2`/`0x00000002` (full control, no consent) or `4`/`0x00000004` (view, no consent) because these allow silent shadowing; treat `1`/`0x00000001` or `3`/`0x00000003` as weaker setup evidence because the user is prompted, unless active shadowing or unexplained lineage appears.
+- If a process event fired, does it show active session shadowing?
+  - Focus: `process.name`, `process.command_line`, `process.parent.name`, `process.parent.executable`.
+  - Hint: if `process.command_line` is truncated or normalized, verify "/shadow", "/control", and "/noConsentPrompt" boundaries with `process.args` before lowering suspicion.
+  - Implication: escalate when "mstsc.exe" includes "/shadow" with "/control" or "/noConsentPrompt". Treat "RdpSaUacHelper.exe" or "RdpSaProxy.exe" under a service host as active target-side shadowing that escalates when paired with no-consent/control, unexplained lineage, or unrecognized user-host context; a plain "mstsc.exe" launch without shadowing arguments is not enough.
+- Does user, host, and session context fit recognized support or training?
+  - Focus: `user.id`, `user.name`, `user.domain`, `host.id`, `process.Ext.session_info.logon_type`.
+  - Implication: escalate when `user.id` targets an unusual workstation, privileged session, or host with no matching shadow-support pattern; lower suspicion only when user-host pairing, session type, and branch evidence match the same recognized workflow.
+- Did the same actor prepare, persist, or extend the host-side shadowing activity?
+  - Focus: `user.id`, `process.entity_id`, `process.command_line`, `registry.path`, `registry.data.strings`.
+  - Hint: start with recovered same-process events; expand to same-host process and registry events only when local capability or context remains suspicious. !{investigate{"description":"","label":"Registry events on the host near the alert","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the same user or lineage enumerates sessions, prepares alternate-token launch, changes Terminal Services or RDP state, launches admin tooling, or persists shadow settings; absent process or registry evidence narrows the case but does not clear the alert.
+- If local findings stay suspicious or unresolved, do related alerts expand scope?
+  - Focus: related alerts for the same `user.id` and `host.id`, especially remote-access, credential, remote-service, and persistence alerts.
+  - Hint: review same-user alerts when local branch and capability questions remain suspicious. !{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: review same-host alerts when host preparation or follow-on activity remains unresolved. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when related alerts show the same user or host in remote-access, credential, or persistence activity; keep scope narrow only when local evidence fits a recognized workflow and related alerts do not contradict it.
+
+- Using branch, capability, identity, lineage, user-host fit, host-side activity, and related alerts, escalate unauthorized no-consent/control shadowing or stealthy policy relaxation; close only when evidence binds to one recognized support, training, or policy workflow with no contradictions; if mixed or incomplete, preserve process and registry artifacts and escalate.
+
+
+*False positive analysis*
+
+
+- Helpdesk support, training labs, and supervised administration can legitimately use "mstsc.exe /shadow" or target-side "RdpSa*" helpers. Confirm `process.command_line`, `process.name`, `process.parent.name`, `user.id`, `host.id`, and any `Shadow` value align with the same authorized workflow, without contradictory `process.command_line` or `registry.path` evidence. Without ticketing or support rosters, require telemetry-only recurrence of the same command pattern, user-host pairing, consent mode, and quiet follow-on profile before closing as benign.
+- Group Policy or endpoint management tooling can legitimately change `Shadow`. Confirm stable `process.executable`, `process.code_signature.subject_name`, `process.parent.command_line`, exact `registry.path`, and resulting `registry.data.strings` match the host class. Without change records or GPO inventories, require quiet recurrence of the same process and registry pattern for the same management scope before closing.
+- Before creating an exception, anchor it on the minimum confirmed workflow: `event.category`, exact `process.command_line` or `registry.path`, `registry.data.strings`, `user.id`, and `host.id`. Avoid exceptions on `process.name`, `registry.value`, or `Shadow` alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and document the exact `event.category`, `process.command_line` or `registry.path`, `registry.data.strings`, `user.id`, and `host.id` that proved the support, training, or policy workflow. Create an exception only after the same narrow pattern recurs.
+- If suspicious but unconfirmed, preserve a case export with the process tree, `process.entity_id`, `process.command_line`, `process.parent.command_line`, `registry.path`, `registry.value`, `registry.data.strings`, affected `user.id`, affected `host.id`, and surrounding preparation or follow-on evidence before changing host state.
+- Apply reversible containment next: restore the `Shadow` policy to the pre-change value, disable shadowing with `0`, require consent with `1` or `3`, or restrict the involved account on the affected `host.id`. Escalate to host isolation only when shadowing is part of broader session abuse and the host role can tolerate isolation.
+- If confirmed malicious, isolate the host when feasible, then terminate active "mstsc.exe" or "RdpSa*" shadowing processes after recording their process identifiers and command lines. Revert unauthorized `Shadow` and related Terminal Services or RDP shadow permission changes after preservation.
+- Scope other hosts and users tied to the same `user.id`, `process.command_line`, `registry.path`, or `registry.data.strings` before removing artifacts or resetting access.
+- Remove malicious helper scripts or tooling found during scoping, revert unauthorized RDP service or policy changes, and reset credentials that may have been exposed in the shadowed session.
+- Post-incident hardening: keep `Shadow` at the least permissive accepted setting, restrict who can shadow sessions, review RDP-Tcp shadow permissions, and retain process and registry telemetry needed to distinguish support use from no-consent shadowing.
+
+==== 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/sysmon-event-reg-setup[Sysmon Registry Events]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+/* Identifies the modification of RDP Shadow registry or
+  the execution of processes indicative of active shadow RDP session */
+
+any where host.os.type == "windows" and
+(
+  (event.category == "registry" and event.type == "change" and
+    registry.value : "Shadow" and
+    registry.path : (
+      "*\\Software\\Policies\\Microsoft\\Windows NT\\Terminal Services\\Shadow"
+    ) and
+    registry.data.strings : ("1", "0x00000001", "2", "0x00000002", "3", "0x00000003", "4", "0x00000004")
+
+  ) or
+  (event.category == "process" and event.type == "start" and
+    (
+      (process.name : ("RdpSaUacHelper.exe", "RdpSaProxy.exe") and process.parent.name : "svchost.exe") or
+      (?process.pe.original_file_name : "mstsc.exe" and process.args : "/shadow:*")
+    )
+  )
+)
+
+----------------------------------
+
+*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: Remote Desktop Protocol
+** ID: T1021.001
+** Reference URL: https://attack.mitre.org/techniques/T1021/001/
+* Technique:
+** Name: Remote Service Session Hijacking
+** ID: T1563
+** Reference URL: https://attack.mitre.org/techniques/T1563/
+* Sub-technique:
+** Name: RDP Hijacking
+** ID: T1563.002
+** Reference URL: https://attack.mitre.org/techniques/T1563/002/
+* Tactic:
+** Name: Collection
+** ID: TA0009
+** Reference URL: https://attack.mitre.org/tactics/TA0009/
+* Technique:
+** Name: Screen Capture
+** ID: T1113
+** Reference URL: https://attack.mitre.org/techniques/T1113/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-reverse-shell-via-java.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-reverse-shell-via-java.asciidoc
new file mode 100644
index 0000000000..267df9c09f
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-reverse-shell-via-java.asciidoc
@@ -0,0 +1,189 @@
+[[prebuilt-rule-8-19-24-potential-reverse-shell-via-java]]
+=== Potential Reverse Shell via Java
+
+This detection rule identifies the execution of a Linux shell process from a Java JAR application post an incoming network connection. This behavior may indicate reverse shell activity via a Java application.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.network*
+* 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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Execution
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 14
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Potential Reverse Shell via Java*
+
+
+Java applications, often run on Linux systems, can be exploited by adversaries to establish reverse shells, allowing remote control over a compromised system. Attackers may execute shell commands via Java processes post-network connection. The detection rule identifies suspicious Java activity by monitoring for shell executions following network connections, excluding benign processes, to flag potential reverse shell attempts.
+
+
+*Possible investigation steps*
+
+
+- Review the network connection details, focusing on the destination IP address to determine if it is external or potentially malicious, as the rule excludes common internal and reserved IP ranges.
+- Examine the Java process that initiated the network connection, including its executable path and arguments, to identify any unusual or unauthorized JAR files being executed.
+- Investigate the child shell process spawned by the Java application, checking its command-line arguments and execution context to assess if it aligns with known reverse shell patterns.
+- Cross-reference the parent Java process and the child shell process with known benign applications or services, such as Jenkins or NetExtender, to rule out false positives.
+- Analyze historical data for the host to identify any previous similar activities or patterns that might indicate a persistent threat or repeated exploitation attempts.
+
+
+*False positive analysis*
+
+
+- Java-based administrative tools like Jenkins may trigger false positives when executing shell commands. Exclude known benign Java applications such as Jenkins by adding their specific JAR paths to the exception list.
+- Automated scripts or maintenance tasks that use Java to execute shell commands can be mistaken for reverse shell activity. Identify and exclude these scripts by specifying their unique process arguments or executable paths.
+- Development environments where Java applications frequently execute shell commands for testing purposes can generate false alerts. Consider excluding these environments by filtering based on specific host identifiers or network segments.
+- Security tools that utilize Java for network operations and shell executions might be flagged. Verify and exclude these tools by adding their process names or executable paths to the exception list.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious Java processes identified in the alert to stop potential reverse shell activity.
+- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or lateral movement attempts.
+- Remove any unauthorized or malicious Java JAR files and associated scripts from the system.
+- Apply security patches and updates to the Java environment and any other vulnerable software on the affected host.
+- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from Elastic Defend.
+
+
+*Elastic Defend Integration Setup*
+
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+
+
+*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide].
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide].
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by host.id with maxspan=5s
+  [network where host.os.type == "linux" and event.action in ("connection_accepted", "connection_attempted") and
+   process.executable : ("/usr/bin/java", "/bin/java", "/usr/lib/jvm/*", "/usr/java/*") and
+   not (destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch(
+     destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
+     "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
+     "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10",
+     "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
+     "FF00::/8"
+    )
+  )] by process.entity_id
+  [process where host.os.type == "linux" and event.action == "exec" and
+   process.parent.executable : ("/usr/bin/java", "/bin/java", "/usr/lib/jvm/*", "/usr/java/*") and
+   process.parent.args : "-jar" and process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
+   and not (
+     process.parent.args in (
+       "/usr/lib/jenkins/jenkins.war", "/etc/remote-iot/services/remoteiot.jar", "/opt/pentaho/data-integration/launcher/launcher.jar",
+       "/usr/share/java/jenkins.war", "/opt/tomcat/statistics/statistics.jar", "/usr/lib64/NetExtender.jar",
+       "/var/lib/jenkins/workspace/MP-QA/tc_certified_copy*/tc_certified_copy_web_ui_test/target/surefire/surefirebooter*.jar",
+       "-javaagent:/opt/opentelemetry/opentelemetry-javaagent-all.jar", "./lib/pipeline-job-executor*SNAPSHOT.jar",
+       "./lib/worker-launcher-agent*SNAPSHOT.jar", "/opt/Seqrite_EndPoint_Security/wildfly/jboss-modules.jar",
+       "/home/data/jenkins.war", "/pro/service-modules/deployment.jar", "/application/HES/READER/*.jar", "*-SNAPSHOT.jar",
+       "READER/G1A/READER_G1A.jar", "READER_G1.jar"
+     ) or
+    process.command_line like~ (
+      "bash -c ps -eo pid,lstart,comm*",
+      "bash -c df -i /application | tail -n 1",
+      "/bin/sh -xe /tmp/hudson*.sh",
+      "bash -c cat /application/HES/*"
+    )
+   )] by process.parent.entity_id
+
+----------------------------------
+
+*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: 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-sharprdp-behavior.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-sharprdp-behavior.asciidoc
new file mode 100644
index 0000000000..2712b7cbab
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-sharprdp-behavior.asciidoc
@@ -0,0 +1,173 @@
+[[prebuilt-rule-8-19-24-potential-sharprdp-behavior]]
+=== Potential SharpRDP Behavior
+
+Identifies potential behavior of SharpRDP, which is a tool that can be used to perform authenticated command execution against a remote target via Remote Desktop Protocol (RDP) for the purposes of lateral movement.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process-*
+* logs-endpoint.events.registry-*
+* logs-endpoint.events.network-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://posts.specterops.io/revisiting-remote-desktop-lateral-movement-8fb905cb46c3
+* https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES/blob/master/Lateral%20Movement/LM_sysmon_3_12_13_1_SharpRDP.evtx
+* 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
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 113
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential SharpRDP Behavior*
+
+
+
+*Possible investigation steps*
+
+
+- Do Timeline source events form one target-side SharpRDP chain?
+  - Focus: same-`host.id` events: inbound `source.ip`, RunMRU `registry.data.strings`, child `process.parent.name`, and child `process.command_line`.
+  - Hint: record the RunMRU time and child `process.entity_id`; the sequence alert may not preserve stage-specific process or registry fields.
+  - Implication: suspicious when non-loopback RDP to port 3389 is followed by a RunMRU shell, Task Manager, or "\\tsclient\" command and child execution; lower suspicion only when all recovered members fit one recognized interactive RDP maintenance action. Missing member events are unresolved, not benign.
+- Which RunMRU method launched execution?
+  - Focus: RunMRU `registry.path`, `registry.data.strings`, child `process.parent.name`, and child `process.command_line`.
+  - Implication: escalate when the RunMRU data selects a shell, Task Manager, or "\\tsclient\" mapped-drive payload and the child process matches that method; normal Run-dialog use is lower risk only when it launches a bounded support utility or installer without shell staging.
+- Does the source and user context fit legitimate RDP use on this target?
+  - Focus: inbound `source.ip`, launched-process `user.id`, and `user.name`.
+  - Implication: escalate when an unusual source uses an end-user or privileged account to start shells, Task Manager, or mapped-drive binaries over RDP; treat a recognized source-user pairing as context only until the RunMRU command and child identity also match the exact RDP task.
+- What ran on the target, and does its identity fit the expected RDP workflow?
+  - Focus: child `process.executable`, `process.command_line`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the command stages scripts, remote-admin tooling, credential access, or unsigned/user-writable payloads; lower suspicion only when binary identity and command line match the same bounded support or deployment workflow. A trusted signer does not clear suspicious command intent.
+- Did the launched child or its descendants create follow-on activity?
+  - Focus: same-host endpoint events scoped to recovered child `process.entity_id`: descendant `process.parent.entity_id`, persistence `registry.path`, DNS-event `dns.question.name`, and connection-event `destination.ip`.
+  - Hint: query process and registry events tied to the child ID; review DNS and connection events separately because `dns.question.name` and `destination.ip` live on different network event subtypes.
+  - Implication: escalate when descendants, registry changes, DNS lookups, or outbound connections show staging, persistence, command-and-control, or more lateral movement; absence of process-scoped DNS or connection telemetry narrows the case only when other evidence is clean. Missing network telemetry is unresolved, not benign.
+- Do related target-host alerts change scope?
+  - Focus: related RDP, remote-service, credential, and execution alerts for the same `host.id`. !{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"}}
+  - Hint: if recovered `source.ip` maps to an enrolled internal asset, follow up on outbound RDP to `destination.port` 3389 from a non-standard RDP client; missing source-host telemetry is unresolved, not benign.
+  - Implication: broaden scope when target-host alerts or caveated source-host follow-up show lateral movement beyond one recovered session; keep local only when the suspicious pattern stays confined to this target and the recovered source workflow is otherwise clean.
+- Using RDP source, RunMRU command, child lineage and identity, user context, follow-on process/registry/network evidence, and related alerts, escalate RDP-driven command execution or "\\tsclient\" payload launch without a coherent benign workflow; close only when all categories align to one exact recognized RDP workflow and no contradictory host or source evidence remains; preserve artifacts and escalate when evidence is mixed or visibility is incomplete.
+
+
+*False positive analysis*
+
+
+- Helpdesk or administrator RDP support can trigger when an operator uses Win+R, Task Manager, or a mapped drive to launch a diagnostic or installer. Confirm `source.ip`, `host.id`, `user.id`, `registry.data.strings`, `process.parent.name`, and `process.executable`/`process.command_line` match one task with no suspicious descendant activity. Without telemetry proof, require operator or ticket confirmation; do not close from historical pattern alone.
+- TSClient drive-redirection deployment can explain `\\tsclient\` execution only when a known installer or utility launches with stable `process.hash.sha256` or `process.code_signature.subject_name`, matching `process.parent.name`, `source.ip`, and `host.id`. Do not close if registry, DNS, connection, or descendant evidence contradicts it.
+- Before creating an exception, anchor on: `source.ip`, `host.id`, `user.id`, exact `registry.data.strings`, `process.parent.name`, and `process.executable` or `process.hash.sha256`. Avoid exceptions on `destination.port`, `process.name`, or RunMRU path alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse any temporary containment and document the exact `source.ip`, `user.id`, `registry.data.strings`, `process.executable`, and `host.id` that established the confirmed workflow. Create an exception only after the exact activity is confirmed and the exception can be pinned to the narrow workflow pattern.
+- If suspicious but unconfirmed, export the Timeline source events, capture the launched child process record and parent command line, save the RunMRU value data, and collect staged payloads, persistence key/value snapshots, DNS names, and connection destinations before containment or cleanup.
+- If suspicious but unconfirmed, after preservation apply reversible containment: end the active RDP session, temporarily restrict new RDP connections from the recovered `source.ip`, or increase monitoring on the affected `host.id`. Escalate to host isolation only when follow-on activity shows broader abuse and the host role can tolerate isolation.
+- If confirmed malicious, isolate the host when feasible, suspend or block the RDP access path or account that established the session, and terminate the launched child process plus suspicious descendants only after preserving the process and command evidence.
+- Review other hosts and users tied to the same `source.ip`, `user.id`, or distinctive `process.command_line` pattern before deleting artifacts or resetting credentials so scoping completes before evidence is destroyed.
+- Remove staged payloads, persistence changes, or follow-on tooling identified during the investigation, then reset or reissue credentials only when the process, user, and source evidence shows likely account misuse or credential exposure.
+- Post-incident hardening: restrict RDP access to controlled jump hosts, limit drive redirection where it is not required, retain process plus registry plus network telemetry on RDP targets, and document any adjacent detection gaps for the detection engineering team.
+
+
+==== 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]
+----------------------------------
+/* Incoming RDP followed by a new RunMRU string value set to cmd, powershell, taskmgr or tsclient, followed by process execution within 1m */
+
+sequence by host.id with maxspan=1m
+  [network where host.os.type == "windows" and event.type == "start" and process.name : "svchost.exe" and destination.port == 3389 and
+   network.direction : ("incoming", "ingress") and network.transport == "tcp" and
+   source.ip != "127.0.0.1" and source.ip != "::1"
+  ]
+
+  [registry where host.os.type == "windows" and event.type == "change" and process.name : "explorer.exe" and
+   registry.path : ("HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\RunMRU\\*") and
+   registry.data.strings : ("cmd.exe*", "powershell.exe*", "taskmgr*", "\\\\tsclient\\*.exe\\*")
+  ]
+
+  [process where host.os.type == "windows" and event.type == "start" and
+   (process.parent.name : ("cmd.exe", "powershell.exe", "taskmgr.exe") or process.args : ("\\\\tsclient\\*.exe")) and
+   not process.name : "conhost.exe"
+   ]
+
+----------------------------------
+
+*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: Remote Desktop Protocol
+** ID: T1021.001
+** Reference URL: https://attack.mitre.org/techniques/T1021/001/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
+* Sub-technique:
+** Name: Windows Command Shell
+** ID: T1059.003
+** Reference URL: https://attack.mitre.org/techniques/T1059/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-system-tampering-via-file-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-system-tampering-via-file-modification.asciidoc
new file mode 100644
index 0000000000..7dd910aae2
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-potential-system-tampering-via-file-modification.asciidoc
@@ -0,0 +1,175 @@
+[[prebuilt-rule-8-19-24-potential-system-tampering-via-file-modification]]
+=== Potential System Tampering via File Modification
+
+Identifies attempts to delete or modify critical files used during the boot process to prevent the system from booting. This may indicate a destructive attack behavior.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-endpoint.events.file-*
+* logs-windows.sysmon_operational-*
+* endgame-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Impact
+* Data Source: Elastic Endgame
+* Resources: Investigation Guide
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Microsoft Defender XDR
+* Data Source: SentinelOne
+
+*Version*: 5
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential System Tampering via File Modification*
+
+
+
+*Possible investigation steps*
+
+
+- Does the alert-local file event show modification or deletion of an active boot-critical file?
+  - Focus: `file.path`, `file.name`, `event.type`, `event.action`, and `process.executable`.
+  - Implication: escalate on deletion or active Windows System32, Windows Boot, or EFI boot paths for `winload.exe`, `winload.efi`, `ntoskrnl.exe`, or `bootmgr`; lower concern only when path normalization or surrounding file evidence shows repair content, not active boot content.
+- Is the modifying process consistent with servicing, repair, recovery, or rollback?
+  - Focus: same-process `process.executable`, `process.command_line`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. !{investigate{"description":"","label":"Events for the modifying process on this host","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}],[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if the transform is ambiguous or empty, recover the process start with `host.id`, `process.pid`, and alert time before judging identity.
+  - Implication: escalate when the binary is unsigned or untrusted, runs from a user-writable or unexpected path, or uses non-servicing commands; a trusted Microsoft or vendor identity lowers concern only when behavior and lineage also fit.
+- What launch chain led to the boot-file modification or deletion?
+  - Focus: same-host process lineage with `process.parent.executable` and `process.parent.command_line`.
+  - Implication: escalate when the chain includes script hosts, remote-management tooling, document launchers, or unexplained intermediaries before the write; lower concern when lineage resolves to a bounded same-host servicing or recovery workflow.
+- Does the user or service context fit legitimate maintenance?
+  - Focus: `user.id`, `user.name`, `user.domain`, and `process.Ext.session_info.logon_type`.
+  - Hint: read `process.Ext.session_info.logon_type` from the same process event used for identity.
+  - Implication: escalate when an interactive or remote user session modifies boot files directly, or when account context does not match repair duties; if session details are unavailable, do not close on user context alone.
+- Did the same process touch other boot, recovery, or protected OS files?
+  - Focus: same-process file telemetry on `host.id` and `process.entity_id`: `file.path`, `event.type`, `event.action`, and rename details for renames. !{investigate{"description":"","label":"File events for the modifying process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"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":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if the pivot is ambiguous, constrain it with `host.id`, `process.pid`, and alert time before interpreting file spread.
+  - Implication: escalate when the process modifies multiple boot-related or protected files, renames content into executable extensions, or spreads outside the original target; lower concern when activity stays bounded to the exact repair set.
+- Did the same process or host also inhibit recovery or show broader destructive behavior?
+  - Focus: surrounding process and file telemetry on `host.id`: `process.executable`, `process.command_line`, `file.path`, and `event.type` for shadow-copy, backup, boot-configuration, or WinRE changes. !{investigate{"description":"","label":"Process events on the host near the modification","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when boot-file tampering is paired with vssadmin, wbadmin, diskshadow, bcdedit, REAgentC, or wmic activity that disables recovery, deletes backups, or damages protected paths; lower concern only when this step finds no recovery-control change, backup deletion, or protected-path spread.
+- If the local findings remain suspicious or unresolved, is the pattern isolated or broader for the same host or user?
+  - Focus: related destructive or recovery-inhibition alerts for the same `host.id`: boot-file tampering, shadow-copy deletion, backup deletion, service disruption, or protected-file modification. !{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"}}
+  - Hint: if `user.id` remains relevant, compare related destructive alerts for that user separately. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate scope when the same host or user shows multiple destructive or recovery-control alerts in a short window; keep the case localized only when this is a single bounded event and local evidence resolves cleanly.
+
+- Escalate when file target, actor identity, lineage, session, protected-file spread, recovery-control, or related alerts point to unauthorized boot tampering; close only when evidence binds one recognized repair, recovery, servicing, or rollback workflow on this host with no contradictory spread; if mixed or incomplete, preserve artifacts and escalate.
+
+
+*False positive analysis*
+
+
+- Offline repair, OEM recovery, Windows servicing, administrator-led boot remediation, or security/backup rollback can replace boot files. Confirm `process.executable`, signer, command line, user or service context, `file.path`, and `event.type` bind to one recognized workflow, stay bounded to the expected repair set, and do not branch into script hosts, unusual parents, protected-file damage, shadow-copy deletion, backup deletion, or boot-configuration tampering. Without change records, require the same signed repair or rollback binary, service or recovery context, protected path family, and no destructive or recovery-control activity on the same `host.id`.
+- Before creating an exception, anchor it on the narrowest stable pattern: `process.executable`, `process.code_signature.subject_name`, `file.path`, and the expected `user.id` or service context. Do not except on `process.name`, `file.name`, or Windows-path activity alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse any temporary containment and record the repair, recovery, servicing, or rollback workflow that matched the process identity, signer, service context, and protected path set. Create an exception only after the same bounded pattern recurs.
+- If suspicious but unconfirmed, preserve the alert event, process-start record, Timeline or case export for the modifying process, boot-file metadata or available copies, recovered binary identity, lineage/session evidence, and any recovery-control or protected-file findings before containment or cleanup.
+- If suspicious but unconfirmed and the host is still online, avoid reboot until boot-file evidence is preserved. Apply reversible containment tied to the findings, such as blocking the remote administration path, disabling the active account session, or isolating the host if protected-file modification or recovery inhibition continues. Weigh host criticality before isolation.
+- If confirmed malicious, isolate the host through endpoint response when boot-file tampering, actor identity, lineage, or recovery-control evidence establishes unauthorized activity. Terminate the offending process only after preserving its entity ID, command line, affected path list, and recovered hashes. If direct response is unavailable, hand off the same evidence to the team that can isolate the host or disk.
+- Review related hosts and users for the same destructive pattern before restoring files so scoping finishes before evidence is destroyed.
+- Restore affected boot files only from trusted media, golden images, or known-good backups after destructive scope is understood, then repair any WinRE, shadow-copy, backup, or boot-configuration controls the attacker disabled.
+- Post-incident hardening: retain file and process telemetry for protected boot paths, restrict who can run repair tooling on critical systems, protect backups from the same account path, and record adjacent destructive behaviors in the case notes.
+
+==== 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]
+- https://ela.st/sysmon-event-23-setup[Sysmon Event ID 23 - File Delete]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+file where host.os.type == "windows" and event.type in ("change", "deletion") and
+  file.name : ("winload.exe", "winload.efi", "ntoskrnl.exe", "bootmgr") and
+  file.path : ("?:\\Windows\\*", "\\Device\\HarddiskVolume*\\Windows\\*") and
+  not process.executable : (
+    "?:\\Windows\\System32\\poqexec.exe",
+    "?:\\Windows\\System32\\wbengine.exe",
+    "?:\\Windows\\WinSxS\\???64_microsoft-windows-servicingstack_*\\tiworker.exe"
+  ) and
+  not file.path : (
+    "?:\\Windows\\WinSxS\\Temp\\InFlight\\*",
+    "?:\\Windows\\SoftwareDistribution\\Download*",
+    "?:\\Windows\\WinSxS\\amd64_microsoft-windows*",
+    "?:\\Windows\\SystemTemp\\*",
+    "?:\\Windows\\Temp\\????????.???\\*",
+    "?:\\Windows\\Temp\\*\\amd64_microsoft-windows-*",
+    "\\Device\\HarddiskVolume*\\Windows\\SoftwareDistribution\\Download*",
+    "?:\\Windows\\Temp\\BootImages\\{*}\\mount\\Windows\\*"
+  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Data Destruction
+** ID: T1485
+** Reference URL: https://attack.mitre.org/techniques/T1485/
+* Technique:
+** Name: Inhibit System Recovery
+** ID: T1490
+** Reference URL: https://attack.mitre.org/techniques/T1490/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-powershell-psreflect-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-powershell-psreflect-script.asciidoc
new file mode 100644
index 0000000000..ea2263239e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-powershell-psreflect-script.asciidoc
@@ -0,0 +1,164 @@
+[[prebuilt-rule-8-19-24-powershell-psreflect-script]]
+=== PowerShell PSReflect Script
+
+Detects PowerShell script block content containing PSReflect-style helper indicators, such as Add-Win32Type, New-InMemoryModule, or DllImport patterns, that may support dynamic Win32 API invocation from PowerShell.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-windows.powershell*
+* 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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/mattifestation/PSReflect/blob/master/PSReflect.psm1
+* https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Execution
+* Resources: Investigation Guide
+* Data Source: PowerShell Logs
+
+*Version*: 318
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating PowerShell PSReflect Script*
+
+
+*Possible investigation steps*
+
+
+- Does the reconstructed script block show active PSReflect native-API wiring?
+  - Why: script block logging can split one script; PSReflect is meaningful only after imports and follow-on logic are visible.
+  - Focus: reconstruct with `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`, then read `powershell.file.script_block_text` in `host.id` / `user.id` scope. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the full script defines New-InMemoryModule, Add-Win32Type, psenum, Reflection.Emit, DefineDynamicAssembly, DefineDynamicModule, or DllImportAttribute and calls wrapped APIs; lower suspicion when it is inert reference text, repository content, or a bounded lab example.
+
+- What native API objective does the script express?
+  - Focus: Imported DLL/function pairs and call sites in reconstructed `powershell.file.script_block_text`.
+  - Hint: renamed wrappers or helper-free variants can show the same behavior when DllImportAttribute, Reflection.Emit, VirtualAlloc, WriteProcessMemory, CreateRemoteThread, OpenProcessToken, or AdjustTokenPrivileges reveal native-API invocation.
+  - Implication: escalate when call sites map to memory manipulation, token or privilege changes, service tampering, registry changes, or network control; lower urgency when imports stay limited to bounded diagnostics or application interop and later evidence does not contradict that use.
+
+- If endpoint process telemetry exists, how was PowerShell launched?
+  - Why: script block events preserve deobfuscated content, not the command line or parent.
+  - Focus: Recover the matching process via `host.id + process.pid` before interpreting `process.*` or `process.parent.*`; read `process.entity_id`, `process.command_line`, `process.parent.executable`, and `process.parent.command_line`. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: expand the window if no process start appears; without process telemetry, keep later review scoped to `host.id`, `user.id`, `process.pid`, and alert time.
+  - Implication: escalate when a document, browser, chat client, remote session, scheduled task, or user-writable script path launched the helper; lower suspicion when launcher and command fit the same recognized build, admin, interop, or assessment workflow as the script.
+
+- Does script origin fit the recovered workflow?
+  - Focus: `file.path`, `file.directory`, `file.name`, missing file-origin fields, and recovered launch context.
+  - Implication: escalate when fileless on a workstation or sourced from temp, download, mounted-share, or user-writable paths that do not fit the user; lower suspicion when it resolves to a stable repository, deployment path, or test harness matching the same workflow.
+
+- Do same-host effects prove the wrapped APIs were used?
+  - Why: PSReflect is a helper pattern; the decisive follow-up is whether host activity matches the imported API family.
+  - Focus: API-matched effects: child execution for process APIs, staged payloads for write/load APIs, persistence or configuration changes for service/registry APIs, and outbound activity for network APIs. Use same-PID events around `@timestamp` to reduce PID-reuse ambiguity.
+    - !{investigate{"description":"","label":"Child process events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"File and registry events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Network events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when effects appear in recovered process scope or the `host.id`, `user.id`, `process.pid`, and time fallback scope; lower suspicion only when they align with the same bounded workflow. Missing network or endpoint effect telemetry is unresolved, not benign.
+
+- Does related alert scope change urgency?
+  - Focus: 48-hour alerts for the same `user.id` showing repeated PowerShell, execution, defense-evasion, privilege-escalation, or credential-access activity; use same-`host.id` alerts only to confirm repeated script substrings or the same imported API set.
+    - !{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 related activity shows repeated native-API abuse, follow-on execution, or spread outside the original host; keep scope local when repetition stays confined to one exact benign workflow already supported by local evidence.
+
+- What disposition is supported?
+  - Implication: escalate when content, origin, launch, effects, or scope align on injection, privilege manipulation, persistence, remote activity, or egress that does not fit the user; close only when same-host telemetry proves one exact benign workflow and no contradictory findings remain. Outside confirmation may corroborate but not replace telemetry; if mixed or incomplete, preserve artifacts and escalate.
+
+
+*False positive analysis*
+
+
+- Internal build, admin, interop, diagnostics, compatibility, or security-testing helpers can use PSReflect-style code. Confirm only when reconstructed `powershell.file.script_block_text`, imported API set, `file.path` or fileless delivery, launcher, `user.id`, `host.id`, and same-host effects all fit one bounded workflow without injection, persistence, egress, or privilege abuse. Change records, repository history, test schedules, or recurrence can support closure but not replace telemetry.
+- Before an exception, validate recurrence of the same `user.id`, `host.id`, stable `file.path` when file-backed, recovered launcher, and distinctive `powershell.file.script_block_text` substrings. Avoid exceptions on PSReflect helper strings, `user.name`, or host alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, document reconstructed script text, imported DLL/function set, origin, `user.id`, `host.id`, launch context, and same-host effect review before reversing containment. Create exceptions only for recurring workflows.
+- If suspicious but unconfirmed, preserve script block IDs/sequences, reconstructed text, API list, origin, process-start evidence, and same-host effect artifacts before response. Apply reversible containment such as destination restrictions or session limits; isolate only when corroboration shows likely injection, persistence, lateral movement, or credential misuse and the host role permits. Avoid destructive cleanup until scope is clearer.
+- If confirmed malicious, preserve the same artifacts plus related child-process, file-system, persistence, credential, and destination evidence before containment. Isolate the host and terminate PowerShell or child payloads after evidence capture; if direct response is unavailable, escalate with preserved artifacts. Block malicious scripts, payload hashes, and destinations, then review related users/hosts for the same script substrings, API set, or launch chain before eradication.
+- After containment, remove only scripts or payloads identified during investigation, undo persistence or configuration changes tied to the API objective, and remediate the delivery path or automation that launched the helper. If imports or same-host effects suggest credential theft, token abuse, or remote execution, reset affected credentials and review related auth/admin sessions before cleanup.
+- Post-incident hardening: restrict PowerShell interop and unsigned script distribution to controlled build, admin, or test systems; retain script block logging and endpoint process telemetry for `host.id + process.pid` recovery; document renamed-wrapper or helper-free reflection variants.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).
+Setup instructions: https://ela.st/powershell-logging-setup
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.category:process and host.os.type:windows and
+  powershell.file.script_block_text:(
+    "New-InMemoryModule" or
+    "Add-Win32Type" or
+    psenum or
+    DefineDynamicAssembly or
+    DefineDynamicModule or
+    "Reflection.TypeAttributes" or
+    "Reflection.Emit.OpCodes" or
+    "Reflection.Emit.CustomAttributeBuilder" or
+    "Runtime.InteropServices.DllImportAttribute"
+  ) and
+  not user.id : "S-1-5-18"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
+* Technique:
+** Name: Native API
+** ID: T1106
+** Reference URL: https://attack.mitre.org/techniques/T1106/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-privilege-escalation-via-named-pipe-impersonation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-privilege-escalation-via-named-pipe-impersonation.asciidoc
new file mode 100644
index 0000000000..36d043751e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-privilege-escalation-via-named-pipe-impersonation.asciidoc
@@ -0,0 +1,178 @@
+[[prebuilt-rule-8-19-24-privilege-escalation-via-named-pipe-impersonation]]
+=== Privilege Escalation via Named Pipe Impersonation
+
+Identifies a privilege escalation attempt via named pipe impersonation. An adversary may abuse this technique by utilizing a framework such as Metasploit's meterpreter getsystem command.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.ired.team/offensive-security/privilege-escalation/windows-namedpipes-privilege-escalation
+* https://www.cobaltstrike.com/blog/what-happens-when-i-type-getsystem/
+* https://redcanary.com/blog/getsystem-offsec/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Resources: Investigation Guide
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Windows Security Event Logs
+* Data Source: Microsoft Defender XDR
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+
+*Version*: 319
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Privilege Escalation via Named Pipe Impersonation*
+
+
+
+*Possible investigation steps*
+
+
+- Did the alert process act as a named-pipe client for a SYSTEM-token handoff?
+  - Why: GetSystem-style abuse pairs a service-context client with a named-pipe server so the server can impersonate the client token; the shell pipe-write is the client-side marker.
+  - Focus: `process.name`, `process.pe.original_file_name`, `process.command_line`, `host.id`, and `user.id`.
+  - Implication: escalate when cmd or PowerShell sends a short marker into a named pipe before token impersonation; lower suspicion only when the same pipe name, marker, host, and user match a stable validation pattern.
+- Does the parent and token context fit a service-driven impersonation attempt?
+  - Focus: `process.parent.name`, `process.parent.command_line`, broader process lineage when needed, `process.Ext.token.integrity_level_name`, and `process.Ext.token.elevation_level`. !{investigate{"description":"","label":"Process starts on the host near the pipe write","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when services.exe, service-creation command lines, or an unexplained launcher starts the pipe write under high or SYSTEM context; absent or ambiguous token context cannot close the alert without matching identity and follow-on evidence.
+- Is the launching binary the expected Windows shell or a masqueraded copy?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the shell runs from a user-writable or deceptive path, has an untrusted signer, or mismatches its original file name; signed System32 cmd or PowerShell confirms identity only and does not clear the pipe-write behavior.
+- Did the pipe writer launch or enable follow-on SYSTEM activity?
+  - Focus: child process events from `process.entity_id`; review `process.name`, `process.command_line`, and `process.Ext.token.integrity_level_name`. !{investigate{"description":"","label":"Child process starts from the pipe writer","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when a shell, tool, service helper, or credential-access process follows under high or SYSTEM integrity; absence of child process evidence lowers only follow-on confidence when pipe syntax or service parentage remains suspicious.
+  - Hint: if `process.entity_id` is unavailable, use `host.id` plus `process.pid` in a tight alert-time window and treat matches as weaker.
+- Is this isolated, or part of repeated named-pipe impersonation behavior?
+  - Focus: process starts sharing `host.id` or `user.id`, marker behavior in `process.command_line`, and either `process.parent.name` or `process.hash.sha256`.
+    - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate scope when repeats cross hosts, users, hashes, or parent chains; keep response local only when all repeats stay inside the same process-evidenced validation pattern.
+  - Range: start with the alert window; expand only if local evidence is suspicious or unresolved.
+- Escalate on suspicious pipe-write syntax, parent/token context, binary identity, follow-on process activity, or host/user scope; close only when all evidence matches a stable validation pattern with no contradictions; preserve artifacts and escalate when evidence is mixed or incomplete.
+
+
+*False positive analysis*
+
+
+- Routine administration should not require shell echo redirection into a named pipe for privilege escalation. Controlled security validation is the narrow benign path; process evidence must prove the exact pattern:
+  - **Identity**: `process.executable`, `process.hash.sha256`, signer, and `process.parent.command_line` match the validation toolchain.
+  - **Pipe syntax**: `process.command_line` shows the expected pipe name, echo value, and wrapper syntax for that test.
+  - **Scope**: `host.id` and `user.id` stay inside the known test target and operator scope.
+  - **Follow-on**: child process starts do not show unexpected high or SYSTEM activity outside the test plan.
+  - If telemetry cannot prove the test scope or toolchain, outside confirmation can corroborate the case but cannot override contradictory process evidence; otherwise preserve and escalate.
+- Build exceptions only from the minimum confirmed validation pattern: stable `process.hash.sha256`, `process.executable`, `process.parent.command_line`, constrained `host.id` or `user.id`, and the specific pipe-write shape in `process.command_line`. Avoid exceptions on `process.name`, cmd or PowerShell alone, or a pipe name alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign:
+  - Reverse any temporary containment and document the evidence that confirmed the validation workflow: pipe syntax, parent/token context, binary identity, `host.id`, `user.id`, and lack of unexpected follow-on SYSTEM activity.
+- If suspicious but unconfirmed:
+  - Preserve the alert, process tree, command lines, parent and child process records, `process.entity_id`, `process.pid`, hashes, and the named-pipe string before termination, cleanup, or credential actions.
+  - Apply reversible containment tied to the findings, such as isolating the endpoint after weighing host criticality or restricting the affected account/session while investigation continues.
+  - Do not terminate cmd, PowerShell, or child processes until the process identifiers, command lines, and any volatile state needed by responders are captured.
+- If confirmed malicious:
+  - Isolate the endpoint after preservation when parent/token, identity, or follow-on process evidence confirms unauthorized SYSTEM activity.
+  - Suspend or terminate the pipe writer and follow-on processes only after recording their entity IDs, PIDs, command lines, hashes, and parent relationships.
+  - Reset credentials or revoke sessions for affected users only when process/session evidence indicates account misuse or credential exposure.
+  - Eradicate only malicious tools, service definitions, binaries, scripts, and configuration changes confirmed during the investigation, then remediate the entry vector that allowed the named-pipe impersonation attempt.
+- Post-incident hardening:
+  - Restrict local admin and service-creation rights that allow untrusted tooling to create SYSTEM service clients.
+  - Retain command-line, parent/child process, and token-integrity telemetry because those fields distinguish testing from GetSystem abuse.
+  - Document the confirmed benign validation pattern or malicious artifact set so future analysts can separate repeat testing from repeat abuse.
+
+
+==== 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 : ("Cmd.Exe", "PowerShell.EXE") or ?process.pe.original_file_name in ("Cmd.Exe", "PowerShell.EXE")) and
+ process.args : "echo" and process.args : ">" and process.args : "\\\\.\\pipe\\*"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Access Token Manipulation
+** ID: T1134
+** Reference URL: https://attack.mitre.org/techniques/T1134/
+* Sub-technique:
+** Name: Token Impersonation/Theft
+** ID: T1134.001
+** Reference URL: https://attack.mitre.org/techniques/T1134/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc
new file mode 100644
index 0000000000..358750855d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc
@@ -0,0 +1,145 @@
+[[prebuilt-rule-8-19-24-privilege-escalation-via-rogue-named-pipe-impersonation]]
+=== Privilege Escalation via Rogue Named Pipe Impersonation
+
+Identifies a privilege escalation attempt via rogue named pipe impersonation. An adversary may abuse this technique by masquerading as a known named pipe and manipulating a privileged process to connect to it.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.sysmon_operational-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://itm4n.github.io/printspoofer-abusing-impersonate-privileges/
+* https://github.com/zcgonvh/EfsPotato
+* https://twitter.com/SBousseaden/status/1429530155291193354
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Data Source: Sysmon
+* Resources: Investigation Guide
+
+*Version*: 212
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Privilege Escalation via Rogue Named Pipe Impersonation*
+
+
+
+*Possible investigation steps*
+
+
+- What rogue pipe path did the alert preserve?
+  - Why: the rule references PrintSpoofer and EfsPotato-style abuse, where a controlled pipe can be hidden inside a path that makes a privileged service connect to what appears to be its normal RPC pipe.
+  - Focus: alert-local `file.name`, `file.path`, or `winlog.event_data.PipeName`, with `event.provider` and `event.code`.
+  - Implication: escalate when the path embeds `\pipe\` after another path segment or mimics a service/RPC pipe tail; benign starts only when exact namespace, creator path, command line, account, and client evidence fit one repeated local IPC workflow on this `host.id`.
+- Which process and account created the suspicious pipe?
+  - Focus: same-host creator `process.executable`, `process.command_line`, `user.name`, and `user.domain`.
+  - Implication: escalate when a service, web worker, script host, or user-writable binary creates the pipe under a low-privileged service identity or account that should not host IPC servers; service-mimic pipe plus suspicious creator is enough while collecting client and impact evidence.
+  - Hint: pivot by `process.entity_id`; if absent, pair `process.pid` with `host.id` in a tight window. !{investigate{"description":"","label":"Events for the pipe creator 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":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+- Do surrounding events corroborate the creator or show a privileged client?
+  - Focus: same-host Sysmon or Windows records for the same `file.name` or `winlog.event_data.PipeName`, reading `event.code`; pipe-connected events, when ingested, corroborate.
+  - Hint: same pipe events on the host. !{investigate{"description":"","label":"Events for the same pipe on this host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.name","queryType":"phrase","value":"{{file.name}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.PipeName","queryType":"phrase","value":"{{winlog.event_data.PipeName}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when surrounding records show the same creator maintaining the pipe or, if pipe-connected events exist, a SYSTEM, administrator, service-host, or service/RPC client touching it. Missing pipe-connect telemetry is unresolved, not benign.
+  - Range: alert window plus +/-5 minutes; expand only if the creator lived longer.
+- Was the pipe followed by elevated execution or token/session abuse?
+  - Focus: same-host process starts after pipe creation: `process.executable`, `process.command_line`, `user.name`, and `winlog.event_data.ElevatedToken` when Windows Security has token context.
+  - Hint: process starts on the host around pipe creation. !{investigate{"description":"","label":"Process starts on the host near the pipe creation","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: elevated shell, script, service-control, SYSTEM, administrator, or elevated-token activity confirms impact; absence lowers impact only after the pipe path, creator, and client evidence fit one recognized workflow. Missing process-start or token telemetry is unresolved, not benign.
+- Does the same rogue-pipe pattern show wider tooling or repeated attempts?
+  - Focus: broaden only after suspicious or unresolved local evidence, using the suspicious `file.name` or `winlog.event_data.PipeName` pattern, creator `process.executable`, `host.id`, and `user.id`.
+  - Hint: same pipe name or creator executable across recent events. !{investigate{"description":"","label":"Events for the same pipe or creator executable","providers":[[{"excluded":false,"field":"file.name","queryType":"phrase","value":"{{file.name}}","valueType":"string"}],[{"excluded":false,"field":"winlog.event_data.PipeName","queryType":"phrase","value":"{{winlog.event_data.PipeName}}","valueType":"string"}],[{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: expand scope when the same embedded-pipe pattern, service/RPC-like tail, or creator executable appears across unrelated hosts or users; no recurrence limits scope but does not close the alert.
+- Escalate when pipe shape plus creator, client, or follow-on evidence supports impersonation; close only when available evidence aligns to one recognized IPC product or authorized test with no contradictory privileged-client or elevated-execution evidence; preserve evidence and escalate when telemetry is missing, mixed, or incomplete.
+
+
+*False positive analysis*
+
+
+- Recognized local IPC products, security tools, or in-house services can trigger when they use nested pipe namespaces with `\pipe\`. Confirm the exact namespace, creator path and command line, account, client process, and host cohort align to the same product, with no elevated follow-on outside that workflow.
+- Authorized exploit validation can trigger this rule. Confirm test host, test account, time window, pipe namespace, and launched command match the test plan; privileged-client or elevated-execution evidence beyond the plan is suspicious.
+- Build exceptions from the minimum confirmed workflow: exact pipe namespace or stable prefix, creator `process.executable` plus command-line pattern, expected `user.id`, and constrained `host.id` or host group. Avoid broad exceptions on `process.name`, service-like pipe tails, or generic `\pipe\`.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and record the pipe namespace, creator process, account, client process, host scope, and absence of unexpected elevated follow-on activity.
+- If suspicious but unconfirmed, preserve the alert record, relevant Timeline events, `file.name` or `winlog.event_data.PipeName`, creator `process.entity_id` or `process.pid`, process command lines, Windows Security records, and any spawned process identifiers before containment.
+- Apply reversible containment before destructive action: isolate or restrict the affected host only when pipe, creator, client, or follow-on evidence indicates active abuse, and weigh critical host roles before isolation.
+- If confirmed malicious, contain the host and involved account, then terminate or suspend malicious processes only after preserving identifiers and command lines. Reset credentials only when Windows Security or process evidence shows account misuse or exposed privileged sessions.
+- Eradicate only the exploit tools, scripts, service changes, or payloads identified during the investigation, then address the entry vector that let the creator process run with impersonation-capable privileges.
+- Post-incident, restrict the privileged service or service account that the investigation showed was coerced or exposed to unnecessary impersonation-capable privileges.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires Sysmon telemetry to be enabled and ingested.
+
+Setup instructions: https://ela.st/sysmon-event-pipe-setup
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+file where host.os.type == "windows" and
+  event.provider == "Microsoft-Windows-Sysmon" and
+  
+  /* Named Pipe Creation */
+  event.code == "17" and
+  
+  /* Sysmon truncates the "Pipe" keyword in normal named pipe creation events */
+  file.name : "\\*\\Pipe\\*"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Access Token Manipulation
+** ID: T1134
+** Reference URL: https://attack.mitre.org/techniques/T1134/
+* Sub-technique:
+** Name: Token Impersonation/Theft
+** ID: T1134.001
+** Reference URL: https://attack.mitre.org/techniques/T1134/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-privilege-escalation-via-windir-environment-variable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-privilege-escalation-via-windir-environment-variable.asciidoc
new file mode 100644
index 0000000000..6fea27f274
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-privilege-escalation-via-windir-environment-variable.asciidoc
@@ -0,0 +1,179 @@
+[[prebuilt-rule-8-19-24-privilege-escalation-via-windir-environment-variable]]
+=== Privilege Escalation via Windir Environment Variable
+
+Identifies a privilege escalation attempt via a rogue Windows directory (Windir) environment variable. This is a known primitive that is often combined with other vulnerabilities to elevate privileges.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.registry-*
+* endgame-*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-crowdstrike.fdr*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.tiraniddo.dev/2017/05/exploiting-environment-variables-in.html
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Microsoft Defender XDR
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 316
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Privilege Escalation via Windir Environment Variable*
+
+
+
+*Possible investigation steps*
+
+
+- Does the alert show a Windir or SystemRoot override that can affect this user?
+  - Focus: `registry.path`, `registry.value`, `registry.data.strings`, `host.id`, and `user.id`.
+  - Implication: Escalate when a per-user Environment hive, such as HKEY_USERS SID or HKCU-equivalent context, changes "windir" or "systemroot" away from "C:\Windows" or "%SystemRoot%"; lower suspicion only when the same host and user recur with the same test or image-engineering value.
+
+- Does the replacement value create a redirection path?
+  - Focus: `registry.data.strings` and `registry.data.type`: user-writable roots, UNC paths, or unexpected command content.
+  - Implication: Escalate when the value can redirect a Windows-root process to attacker-controlled content or command execution; lower suspicion only when the exact replacement is bounded test or image data and no later elevated execution uses it.
+
+- Is the writing process the expected tool in an explainable launch chain?
+  - Focus: `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.parent.command_line`.
+  - Implication: Escalate when the writer is "reg.exe", a script host, unsigned or user-writable binary, browser or Office child, or renamed tool outside a recognized management chain; reduce suspicion only when signer, path, parent, and arguments match the same test or image-engineering toolchain.
+
+- Does the session and token context make a UAC-bypass path feasible?
+  - Focus: `user.id`, `user.domain`, `process.Ext.session_info.logon_type`, `process.Ext.token.integrity_level_name`, and `process.Ext.token.elevation_level`.
+  - Implication: Escalate when an interactive or remote-admin user changes a per-user value from a medium or limited token and later activity reaches high integrity; lower suspicion when a noninteractive service or repair context cannot exercise an interactive auto-elevated task.
+  - Hint: Recover session and token fields from the writer process by `process.entity_id`; if absent, use the same host plus `process.pid` and a tight time window. !{investigate{"description":"","label":"Writer process event","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+
+- Did follow-on process execution exercise the override?
+  - Focus: same-host, same-user process starts after the alert, comparing `process.executable`, `process.command_line`, `process.parent.executable`, and `process.Ext.token.integrity_level_name` to the replacement value.
+  - Implication: Escalate when follow-on execution resolves through the substituted path or higher integrity, or when command-line evidence consumes then deletes or restores the value.
+  - Hint: If no follow-on execution appears in the alert window, treat the value as staged and extend only far enough to test later starts reusing the same replacement string. !{investigate{"description":"","label":"Process events for the same user and host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+
+- If local evidence is suspicious or unresolved, do related alerts change scope?
+  - Focus: related alerts for meaningful `user.id` values, such as real users or named service accounts. For machine, local service, or generic service identities, prioritize same-host alerts.
+    - !{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 response when the same user or host has adjacent privilege-escalation, persistence, defense-evasion, credential-access, or suspicious elevated-process alerts; keep scope local when related alerts are absent and local telemetry supports the same test or image-engineering pattern.
+
+Final - Escalate when the non-default value enables redirection or command execution and writer, session, follow-on, or related-alert evidence is suspicious; close only when the registry value, writer path and parent, session, timeline, and host or user pattern fit the same test or image-engineering workflow; preserve artifacts and escalate when evidence is mixed or visibility is incomplete.
+
+
+*False positive analysis*
+
+
+- Non-default per-user "windir" or "systemroot" values are unusual on production endpoints. Close as benign only when registry value, writer identity, parent chain, session, host and user pattern, and surrounding process or registry activity converge on one exact test or image-engineering workflow; outside confirmation can corroborate only after telemetry aligns. Recurrence can support missing records but not unresolved current telemetry.
+- Do not close if the replacement value, writer lineage, host or user pattern, or elevated-execution evidence drifts.
+- Before creating an exception, validate the minimum stable pattern: exact `registry.path`, exact or tightly bounded `registry.data.strings`, writer `process.executable`, parent `process.parent.command_line`, `host.id`, and `user.id`. Avoid exceptions on `registry.value`, process names such as "cmd.exe", or `host.id` alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and record the exact evidence that proved the workflow: `registry.path`, `registry.data.strings`, writer `process.executable`, `process.parent.command_line`, `host.id`, and `user.id`. Create an exception only if the same bounded pattern is stable across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve a case export of the alert and registry event, the original and modified Environment values, the writer process tree anchored on `process.entity_id`, command lines, and any substituted-path binaries or scripts recovered from the host before containment or cleanup.
+- Apply reversible containment first: heightened monitoring, temporary task or execution restrictions, or removal of the rogue Environment value after evidence capture if operations permit it. Escalate to host isolation or account containment only when follow-on elevated execution, higher-integrity child processes, or related post-exploitation alerts make active misuse likely and the host role can tolerate stronger action.
+- If confirmed malicious, isolate the endpoint when the registry value, writer lineage, session context, and follow-on execution show unauthorized privilege escalation. Before terminating processes or deleting artifacts, record the writer and follow-on process entity IDs, command lines, parent chain, modified registry path and value, substituted-path artifacts, and privileged process paths.
+- After scope is preserved, restore "windir" or "systemroot" to the expected value, remove substituted-path content or execution triggers identified during triage, and review which privileged processes executed from the substituted path before cleanup.
+- If the override was exercised or related alerts show broader compromise, treat the affected user context as potentially elevated beyond its intended boundary. Scope administrator or remote-access accounts active on the host and perform credential hygiene according to exposure and role.
+- Post-incident hardening: reduce use of environment-variable-expanded paths in auto-elevated tasks where possible, retain process and registry telemetry needed for writer-lineage and follow-on execution review, and record any uncovered variant or visibility gap in the case outcome.
+
+==== 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-reg-setup[Sysmon Registry Events]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+registry where host.os.type == "windows" and event.type == "change" and
+registry.value : ("windir", "systemroot") and registry.data.strings != null and
+registry.path : (
+    "*\\Environment\\windir",
+    "*\\Environment\\systemroot"
+    ) and
+ not registry.data.strings : ("C:\\windows", "%SystemRoot%")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Hijack Execution Flow
+** ID: T1574
+** Reference URL: https://attack.mitre.org/techniques/T1574/
+* Sub-technique:
+** Name: Path Interception by PATH Environment Variable
+** ID: T1574.007
+** Reference URL: https://attack.mitre.org/techniques/T1574/007/
+* 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-24/prebuilt-rule-8-19-24-privileges-elevation-via-parent-process-pid-spoofing.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-privileges-elevation-via-parent-process-pid-spoofing.asciidoc
new file mode 100644
index 0000000000..9f76ef089c
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-privileges-elevation-via-parent-process-pid-spoofing.asciidoc
@@ -0,0 +1,200 @@
+[[prebuilt-rule-8-19-24-privileges-elevation-via-parent-process-pid-spoofing]]
+=== Privileges Elevation via Parent Process PID Spoofing
+
+Identifies parent process spoofing used to create an elevated child process. Adversaries may spoof the parent process identifier (PPID) of a new process to evade process-monitoring defenses or to elevate privileges.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://gist.github.com/xpn/a057a26ec81e736518ee50848b9c2cd6
+* https://blog.didierstevens.com/2017/03/20/that-is-not-my-child-process/
+* https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute
+* https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1134.002/T1134.002.md
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 12
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Privileges Elevation via Parent Process PID Spoofing*
+
+
+
+*Possible investigation steps*
+
+
+- Does the alert show a SYSTEM child with a spoofed parent relationship?
+  - Focus: `user.id`, token integrity, `process.parent.pid`, `process.parent.Ext.real.pid`, and `process.parent.executable`.
+  - Implication: escalate when a SYSTEM child has a nonzero real-creator PID that differs from the reported parent, especially when that parent gives trusted system, service, or desktop cover; treat a recognized broker or authorized test as only a candidate benign path until creator and child intent are checked.
+  - Why: PPID spoofing can make process-tree views show the selected parent instead of the process that requested creation.
+- Which process actually requested the spoofed launch?
+  - Focus: recovered creator for `process.parent.Ext.real.pid`: `process.entity_id`, `process.executable`, `process.command_line`, signer, and trust state.
+  - Implication: escalate when the creator is unsigned, user-writable, a shell or script launcher, or unrelated to the reported parent; lower suspicion only for a stable signed vendor, update, accessibility, audit, or test component tied to the same workflow.
+  - Why: the Windows parent-process attribute can select a parent handle, so the recovered creator is the actor path the visible parent may hide.
+  - Hint: search the same `host.id` around `@timestamp` for `process.pid` = `process.parent.Ext.real.pid`; keep PID windows tight because PIDs are reused. !{investigate{"description":"","label":"Real creator process event","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.Ext.real.pid}}","valueType":"string"}]],"relativeFrom":"now-15m","relativeTo":"now"}}
+- Does the SYSTEM child identity and command line fit the recovered creator workflow?
+  - Focus: `process.executable`, `process.command_line`, `process.pe.original_file_name`, signer, and trust state.
+  - Implication: escalate when the child is a shell, script host, renamed binary, user-writable executable, unsigned or untrusted, or has commands that do not belong to the recovered creator; trusted signing reduces identity concern but does not clear PPID spoofing without launch-context fit.
+- Did the spoofed SYSTEM child launch follow-on activity?
+  - Focus: child process events from `process.entity_id`, reviewing `process.executable`, `process.command_line`, and `user.id`. !{investigate{"description":"","label":"Descendant process events for the spoofed child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when it spawns shells, scripting, credential, service, or lateral-movement tooling under SYSTEM; no descendants lowers immediate impact but does not clear a suspicious creator or child identity.
+  - Hint: if `process.entity_id` is unavailable, fall back to `host.id`, `process.pid`, and a tight alert-time window.
+- If escalation is likely, what is the immediate scope?
+  - Focus: prior process alerts for `host.id` and `user.id` with matching child executable or hash, reported parent, and real-creator PID.
+    - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: expand containment and scoping when the same child or creator appears on other hosts or unrelated users; keep scope local when the tuple is isolated and no descendant activity contradicts it. Do not use recurrence alone to close.
+  - Range: use a lookback that fits endpoint retention.
+
+Disposition: escalate when PPID spoofing to SYSTEM has an unrecognized creator, suspicious child, misleading parent, SYSTEM follow-on activity, or cross-host scope. Close only when alert and recovered telemetry tie the event to one exact recognized broker or authorized test and no descendant evidence contradicts it; preserve evidence and escalate when recovery is incomplete or evidence conflicts.
+
+
+*False positive analysis*
+
+
+- Signed broker cases require the exact telemetry tuple: child path, signer, and command; reported parent path; recovered creator path, signer, and command; and host/user cohort. Authorized PPID-spoofing tests require exact host, time, tester, test binary, parent PID, real creator PID, and child command line. Without that tie to one product or test, treat as suspicious because the rule already filters common Windows Error Reporting, update, accessibility, remote-support, and Netwrix patterns.
+- Build exceptions only from the minimum confirmed tuple: `process.hash.sha256` or `process.code_signature.thumbprint_sha256`, `process.executable`, `process.parent.executable`, recovered creator identity, `host.id` or managed host group, and the test or product command pattern. Avoid exceptions on `process.name`, `process.parent.name`, or signer alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign: document the exact child, reported parent, real creator, signer, command line, host, and user evidence that proved the workflow; reverse any temporary containment and create only a narrow exception for the same tuple.
+- If suspicious but unconfirmed: preserve the alert, process event, recovered creator and descendant process records, process entity IDs and PIDs, command lines, hashes, signers, and current process state before containment. Use reversible containment such as host isolation or temporary policy controls based on host criticality; avoid killing the child or creator until evidence is preserved.
+- If confirmed malicious: isolate the affected host when identity, lineage, or descendant evidence shows unauthorized SYSTEM execution. Before termination, record `process.entity_id`, `process.parent.Ext.real.pid`, `process.command_line`, and `process.hash.sha256`; then terminate malicious child or descendant processes and remove only the binaries, scripts, services, or persistence found during follow-on investigation.
+- Reset or rotate credentials only for accounts, services, or remote-access paths whose misuse is confirmed by additional evidence. Do not treat SYSTEM context alone as proof that a named user credential was compromised.
+- Post-incident hardening: restrict administrative paths that can obtain parent-process creation privileges, review who can run PPID-spoofing test tools, and document the confirmed tuple or malicious artifact set so future analysts can separate repeated product behavior from repeated abuse.
+
+==== 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]
+----------------------------------
+/* This rule is compatible with Elastic Endpoint only */
+
+process where host.os.type == "windows" and event.action == "start" and
+
+ /* process creation via seclogon */
+ process.parent.Ext.real.pid > 0 and
+
+ /* PrivEsc to SYSTEM */
+ user.id : "S-1-5-18"  and
+
+ /* Common FPs - evasion via hollowing is possible, should be covered by code injection */
+ not process.executable : ("?:\\Windows\\System32\\WerFault.exe",
+                           "?:\\Windows\\SysWOW64\\WerFault.exe",
+                           "?:\\Windows\\System32\\WerFaultSecure.exe",
+                           "?:\\Windows\\SysWOW64\\WerFaultSecure.exe",
+                           "?:\\Windows\\System32\\Wermgr.exe",
+                           "?:\\Windows\\SysWOW64\\Wermgr.exe",
+                           "?:\\Windows\\SoftwareDistribution\\Download\\Install\\securityhealthsetup.exe") and
+ /* Logon Utilities */
+ not (process.parent.executable : "?:\\Windows\\System32\\Utilman.exe" and
+     process.executable : ("?:\\Windows\\System32\\osk.exe",
+                           "?:\\Windows\\System32\\Narrator.exe",
+                           "?:\\Windows\\System32\\Magnify.exe",
+                           "?:\\Windows\\System32\\VoiceAccess.exe")) and
+
+ not process.parent.executable : "?:\\Windows\\System32\\AtBroker.exe" and
+
+ not (process.code_signature.subject_name in
+           ("philandro Software GmbH", "Freedom Scientific Inc.", "TeamViewer Germany GmbH", "Projector.is, Inc.",
+            "TeamViewer GmbH", "Cisco WebEx LLC", "Dell Inc") and process.code_signature.trusted == true) and
+
+ /* AM_Delta_Patch Windows Update */
+ not (process.executable : ("?:\\Windows\\System32\\MpSigStub.exe", "?:\\Windows\\SysWOW64\\MpSigStub.exe") and
+      process.parent.executable : ("?:\\Windows\\System32\\wuauclt.exe",
+                                   "?:\\Windows\\SysWOW64\\wuauclt.exe",
+                                   "?:\\Windows\\UUS\\Packages\\Preview\\*\\wuaucltcore.exe",
+                                   "?:\\Windows\\UUS\\amd64\\wuauclt.exe",
+                                   "?:\\Windows\\UUS\\amd64\\wuaucltcore.exe",
+                                   "?:\\ProgramData\\Microsoft\\Windows\\UUS\\*\\wuaucltcore.exe")) and
+ not (process.executable : ("?:\\Windows\\System32\\MpSigStub.exe", "?:\\Windows\\SysWOW64\\MpSigStub.exe") and process.parent.executable == null) and
+
+ /* Other third party SW */
+ not process.parent.executable :
+                   ("?:\\Program Files (x86)\\HEAT Software\\HEAT Remote\\HEATRemoteServer.exe",
+                    "?:\\Program Files (x86)\\VisualCron\\VisualCronService.exe",
+                    "?:\\Program Files\\BinaryDefense\\Vision\\Agent\\bds-vision-agent-app.exe",
+                    "?:\\Program Files\\Tablet\\Wacom\\WacomHost.exe",
+                    "?:\\Program Files (x86)\\LogMeIn\\x64\\LogMeIn.exe",
+                    "?:\\Program Files (x86)\\EMC Captiva\\Captiva Cloud Runtime\\Emc.Captiva.WebCaptureRunner.exe",
+                    "?:\\Program Files\\Freedom Scientific\\*.exe",
+                    "?:\\Program Files (x86)\\Google\\Chrome Remote Desktop\\*\\remoting_host.exe",
+                    "?:\\Program Files (x86)\\GoToAssist Remote Support Customer\\*\\g2ax_comm_customer.exe") and
+ not (
+    process.code_signature.trusted == true and process.code_signature.subject_name == "Netwrix Corporation" and
+    process.name : "adcrcpy.exe" and process.parent.name : (
+      "Netwrix.ADA.EventCollector.exe",
+      "Netwrix.ADA.Analyzer.exe"
+    )
+ )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Access Token Manipulation
+** ID: T1134
+** Reference URL: https://attack.mitre.org/techniques/T1134/
+* Sub-technique:
+** Name: Create Process with Token
+** ID: T1134.002
+** Reference URL: https://attack.mitre.org/techniques/T1134/002/
+* Sub-technique:
+** Name: Parent PID Spoofing
+** ID: T1134.004
+** Reference URL: https://attack.mitre.org/techniques/T1134/004/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-process-created-with-an-elevated-token.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-process-created-with-an-elevated-token.asciidoc
new file mode 100644
index 0000000000..eab22cebde
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-process-created-with-an-elevated-token.asciidoc
@@ -0,0 +1,206 @@
+[[prebuilt-rule-8-19-24-process-created-with-an-elevated-token]]
+=== Process Created with an Elevated Token
+
+Identifies the creation of a process running as SYSTEM while impersonating the token context of a Windows core binary. Adversaries may create a new process with a different token to escalate privileges and bypass access controls.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://lengjibo.github.io/token/
+* https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createprocesswithtokenw
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 12
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Process Created with an Elevated Token*
+
+
+*Possible investigation steps*
+
+
+- What SYSTEM token path did the alert record?
+  - Why: CreateProcessWithTokenW-style abuse creates a process in a supplied token context, so child, OS parent, and effective parent must be interpreted together.
+  - Focus: `user.id`, `process.executable`, `process.command_line`, `process.parent.executable`, and `process.Ext.effective_parent.executable`.
+  - Implication: escalate when a payload or unusual command runs as `S-1-5-18` through a Windows effective parent without one exact recognized workflow; lower suspicion only when child, OS parent, and effective parent all bind to the same vendor, update, accessibility, or test activity.
+- Does the OS parent explain why another token was used?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.code_signature.subject_name`, and lineage when needed.
+  - Implication: escalate when the parent is user-writable, script-driven, remote-tool initiated, unexpectedly signed, or unrelated to the effective parent; lower suspicion when it is a stable signed helper for the same component.
+- Is the created process identity consistent with that workflow?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, and `process.code_signature.subject_name`.
+  - Implication: escalate when the SYSTEM child has an unexpected signer, user-writable path, new hash, or PE-name mismatch; lower suspicion when signer, hash history, path, and parent context all fit the same component.
+- Does the token and session context explain the SYSTEM child?
+  - Why: CreateProcessWithTokenW, CreateProcessAsUserW, and runas-style abuse can look ordinary unless token/session context is compared with lineage.
+  - Focus: `process.Ext.authentication_id`, `process.Ext.session_info.logon_type`, `process.Ext.token.integrity_level_name`, `process.Ext.token.elevation_level`, and `user.id`.
+  - Implication: escalate when SYSTEM or full-integrity execution appears in a logon/session context disconnected from parent or effective parent; lower suspicion when token level and session type match the same service, update, accessibility, or test component.
+- Did the process tree show staging or immediate follow-on execution?
+  - Why: token reuse after the first child makes repeated SYSTEM children or fresh executable timing a scope-expansion trigger.
+  - Focus: same-`host.id` child process starts from `process.entity_id`; review child `process.executable`, `process.command_line`, `process.Ext.relative_file_creation_time`, and `process.Ext.relative_file_name_modify_time`. !{investigate{"description":"","label":"Child process starts from the SYSTEM process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if hash or relative-time values are empty, scope with `process.executable`, `process.command_line`, `process.parent.executable`, and `process.Ext.effective_parent.executable`; broaden only when local evidence stays suspicious or unresolved.
+    - !{investigate{"description":"","label":"Process events for the same token-creation pattern","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"},{"excluded":false,"field":"process.parent.executable","queryType":"phrase","value":"{{process.parent.executable}}","valueType":"string"},{"excluded":false,"field":"process.Ext.effective_parent.executable","queryType":"phrase","value":"{{process.Ext.effective_parent.executable}}","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"}}
+    - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate when the SYSTEM child launches shells, script interpreters, security tools, freshly created or renamed executables, or the same token-creation pattern on unrelated hosts; lower suspicion when descendants and recurrence stay inside the same component pattern.
+- What disposition is supported?
+  - Escalate on conflict across child command, parent/effective-parent pair, identity, token/session, or descendants. Close only when the same signed component explains all categories on this `host.id`; preserve and escalate when any element is missing or contradictory.
+
+
+*False positive analysis*
+
+
+- Treat this alert as unusual until alert-local process evidence proves one component expected to create a SYSTEM process from another token, such as an unexcluded vendor support or accessibility helper, updater/installer, print or error-reporting component, or authorized security test.
+- Confirm benign activity only when identity, parentage, token context, and scope all point to that component: `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.parent.executable`, `process.Ext.effective_parent.executable`, `user.id`, and `host.id`. A trusted signer, Windows path, or component label alone is insufficient.
+- Before adding an exception, validate that the exact child/parent/effective-parent pattern is stable for the same host or managed host group. Build from minimum stable fields, avoiding broad exceptions on `process.name`, `user.name`, or `?:\Windows\*.exe` alone.
+
+
+*Response and remediation*
+
+
+- Preserve evidence first: export the alert, process tree, `process.entity_id`, `process.pid`, command lines, hashes, signer details, token/session fields, and any descendant process records before containment or process termination.
+- If suspicious but unconfirmed, preserve and scope first. Use reversible containment such as host isolation only when the SYSTEM child is still running, spawning descendants, or recurring beyond one validated workflow; otherwise keep the host connected for evidence collection while escalating.
+- If malicious activity is confirmed, contain the host, block or quarantine confirmed malicious hashes or executables, and suspend or terminate the SYSTEM child only after recording its identifiers and collecting needed memory or file evidence.
+- Eradicate only artifacts and configuration changes identified during investigation or incident response. Remediate the entry path that obtained or duplicated the token, and reset credentials only for accounts tied to confirmed misuse.
+- After recovery, document the confirmed benign workflow or malicious child/parent/effective-parent pattern, and keep any exception scoped to the stable fields that proved the case.
+
+==== 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]
+----------------------------------
+process where host.os.type == "windows" and event.action == "start" and
+
+ /* CreateProcessWithToken and effective parent is a privileged MS native binary used as a target for token theft */
+ user.id == "S-1-5-18"  and process.parent.executable != null and
+
+ /* Token Theft target process usually running as service are located in one of the following paths */
+ process.Ext.effective_parent.executable : "?:\\Windows\\*.exe" and
+
+/* Ignores Utility Manager in Windows running in debug mode */
+ not (process.Ext.effective_parent.executable : "?:\\Windows\\System32\\Utilman.exe" and
+      process.parent.executable : "?:\\Windows\\System32\\Utilman.exe" and process.parent.args : "/debug") and
+
+/* Ignores Windows print spooler service with correlation to Access Intelligent Form */
+not (process.parent.executable : ("?:\\Windows\\System32\\spoolsv.exe", "?:\\Windows\\System32\\PrintIsolationHost.exe") and
+     process.executable: ("?:\\Program Files\\*.exe",
+                          "?:\\Program Files (x86)\\*.exe",
+                          "?:\\Windows\\System32\\spool\\drivers\\*.exe",
+                          "?:\\Windows\\System32\\ROUTE.EXE")) and
+
+/* Ignores Windows error reporting executables */
+ not process.executable : ("?:\\Windows\\System32\\WerFault.exe",
+                           "?:\\Windows\\SysWOW64\\WerFault.exe",
+                           "?:\\Windows\\System32\\WerFaultSecure.exe",
+                           "?:\\Windows\\SysWOW64\\WerFaultSecure.exe",
+                           "?:\\windows\\system32\\WerMgr.exe",
+                           "?:\\Windows\\SoftwareDistribution\\Download\\Install\\securityhealthsetup.exe")  and
+
+ /* Ignores Windows updates from TiWorker.exe that runs with elevated privileges */
+ not (process.parent.executable : "?:\\Windows\\WinSxS\\*\\TiWorker.exe" and
+      process.executable : ("?:\\Windows\\Microsoft.NET\\Framework*.exe",
+                            "?:\\Windows\\WinSxS\\*.exe",
+                            "?:\\Windows\\System32\\inetsrv\\iissetup.exe",
+                            "?:\\Windows\\SysWOW64\\inetsrv\\iissetup.exe",
+                            "?:\\Windows\\System32\\inetsrv\\aspnetca.exe",
+                            "?:\\Windows\\SysWOW64\\inetsrv\\aspnetca.exe",
+                            "?:\\Windows\\System32\\lodctr.exe",
+                            "?:\\Windows\\SysWOW64\\lodctr.exe",
+                            "?:\\Windows\\System32\\netcfg.exe",
+                            "?:\\Windows\\Microsoft.NET\\Framework*\\*\\ngen.exe",
+                            "?:\\Windows\\Microsoft.NET\\Framework*\\*\\aspnet_regiis.exe")) and
+
+/* Ignores additional parent executables that run with elevated privileges */
+ not process.parent.executable :
+               ("?:\\Windows\\System32\\AtBroker.exe",
+                "?:\\Windows\\system32\\svchost.exe",
+                "?:\\Program Files (x86)\\*.exe",
+                "?:\\Program Files\\*.exe",
+                "?:\\Windows\\System32\\msiexec.exe",
+                "?:\\Windows\\System32\\DriverStore\\*",
+                "?:\\Windows\\LTSvc\\*\\Update.exe") and
+
+/* Ignores Windows binaries with a trusted signature and specific signature name */
+ not (process.code_signature.trusted == true and
+      process.code_signature.subject_name :
+                ("philandro Software GmbH",
+                 "Freedom Scientific Inc.",
+                 "TeamViewer Germany GmbH",
+                 "Projector.is, Inc.",
+                 "TeamViewer GmbH",
+                 "Cisco WebEx LLC",
+                 "Dell Inc",
+                 "Sophos Ltd",
+                 "Sophos Limited",
+                 "Brother Industries, Ltd.",
+                 "MILVUS INOVACOES EM SOFTWARE LTDA",
+                 "Chocolatey Software, Inc")) and
+
+ not (process.Ext.effective_parent.executable : "?:\\Windows\\servicing\\TrustedInstaller.exe" and
+      process.executable : "C:\\Windows\\WinSxS\\amd64_microsoft-windows-servicingstack_*\\TiWorker.exe") and
+
+ not process.Ext.effective_parent.executable : "?:\\Windows\\ServiceProfiles\\LocalService\\AppData\\Local\\ServicePortalAgent\\current\\emulator\\MmrAgent.NetFxEmulator.exe"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Access Token Manipulation
+** ID: T1134
+** Reference URL: https://attack.mitre.org/techniques/T1134/
+* Sub-technique:
+** Name: Create Process with Token
+** ID: T1134.002
+** Reference URL: https://attack.mitre.org/techniques/T1134/002/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-remote-computer-account-dnshostname-update.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-remote-computer-account-dnshostname-update.asciidoc
new file mode 100644
index 0000000000..ce53f5acb7
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-remote-computer-account-dnshostname-update.asciidoc
@@ -0,0 +1,158 @@
+[[prebuilt-rule-8-19-24-remote-computer-account-dnshostname-update]]
+=== Remote Computer Account DnsHostName Update
+
+Identifies the remote update to a computer account's DnsHostName attribute. If the new value set is a valid domain controller DNS hostname and the subject computer name is not a domain controller, then it's highly likely a preparation step to exploit CVE-2022-26923 in an attempt to elevate privileges from a standard domain user to domain admin privileges.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4
+* https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-26923
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Use Case: Active Directory Monitoring
+* Data Source: Active Directory
+* Use Case: Vulnerability
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 215
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Remote Computer Account DnsHostName Update*
+
+
+
+*Possible investigation steps*
+
+
+- What object, initiator, and DNS-name mismatch does the alert prove?
+  - Focus: `winlog.event_data.TargetUserName`, `winlog.event_data.TargetSid`, `winlog.event_data.DnsHostName`, `winlog.event_data.SubjectUserSid`, and `winlog.event_data.SubjectLogonId`.
+  - Implication: escalate or continue when the new DNS host name no longer matches the target computer account and points to another server namespace; lower suspicion only when target SID, subject SID, and logon session fit a recognized rename, promotion, re-binding, or authorized test.
+
+- Does the new DNS host name collide with a domain controller or other sensitive host?
+  - Why: Certifried abuse makes a controlled computer account look like a trusted host before requesting or using a machine certificate.
+  - Focus: `winlog.event_data.DnsHostName`, `winlog.event_data.TargetUserName`, `winlog.event_data.TargetDomainName`, and `winlog.computer_name`.
+  - Implication: high risk when the value matches a real domain controller, CA, or privileged server different from `winlog.event_data.TargetUserName`; lower risk only when it belongs to the same object transition and does not collide with a privileged asset.
+
+- Who made the update, and does the source/session context fit that account's role?
+  - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, `winlog.event_data.SubjectLogonId`, and `source.ip`.
+  - Implication: escalate when the subject is a standard user, non-tier-0 admin, unusual service account, machine account, or unexpected source for computer-account management; lower suspicion when subject, source when present, and logon session match a recognized AD management path.
+
+- Did the same object show SPN deletion, empty-SPN creation, or other preparation?
+  - Why: successful DNS-name spoofing often requires removing FQDN service principal names or creating a computer account without them so SPN uniqueness checks do not block the DNS update.
+  - Focus: Windows Security account-management and directory-change events for `winlog.event_data.TargetSid`, especially `event.code`, `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.AttributeValue`, and `winlog.event_data.ObjectDN`.
+  - Implication: escalate when the sequence removes servicePrincipalName values, creates or controls the computer object, or changes related attributes just before the DNS update; lower suspicion when the same change set follows a recognized promotion or re-binding path.
+
+- Did certificate-service or Kerberos activity use the spoofed identity after the update?
+  - Focus: post-alert Windows Security certificate enrollment and authentication events for `winlog.event_data.TargetUserName` or the spoofed host name, reading `event.code`, `winlog.event_data.AuthenticationPackageName`, `winlog.logon.type`, and `source.ip`.
+  - Hint: missing certificate-service or Kerberos telemetry leaves post-update use unresolved, not benign.
+  - Implication: escalate when the modified object requests or receives a machine certificate, uses Kerberos with the spoofed identity, authenticates from unexpected `source.ip` when present, or appears in privileged follow-on activity; absence of follow-on use lowers urgency only when object, initiator, and preparation evidence also align benignly.
+
+- If local evidence stays suspicious or unresolved, do related alerts show the same modifying user elsewhere?
+  - Focus: related alerts for modifying `user.id`, especially AD manipulation, certificate abuse, credential-access, or privilege-escalation alerts. !{investigate{"description":"","label":"Alerts associated with the modifying user in the surrounding window","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-2h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same user appears in more directory changes, certificate abuse, unusual authentication, or privilege escalation; keep response local only when related alerts are absent and local evidence supports one recognized workflow.
+
+- What disposition do the DNS-name mismatch, hostname collision, initiator, preparation, follow-on use, and scope support?
+  - Escalate on sensitive-host collision, suspicious initiator, SPN/object preparation, certificate/Kerberos use, or related AD abuse; close only when all evidence binds one recognized test or object-transition workflow with no contradictions; preserve evidence and escalate when answers conflict or visibility is incomplete.
+
+
+*False positive analysis*
+
+
+- Benign matches are uncommon because changing a computer account DNS host name to another host namespace is an AD identity anti-pattern. Authorized CVE-2022-26923 testing or patch validation explains the alert only when subject SID/logon, target SID/name, spoofed host name, event-origin controller, SPN/object-change sequence, and follow-on certificate or authentication events all match the same test scope. Without a test plan, close only when telemetry proves a bounded lab pattern; drift in initiator, hostname, or follow-on use keeps the alert suspicious.
+- Rare promotion, rename, migration, or re-binding explains the alert only when the same computer object intentionally assumes the new DNS identity, no privileged-host collision exists, and subject, target SID, new host name, controller, and bounded follow-on authentication path all align. Do not close if telemetry leaves object identity, collision, or follow-on use unresolved.
+- Build exceptions from the minimum confirmed workflow: stable `winlog.event_data.SubjectUserSid`, `winlog.event_data.TargetSid`, `winlog.event_data.TargetUserName`, `winlog.event_data.DnsHostName`, `winlog.computer_name`, and bounded follow-on `source.ip` or `event.code`. Avoid exceptions on `event.action`, `winlog.event_data.DnsHostName`, or `winlog.event_data.TargetSid` alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, document the exact workflow evidence first: subject SID/logon, target SID/name, DNS host name, event-origin controller, SPN/object-change context, and bounded follow-on authentication or certificate pattern. Then reverse temporary containment. Create an exception only after the same pattern is stable enough to avoid suppressing lookalike spoofing.
+- If suspicious but unconfirmed, export the alert and surrounding Windows Security records first, preserving the target object, spoofed host name, subject identity/logon, event-origin controller, SPN/object changes, certificate/authentication events, source IPs, and related alerts. Then use reversible containment, such as restoring the prior DNS host name or temporarily disabling the modified computer account with AD owner coordination. Escalate to account or host containment only when certificate issuance, Kerberos use, or related privilege abuse shows active use.
+- If confirmed malicious, preserve the same AD object-change and follow-on authentication/certificate evidence before restoration. Disable or restore the modified computer object, reset the machine-account secret or trust path, revoke or map affected certificates when issued, and contain the modifying account and suspected source host. Use broader domain recovery only when certificate or Kerberos abuse extends beyond the single object.
+- Before final object restoration, search the same subject SID and target SID across Windows Security logs for additional DNS host name, SPN, certificate, or privilege-abuse events so scope is complete before evidence changes.
+- Post-incident hardening: apply CVE-2022-26923 domain controller and AD CS fixes, reduce ms-DS-MachineAccountQuota where feasible, restrict computer-account creation and validated writes, retain computer-account and 5136 directory-service auditing, and record the confirmed subject/target/hostname/follow-on-authentication pattern for future triage.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Audit Computer Account Management must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-computer-account-management
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+iam where host.os.type == "windows" and event.action == "changed-computer-account" and
+    user.id : ("S-1-5-21-*", "S-1-12-1-*") and
+
+    /* if DnsHostName value equal a DC DNS hostname then it's highly suspicious */
+    winlog.event_data.DnsHostName : "??*" and
+
+    /* exclude FPs where DnsHostName starts with the ComputerName that was changed */
+    not startswith~(winlog.event_data.DnsHostName, substring(winlog.event_data.TargetUserName, 0, length(winlog.event_data.TargetUserName) - 1))
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Exploitation for Privilege Escalation
+** ID: T1068
+** Reference URL: https://attack.mitre.org/techniques/T1068/
+* Technique:
+** Name: 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-24/prebuilt-rule-8-19-24-screenconnect-server-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-screenconnect-server-spawning-suspicious-processes.asciidoc
new file mode 100644
index 0000000000..409a09d977
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-screenconnect-server-spawning-suspicious-processes.asciidoc
@@ -0,0 +1,198 @@
+[[prebuilt-rule-8-19-24-screenconnect-server-spawning-suspicious-processes]]
+=== ScreenConnect Server Spawning Suspicious Processes
+
+Identifies suspicious processes being spawned by the ScreenConnect server process (ScreenConnect.Service.exe). This activity may indicate exploitation activity or access to an existing web shell backdoor.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://blackpointcyber.com/resources/blog/breaking-through-the-screen/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Initial Access
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Windows Security Event Logs
+* Data Source: Microsoft Defender XDR
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 211
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating ScreenConnect Server Spawning Suspicious Processes*
+
+
+
+*Possible investigation steps*
+
+
+- Does the alert prove ScreenConnect application-server execution rather than client-side remote command use?
+  - Why: the reference separates server compromise from routine client deployment; server-side abuse uses "ScreenConnect.Service.exe", while client-side commands usually involve "ScreenConnect.ClientService.exe".
+  - Focus: alert-local `process.parent.name`, `process.parent.executable`, `process.name`, `process.pe.original_file_name`, `host.id`, and `host.name`.
+  - Implication: escalate sooner when "ScreenConnect.Service.exe" on the application server spawned "cmd.exe", PowerShell, or "csc.exe"; lower suspicion only when parent or host evidence proves this is not server-side execution, then resolve the mismatch before applying this guide.
+
+- Is the spawned child the genuine Windows tool expected by its name?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the child runs from a user-writable or ScreenConnect content path, is unsigned or untrusted, or PE metadata does not match the shell, PowerShell, or compiler name; confirmed identity says what ran, not that the launch is benign.
+
+- What intent is visible in the child command line and service context?
+  - Why: ScreenConnect server exploitation often inherits the service identity, so SYSTEM or the expected service account does not reduce risk by itself.
+  - Focus: `process.command_line`, `process.parent.command_line`, and `user.id`.
+  - Implication: escalate when the command shows encoded PowerShell, download or staging, account creation, service changes, webshell-style shell use, or "csc.exe" compiling from temporary or ScreenConnect content paths; lower suspicion only for narrow maintenance, extension, or vendor-support action and later evidence agrees.
+
+- Do ScreenConnect server artifacts corroborate authentication bypass, extension traversal, or webshell staging?
+  - Why: the reference describes CVE-2024-1709 admin-user changes in "Users.xml" and CVE-2024-1708 web-accessible ASP.NET content under "App_Extensions".
+  - Focus: if file telemetry exists, query file events on `host.id` where `process.entity_id` equals server service `process.parent.entity_id`; if absent, pivot on `host.id`, service PID, and alert time, then review `file.path` and `file.name` for "Users.xml", "App_Extensions", ASP.NET files, or extension archives. !{investigate{"description":"","label":"File events for the ScreenConnect server process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if file telemetry is unavailable or empty, inspect those server paths directly; missing file telemetry is unresolved, not benign.
+  - Implication: escalate when "Users.xml" shows an unexpected admin, "App_Extensions" contains a lone ASP.NET file, or extension content appears outside GUID-scoped folders; lower suspicion only when artifacts stay inside expected extension paths and process evidence supports the same workflow.
+
+- Did the spawned child make network connections consistent with follow-on tooling or external control?
+  - Focus: if network telemetry exists, query `host.id` and child `process.entity_id`; if absent, pivot on `host.id`, `process.pid`, and alert time, separating DNS `dns.question.name` from connection `destination.ip`, `destination.port`, and `destination.as.organization.name`. !{investigate{"description":"","label":"Network events for the spawned child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: Missing network telemetry is unresolved, not benign.
+  - Implication: escalate when the shell, PowerShell, or compiler reaches a public destination with no ScreenConnect/vendor relationship, a staging domain, or any destination inconsistent with the recovered command; lower suspicion for absent destinations only after telemetry is verified and local process/artifact evidence resolve cleanly.
+
+- Do related host alerts change scope when local findings are suspicious or unresolved?
+  - Focus: child process starts, additional children from the same ScreenConnect service parent, plus related alerts for `host.id`, especially webshell, persistence, credential-access, service-creation, or secondary-RMM alerts. !{investigate{"description":"","label":"Child process events from the suspicious child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    !{investigate{"description":"","label":"Process events from the same ScreenConnect service","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","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 response scope when the ScreenConnect server also shows exploitation, persistence, credential access, or secondary remote-access activity; keep scope local only when this alert is isolated and process, artifact, and destination evidence all resolve to one exact benign workflow.
+
+- Escalate when server-side parentage combines with suspicious child identity or command intent, or artifacts, destinations, or related alerts support compromise; close only when process evidence and recovery tie to one exact ScreenConnect maintenance, extension, or vendor-support workflow with no contradictions; preserve artifacts and escalate when evidence is mixed or visibility is incomplete.
+
+
+*False positive analysis*
+
+
+- ScreenConnect server maintenance, extension installation, or vendor troubleshooting can legitimately spawn "powershell.exe", "cmd.exe", or "csc.exe". Confirm the same workflow across child identity, signer or hash, command intent, `host.id`, `user.id`, recovered server artifacts, and destinations when network telemetry exists. Use change records or vendor cases as corroboration, not a replacement for telemetry gaps.
+- Do not treat generic administrative scripting or compile activity as benign on a ScreenConnect server. Confirm only narrow recurring service workflow: same parent path, child identity, command pattern, `user.id`, and quiet artifact or destination pattern on the same `host.id` across prior alerts or source events when external records are unavailable. One-off shells, downloaders, account changes, or root-level "App_Extensions" files remain suspicious.
+- Before creating an exception, build it from the minimum confirmed workflow pattern: `process.parent.executable`, `process.executable`, a constrained `process.command_line` pattern, stable signer or hash, `host.id`, and the specific ScreenConnect maintenance or extension context. Avoid exceptions on `process.name` or "ScreenConnect.Service.exe" alone.
+
+
+*Response and remediation*
+
+
+- Before restriction or cleanup in suspicious cases, preserve a case export of the alert process and parent records, recovered file and network events, ScreenConnect and IIS logs around the alert time, "Users.xml", the "App_Extensions" tree, suspicious extension archives or ASP.NET files, and staged payloads.
+- If confirmed benign, reverse temporary restrictions and document evidence proving the workflow: parent and child identity, command intent, server scope, expected ScreenConnect artifacts, and expected destinations if present. Build a narrow exception only after the same workflow recurs consistently.
+- If suspicious but unconfirmed, apply reversible containment tied to the findings: restrict public access to the ScreenConnect web interface, temporarily limit egress from the affected `host.id`, or suspend a newly created ScreenConnect admin account where operationally safe. Weigh server criticality before full host isolation.
+- If confirmed malicious, preserve the artifacts above before terminating processes or deleting files. Then isolate the server or disable public exposure, remove malicious admin accounts, webshells, extensions, secondary RMM services, and other persistence found during the investigation, and rotate compromised ScreenConnect, service, or domain credentials.
+- Patch ScreenConnect to a fixed version and review whether the attacker used the server to reach managed clients or create admin or service accounts.
+- After containment, retain process, file, and network telemetry needed for future ScreenConnect investigations, restrict who can manage extensions or internet exposure, and document any telemetry gaps that limited this investigation.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/crowdstrike-integration[CrowdStrike]
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+- https://ela.st/audit-process-creation[Windows Process Creation Logs]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+  process.parent.name : "ScreenConnect.Service.exe" and
+  (process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe", "csc.exe") or
+  ?process.pe.original_file_name in ("Cmd.Exe", "PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE", "csc.exe"))
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Exploit Public-Facing Application
+** ID: T1190
+** Reference URL: https://attack.mitre.org/techniques/T1190/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
+* Sub-technique:
+** Name: Windows Command Shell
+** ID: T1059.003
+** Reference URL: https://attack.mitre.org/techniques/T1059/003/
+* 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-sensitive-files-compression.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-sensitive-files-compression.asciidoc
new file mode 100644
index 0000000000..fd19804946
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-sensitive-files-compression.asciidoc
@@ -0,0 +1,231 @@
+[[prebuilt-rule-8-19-24-sensitive-files-compression]]
+=== Sensitive Files Compression
+
+Identifies the use of a compression utility to collect known files containing sensitive information, such as credentials and system configurations.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* auditbeat-*
+* endgame-*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.trendmicro.com/en_ca/research/20/l/teamtnt-now-deploying-ddos-capable-irc-bot-tntbotinger.html
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Collection
+* Tactic: Credential Access
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: SentinelOne
+* Data Source: Auditd Manager
+* 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 Sensitive Files Compression*
+
+
+Compression utilities like zip, tar, and gzip are essential for efficiently managing and transferring files. However, adversaries can exploit these tools to compress and exfiltrate sensitive data, such as SSH keys and configuration files. The detection rule identifies suspicious compression activities by monitoring process executions involving these utilities and targeting known sensitive file paths, thereby flagging potential data collection and credential access attempts.
+
+
+*Possible investigation steps*
+
+
+- Review the process execution details to identify the user account associated with the compression activity, focusing on the process.name and process.args fields.
+- Examine the command line arguments (process.args) to determine which specific sensitive files were targeted for compression.
+- Check the event.timestamp to establish a timeline and correlate with other potentially suspicious activities on the host.
+- Investigate the host's recent login history and user activity to identify any unauthorized access attempts or anomalies.
+- Analyze network logs for any outbound connections from the host around the time of the event to detect potential data exfiltration attempts.
+- Assess the integrity and permissions of the sensitive files involved to determine if they have been altered or accessed inappropriately.
+
+
+*False positive analysis*
+
+
+- Routine system backups or administrative tasks may trigger the rule if they involve compressing sensitive files for legitimate purposes. Users can create exceptions for known backup scripts or administrative processes by excluding specific process names or command-line arguments associated with these tasks.
+- Developers or system administrators might compress configuration files during development or deployment processes. To handle this, users can whitelist specific user accounts or directories commonly used for development activities, ensuring these actions are not flagged as suspicious.
+- Automated scripts or cron jobs that regularly archive logs or configuration files could be mistakenly identified as threats. Users should review and exclude these scheduled tasks by identifying their unique process identifiers or execution patterns.
+- Security tools or monitoring solutions that periodically compress and transfer logs for analysis might be misinterpreted as malicious. Users can exclude these tools by specifying their process names or paths in the detection rule exceptions.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration and unauthorized access.
+- Terminate any suspicious processes identified by the detection rule to halt ongoing compression and potential data exfiltration activities.
+- Conduct a thorough review of the compressed files and their contents to assess the extent of sensitive data exposure and determine if any data has been exfiltrated.
+- Change all credentials associated with the compromised files, such as SSH keys and AWS credentials, to prevent unauthorized access using stolen credentials.
+- Restore any altered or deleted configuration files from a known good backup to ensure system integrity and functionality.
+- 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 compression utilities and sensitive file access to detect and respond to similar threats more effectively in the future.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from one of the following integrations:
+- Elastic Defend
+- Auditbeat
+
+
+
+*Elastic Defend Integration Setup*
+
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows
+the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+
+
+*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide].
+- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide].
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide].
+
+
+*Auditbeat Setup*
+
+Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.
+
+
+*The following steps should be executed in order to add the Auditbeat on a Linux System:*
+
+- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
+- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide].
+- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide].
+- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide].
+- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.category:process and host.os.type:linux and event.type:start and
+event.action:("exec" or "exec_event" or "start" or "executed" or "process_started") and
+process.name:(zip or tar or gzip or hdiutil or 7z) and
+process.args:
+    (
+      /root/.ssh/id_rsa or
+      /root/.ssh/id_rsa.pub or
+      /root/.ssh/id_ed25519 or
+      /root/.ssh/id_ed25519.pub or
+      /root/.ssh/authorized_keys or
+      /root/.ssh/authorized_keys2 or
+      /root/.ssh/known_hosts or
+      /root/.bash_history or
+      /etc/hosts or
+      /home/*/.ssh/id_rsa or
+      /home/*/.ssh/id_rsa.pub or
+      /home/*/.ssh/id_ed25519 or
+      /home/*/.ssh/id_ed25519.pub or
+      /home/*/.ssh/authorized_keys or
+      /home/*/.ssh/authorized_keys2 or
+      /home/*/.ssh/known_hosts or
+      /home/*/.bash_history or
+      /root/.aws/credentials or
+      /root/.aws/config or
+      /home/*/.aws/credentials or
+      /home/*/.aws/config or
+      /home/*/.config/gcloud/credentials.db or
+      /home/*/.config/gcloud/access_tokens.db or
+      /home/*/.azure/credentials or
+      /root/.azure/credentials or
+      /root/.docker/config.json or
+      /home/*/.docker/config.json or
+      /root/.kube/config or
+      /home/*/.kube/config or
+      /etc/group or
+      /etc/passwd or
+      /etc/shadow or
+      /etc/gshadow
+    )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Unsecured Credentials
+** ID: T1552
+** Reference URL: https://attack.mitre.org/techniques/T1552/
+* Sub-technique:
+** Name: Credentials In Files
+** ID: T1552.001
+** Reference URL: https://attack.mitre.org/techniques/T1552/001/
+* Tactic:
+** Name: Collection
+** ID: TA0009
+** Reference URL: https://attack.mitre.org/tactics/TA0009/
+* Technique:
+** Name: Data from Local System
+** ID: T1005
+** Reference URL: https://attack.mitre.org/techniques/T1005/
+* Technique:
+** Name: Archive Collected Data
+** ID: T1560
+** Reference URL: https://attack.mitre.org/techniques/T1560/
+* Sub-technique:
+** Name: Archive via Utility
+** ID: T1560.001
+** Reference URL: https://attack.mitre.org/techniques/T1560/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-service-creation-via-local-kerberos-authentication.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-service-creation-via-local-kerberos-authentication.asciidoc
new file mode 100644
index 0000000000..f34116e381
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-service-creation-via-local-kerberos-authentication.asciidoc
@@ -0,0 +1,161 @@
+[[prebuilt-rule-8-19-24-service-creation-via-local-kerberos-authentication]]
+=== Service Creation via Local Kerberos Authentication
+
+Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to localhost, followed by service creation from the same LogonId. This may indicate an attempt to leverage a Kerberos relay attack variant that can elevate privileges locally from a domain-joined user to LocalSystem privileges.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/Dec0ne/KrbRelayUp
+* https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html
+* https://github.com/cube0x0/KrbRelay
+* https://gist.github.com/tyranid/c24cfd1bd141d14d4925043ee7e03c82
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Use Case: Active Directory Monitoring
+* Data Source: Active Directory
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 214
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Service Creation via Local Kerberos Authentication*
+
+
+*Possible investigation steps*
+
+
+- Do the source events show a loopback Kerberos logon followed by service creation in the same session?
+  - Why: sequence alerts merge fields; recover the 4624 and 4697 Timeline source events before interpreting grouped meaning.
+  - Focus: `winlog.computer_name`: 4624 `source.ip`, `winlog.logon.type`, `winlog.event_data.AuthenticationPackageName`, `winlog.event_data.TargetLogonId`; 4697 `winlog.event_data.SubjectLogonId`.
+  - Implication: escalate when loopback Kerberos network logon and 4697 service install share the same logon ID; lower suspicion when recovery shows no matching 4697, non-loopback source, or a different session.
+- Which identity received the elevated loopback Kerberos session?
+  - Focus: 4624 `winlog.event_data.TargetUserName`, `winlog.event_data.TargetDomainName`, `winlog.event_data.TargetUserSid`, `user.id`, and `winlog.event_data.ElevatedToken`; Subject fields are the local initiator, not the authenticated identity.
+  - Implication: escalate when the authenticated identity is an unexpected admin, service, or machine-account path for this host; lower suspicion only when the same identity and lab or deployment host cohort are recognized for this validation pattern.
+- What service did the recovered 4697 install?
+  - Focus: 4697 `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceAccount`, `winlog.event_data.ServiceStartType`, and `winlog.event_data.ServiceType`.
+  - Implication: escalate when the service uses a throwaway name, shell or script command, user-writable payload, or LocalSystem execution. Public tools may use "KrbSCM" or "UACBypassedService"; lower suspicion only when stable service metadata, account, and host cohort match the same authorized validation or owner-confirmed deployment workflow.
+- Do same-session Windows Security events show credential use, privilege activation, or additional service activity?
+  - Focus: same-host Windows Security events surrounding the sequence, keyed on `winlog.event_data.SubjectLogonId`; read 4624, 4648, and additional 4697 records. !{investigate{"description":"","label":"Windows Security events for the same logon session","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: query `winlog.computer_name` plus either recovered logon ID across the alert window first; expand only if source-event ordering is unclear.
+  - Hint: Missing authentication telemetry is unresolved, not benign.
+  - Implication: escalate when the same session shows explicit credentials or multiple service installs; keep scope local when evidence remains one recovered 4624-to-4697 chain with no contradictory activity.
+- If local evidence remains suspicious or unresolved, do related alerts show the same relay-to-service chain elsewhere?
+  - Focus: related alerts for `winlog.computer_name` in the last 48 hours that reuse the same service name or command, or show Kerberos or service-install abuse on this host. !{investigate{"description":"","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":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: compare `user.id` only if the host view does not show whether one operator or account cohort is involved. !{investigate{"description":"","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"}}
+  - Implication: broaden scope when related alerts show the same host or user preparing, reusing, or expanding the service-creation chain; keep response local when related-alert review is quiet and source events already resolve the case.
+- Escalate when source recovery confirms loopback Kerberos followed by suspicious LocalSystem service creation; close only when the session, identity, service metadata, and surrounding Windows Security evidence fit one exact benign activity with corroborating owner or test records when telemetry cannot prove legitimacy; preserve and escalate when evidence is mixed.
+
+
+*False positive analysis*
+
+
+- Authorized exploit validation, red-team work, or security research can reproduce this rule on lab systems. Confirm the 4624-to-4697 chain, `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `user.id`, and `winlog.computer_name` match test scope and timing. Without change or test records, close only when telemetry independently proves that validation scope; mark a one-off test as non-exceptionable instead of requiring recurrence.
+- Treat loopback Kerberos plus service creation as an operational anti-pattern outside authorized validation. A deployment or support claim is benign only when owner or runbook confirmation and source events prove this exact local SCM path, stable `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceAccount`, `user.id`, `winlog.computer_name`, and no relay-prerequisite or follow-on alerts.
+- Before creating an exception, pin `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceAccount`, `user.id`, and `winlog.computer_name`, and add an expiry or test-scope constraint for one-off validation. Avoid exceptions on loopback `source.ip`, event 4624, event 4697, or Kerberos alone because those conditions are broader than the confirmed workflow.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, preserve the source-event chain and service evidence that proved the authorized workflow, then reverse temporary containment. Create an exception only from the pinned workflow fields, with an expiry or test-scope constraint for one-off validation.
+- If suspicious but unconfirmed, preserve the Timeline source events, recovered logon IDs, loopback source, service metadata, and surrounding `event.code` "4648" evidence before containment. Apply reversible containment first: stop and disable the new service after evidence capture, temporarily restrict the implicated account if follow-on activity indicates active misuse, or isolate the host only when active compromise and host criticality justify interruption.
+- If confirmed malicious, preserve the service record and recovered source events, then isolate the host when feasible, disable and remove the malicious service, and reset or restrict the implicated account plus any machine-account, delegation, or certificate artifacts found during scoping. If direct response is unavailable, escalate with session IDs, service metadata, `source.ip`, `user.id`, and related-alert evidence to the team that can contain the system. Scope related hosts and identities for the same service name, service command, or loopback Kerberos pattern before cleanup.
+- Post-incident hardening: enforce LDAP signing and channel binding where possible, reduce ms-DS-MachineAccountQuota, protect privileged accounts from delegation, harden ADCS web enrollment with TLS and EPA if that path exists, and retain Windows Security logs long enough to reconstruct future 4624-to-4697 chains.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+The following Windows audit policies must be enabled to generate the events used by this rule:
+- https://ela.st/audit-logon[Audit Logon]
+- https://ela.st/audit-security-system-extension[Audit Security System Extension]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by winlog.computer_name with maxspan=5m
+ [authentication where host.os.type == "windows" and
+
+  /* event 4624 need to be logged */
+  event.action == "logged-in" and event.outcome == "success" and winlog.event_data.ElevatedToken == "%%1843" and process.pid == 0 and 
+
+  /* authenticate locally using relayed kerberos Ticket */
+  winlog.event_data.AuthenticationPackageName :"Kerberos" and winlog.logon.type == "Network" and cidrmatch(source.ip, "127.0.0.0/8", "::1")] by winlog.event_data.TargetLogonId
+
+  [any where host.os.type == "windows" and
+   /* event 4697 need to be logged */
+   event.action : "service-installed"] by winlog.event_data.SubjectLogonId
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Create or Modify System Process
+** ID: T1543
+** Reference URL: https://attack.mitre.org/techniques/T1543/
+* Sub-technique:
+** Name: Windows Service
+** ID: T1543.003
+** Reference URL: https://attack.mitre.org/techniques/T1543/003/
+* 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/
+* Technique:
+** Name: Steal or Forge Kerberos Tickets
+** ID: T1558
+** Reference URL: https://attack.mitre.org/techniques/T1558/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-cmd-execution-via-wmi.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-cmd-execution-via-wmi.asciidoc
new file mode 100644
index 0000000000..e4a417e61c
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-cmd-execution-via-wmi.asciidoc
@@ -0,0 +1,188 @@
+[[prebuilt-rule-8-19-24-suspicious-cmd-execution-via-wmi]]
+=== Suspicious Cmd Execution via WMI
+
+Identifies suspicious command execution (cmd) via Windows Management Instrumentation (WMI) on a remote host. This could be indicative of adversary lateral movement.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*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/operation-bleeding-bear
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Execution
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Windows Security Event Logs
+* Data Source: Microsoft Defender XDR
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 322
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Suspicious Cmd Execution via WMI*
+
+
+
+*Possible investigation steps*
+
+
+- Does the alert-local command line match the Impacket-style WMI output-capture shape?
+  - Focus: `process.command_line` for quiet execution, stdout/stderr redirection, temp or loopback admin-share output paths, `__*` names, and "-encodehex".
+  - Implication: escalate when WMI-brokered output capture writes to temp or loopback admin-share paths; lower concern only when the same exact capture shape recurs for one recognized RMM, SCCM, backup, or helpdesk workflow on this `host.id`.
+
+- Are "cmd.exe" and "WmiPrvSE.exe" the expected binaries in the expected launch context?
+  - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.executable`, and `process.parent.command_line`.
+  - Implication: escalate when either binary is unsigned, renamed, path-abnormal, or WMI broker context does not fit a management service; Microsoft-signed binaries reduce masquerade concern but do not clear output capture.
+
+- What operation does the captured command perform?
+  - Focus: `process.command_line` for nested interpreters, discovery commands, copy/archive tools, service or scheduled-task verbs, and defense-evasion tokens.
+  - Implication: escalate when the command stages execution, changes services or tasks, performs discovery at scale, invokes secondary interpreters or LOLBins, copies payloads, or hides output; lower concern for one bounded diagnostic or inventory command.
+
+- Does the user, host, and any session metadata fit controlled WMI administration?
+  - Focus: `user.id`, `user.domain`, `host.id`, `process.Ext.session_info.logon_type`, and `process.Ext.session_info.authentication_package`.
+  - Hint: when `process.Ext.authentication_id` or session details exist, pivot to same-host Windows Security 4624/4648 and match logon/session ID to recover source workstation, source IP, and account context. Missing authentication telemetry is unresolved, not benign.
+  - Hint: if session metadata is absent, decide from recurring `user.id`, `host.id`, parent executable, command line, child lineage, and related-alert pattern; missing session metadata is unresolved, not benign.
+  - Implication: escalate when a standard user, unusual domain context, network/service session, or unexpected NTLM context drives WMI command execution on this host; lower concern when the same account, host, and parent-command pattern recur as controlled administration.
+
+- Did the WMI-launched command become a launcher for follow-on execution?
+  - Focus: child process events from `process.entity_id`, reading child `process.name`, `process.executable`, and `process.command_line`. !{investigate{"description":"","label":"Child processes from WMI launched via Cmd.exe","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"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `process.entity_id` is missing, use `host.id` plus alert `process.pid` as child `process.parent.pid` in a tight alert window; treat this as weaker than entity-linked lineage.
+  - Implication: escalate when child processes include secondary interpreters, "rundll32.exe", "regsvr32.exe", "schtasks.exe", "sc.exe", copy tools, archivers, or other LOLBins; keep scope narrower when the cmd instance exits after one bounded command and no suspicious child appears.
+
+- If local process evidence stays suspicious or unresolved, do related alerts show the same user or host in lateral-movement activity?
+  - Focus: same-`user.id` alerts that reuse WMI output-capture fragments, WMI parentage, SMB, WinRM, service-install, scheduled-task, or matching command-line patterns. !{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 user view is quiet or ambiguous, compare same-`host.id` alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same user, host, or command pattern appears in adjacent remote-execution alerts; keep the case local when related alerts are absent and the local process evidence already explains the activity.
+
+- Escalate when output capture combines with suspicious identity, command intent, session, child, or related-alert evidence; close only when exact command shape, parent, user/host scope, child lineage, and recurrence bind to one recognized workflow on this `host.id`; preserve evidence and escalate when answers conflict or remain incomplete.
+
+
+*False positive analysis*
+
+
+- Remote-management, software distribution, backup, and helpdesk workflows can run "cmd.exe" through WMI and capture output to temp or loopback admin-share paths. Confirm only when parent executable, command line, `user.id`, `host.id`, process-side session context, and child behavior align with one workflow. Inventories, change records, and owner confirmation can corroborate but not replace telemetry; without them, require recurrence of the same anchors across prior alerts from this rule.
+- Bounded diagnostic WMI commands can be legitimate when an admin account runs one inventory or support command and the tree ends there. Do not close on Microsoft-signed "cmd.exe" or "WmiPrvSE.exe" alone; require exact output-capture shape, account, host scope, and no suspicious child processes to match the recognized workflow.
+- Build exceptions from the minimum confirmed pattern: stable `process.parent.executable`, specific output-capture command shape, `user.id`, and `host.id`. Avoid exceptions on `process.name`, "cmd.exe", "WmiPrvSE.exe", or temp-path fragments alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse any temporary containment and document the command, WMI broker path, account, host, session context, child-process result, and recurrence evidence that validated the workflow. Create an exception only for that same recurring pattern.
+- If suspicious but unconfirmed, export the alert, process tree, command line, parent context, child-process lineage, temp/admin-share output path fragments, and related-alert results before containment. Apply reversible containment first, such as heightened monitoring or temporary WMI restriction for the affected account or host where business impact permits; isolate the host only if child execution, destructive command intent, or related alerts suggest active compromise.
+- If confirmed malicious, isolate the host when its role can tolerate isolation, or terminate the alerting "cmd.exe" and malicious child processes only after preserving their command lines and entity IDs. Disable or rotate the affected credentials when user/session evidence or related alerts show account misuse.
+- After containment, remove only the temp outputs, staged payloads, services, scheduled tasks, or WMI persistence changes identified during the investigation, then verify no related alerts remain for the same `user.id`, `host.id`, or `process.command_line` pattern.
+- Post-incident hardening: restrict remote WMI to recognized admin hosts and accounts, reduce local administrator exposure, and retain process telemetry that distinguishes this output-capture pattern from adjacent WinRM or SMB service-based remote execution.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/crowdstrike-integration[CrowdStrike]
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+- https://ela.st/audit-process-creation[Windows Process Creation Logs]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+ process.parent.name : "WmiPrvSE.exe" and process.name : "cmd.exe" and process.args : "/c" and process.args:"/Q" and 
+ process.args : "2>&1" and process.args: "1>"  and 
+ process.args : ("C:\\windows\\temp\\*.txt", "\\Windows\\Temp\\*", "-encodehex", "\\\\127.0.0.1\\C$\\Windows\\Temp\\*", "\\\\127.0.0.1\\ADMIN$\\__*.*")
+
+----------------------------------
+
+*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/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: Windows Command Shell
+** ID: T1059.003
+** Reference URL: https://attack.mitre.org/techniques/T1059/003/
+* Tactic:
+** Name: Lateral Movement
+** ID: TA0008
+** Reference URL: https://attack.mitre.org/tactics/TA0008/
+* Technique:
+** Name: Remote Services
+** ID: T1021
+** Reference URL: https://attack.mitre.org/techniques/T1021/
+* Sub-technique:
+** Name: Distributed Component Object Model
+** ID: T1021.003
+** Reference URL: https://attack.mitre.org/techniques/T1021/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-execution-from-a-webdav-share.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-execution-from-a-webdav-share.asciidoc
new file mode 100644
index 0000000000..d322e531cd
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-execution-from-a-webdav-share.asciidoc
@@ -0,0 +1,202 @@
+[[prebuilt-rule-8-19-24-suspicious-execution-from-a-webdav-share]]
+=== Suspicious Execution from a WebDav Share
+
+Identifies attempts to execute or invoke content from remote WebDAV shares. Adversaries may abuse WebDAV paths, public tunnels, or host@port UNC paths to run tools or scripts while reducing local staging on the victim file system.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* endgame-*
+* logs-crowdstrike.fdr*
+* logs-endpoint.events.process-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-system.security*
+* logs-windows.forwarded*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Execution
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Windows Security Event Logs
+* Data Source: Microsoft Defender XDR
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 4
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Suspicious Execution from a WebDav Share*
+
+
+
+*Possible investigation steps*
+
+
+- Does the alert command line show direct WebDAV execution, and external delivery vs internal transfer?
+  - Focus: `process.command_line`, `process.name`, and `process.executable`; separate public tunnel or tenant paths from internal host@port UNC, "@SSL", "DavWWWRoot", or high-port paths.
+  - Implication: escalate when a script host, installer, shell, transfer tool, or net.exe points to public WebDAV content or an unrelated internal transfer host; lower concern when path maps to one recognized internal tenant, vendor, or deployment namespace for that role.
+
+- Do the launcher identity and parent lineage match that exact workflow?
+  - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.executable`, and `process.parent.command_line`.
+  - Implication: escalate when a signed utility proxies execution from a browser, Office app, chat client, archive tool, or unexplained service context. Public paths from user-facing parents suggest user delivery; internal host@port paths or net.exe share activity suggest lateral transfer. Lower concern when signer, parent, path, host, and user recur as one recognized collaboration, deployment, or support workflow; identity alone does not clear remote execution.
+
+- Did the alerting process spawn follow-on execution or share-mount activity?
+  - Focus: child or sibling process starts on `host.id` where `process.parent.entity_id` matches `process.entity_id`; check shells, downloaders, installers, schedulers, net.exe, or user-writable `process.executable` paths. !{investigate{"description":"","label":"Child process events from the WebDAV launcher","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `process.entity_id` is unavailable, use `host.id`, `process.pid`, and a tight alert-time window; PID lineage is weaker because of reuse.
+  - Implication: escalate when the launcher spawns download, install, persistence, or share-mapping tied to the same path; narrow scope when the chain ends cleanly inside one recognized workflow.
+
+- Did file telemetry show local staging or later execution from the WebDAV launch?
+  - Focus: if file telemetry exists, query `host.id` plus `process.entity_id` for `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and later starts where `process.executable` matches a written path. !{investigate{"description":"","label":"File events from the WebDAV launcher","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if WebDAV content is copied locally or to a mapped drive before execution, treat it as the same delivery chain and keep original-process scope.
+  - Range: start with the alert window; expand only after a suspicious write to confirm later execution.
+  - Implication: escalate when the chain writes scripts, installers, renamed payloads, or startup material in user-writable paths. Missing file telemetry is unresolved, not benign; direct WebDAV execution may leave few local artifacts.
+
+- Did DNS or connection telemetry confirm the WebDAV endpoint or delivery infrastructure?
+  - Focus: if network telemetry exists, separate DNS events (`dns.question.name`, `dns.resolved_ip`) from connection events (`destination.ip`, `destination.port`) for the same `host.id` and `process.entity_id`. !{investigate{"description":"","label":"Network events from the WebDAV launcher","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: use DNS lookup_result events to map `dns.resolved_ip` to later `destination.ip` before tying a domain to a connection. Missing network telemetry is unresolved, not benign.
+  - Implication: escalate when the process reaches public tunnels, rare external domains, high-port WebDAV services, or destinations unrelated to the signer and parent workflow; lower concern when the endpoint matches the command line's recognized tenant, internal share, or vendor.
+
+- If local evidence is suspicious or unresolved, do related alerts show the same WebDAV delivery or transfer pattern?
+  - Focus: related alerts for `user.id` over 48 hours, checking reused WebDAV path, launcher, destination, or follow-on artifact. !{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 user scope is quiet or ambiguous, check `host.id` for whether the path stays local or appears with other execution or download alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same path, domain, launcher, or artifact pattern appears beyond one recognized workflow; keep the case local when related-alert history is confined to that workflow.
+
+- Escalate on direct remote WebDAV execution plus suspicious launcher, lineage, child, artifact, destination, or related-alert evidence; close only when process evidence and recovery align to one exact recognized workflow; preserve and escalate when answers conflict or visibility is incomplete.
+
+
+*False positive analysis*
+
+
+- Tenant collaboration portals, internal WebDAV shares, and vendor content portals can trigger when `process.command_line` namespace, `process.parent.executable`, `process.executable`, signer, `user.id`, and `host.id` converge on one recognized workflow. Close only when telemetry shows parent, path, utility, user, and host stable across prior rule alerts and no child, artifact, or destination evidence contradicts the portal workflow. Use portal allowlists or owner records as corroboration, not substitutes.
+- Deployment or remote-support tooling can run msiexec.exe, powershell.exe, cmd.exe, or bitsadmin.exe against WebDAV-hosted packages. Confirm only when a management-agent or support-console parent, utility identity, signer, package namespace, written-artifact pattern, and host/user scope fit the same workflow. Public tunnel paths, renamed payloads, unexpected children, or one-off standard-user launches remain suspicious unless externally confirmed with no telemetry contradictions.
+- Before creating an exception, use the minimum confirmed workflow pattern: stable `process.code_signature.subject_name` or `process.executable`, `process.parent.executable`, specific `process.command_line` namespace or destination pattern, and proving `user.id` or `host.id` scope. Avoid exceptions on `process.name`, `user.name`, "@SSL", or "DavWWWRoot" alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and document the command-line namespace, parent launcher, utility identity, signer, available destination or artifact evidence, and `user.id` / `host.id` scope that validated the workflow. Create an exception only after the same scoped pattern is stable across prior rule alerts.
+- If suspicious but unconfirmed, preserve the alert export, process tree, `process.entity_id`, `process.command_line`, `process.parent.command_line`, remote path, staged artifacts, and destination indicators before containment. First apply reversible containment, such as temporarily blocking the confirmed WebDAV namespace or increasing monitoring on affected `host.id` and `user.id`; avoid termination or deletion until child execution, payload staging, or repeated suspicious destinations indicate active compromise.
+- If confirmed malicious, isolate the host when feasible or terminate the alerting process after evidence capture. If identity evidence suggests account misuse, contain or reset the affected account with identity owners. If direct endpoint response is unavailable, hand off preserved process, artifact, destination, host, and user evidence to the team able to contain the host or account.
+- Block confirmed malicious domains, destination IPs, hashes, executable paths, and staged artifact paths. Review other hosts and users for the same `process.parent.executable` plus `process.command_line` plus destination pattern, then remove only staged scripts, installers, startup material, or persistence changes tied to the chain.
+- Post-incident hardening: restrict unnecessary WebDAV and WebClient usage, limit direct execution from remote shares by script hosts and installers, use application control or attack surface reduction where feasible, retain file and network telemetry for this workflow, and document variants such as mapped-drive execution, copied-local execution, and alternate script-host launchers.
+
+
+==== 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 : ("cmd.exe", "powershell.exe", "conhost.exe", "wscript.exe", "mshta.exe", "curl.exe", "msiexec.exe", "bitsadmin.exe", "net.exe") and
+ process.command_line : ("*trycloudflare.com*", "*@SSL\\*", "*\\webdav\\*", "*\\DavWWWRoot\\*", "*\\\\*.*@8080\\*", "*\\\\*.*@80\\*", "*\\\\*.*@8443\\*", "*\\\\*.*@443\\*") and
+ not (process.name : "cmd.exe" and process.args : "\\\\?\\UNC\\*.sharepoint.com@SSL\\DavWWWRoot\\*")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: User Execution
+** ID: T1204
+** Reference URL: https://attack.mitre.org/techniques/T1204/
+* Sub-technique:
+** Name: Malicious File
+** ID: T1204.002
+** Reference URL: https://attack.mitre.org/techniques/T1204/002/
+* Tactic:
+** Name: 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/
+* 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-execution-from-inet-cache.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-execution-from-inet-cache.asciidoc
new file mode 100644
index 0000000000..097b7fe0e1
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-execution-from-inet-cache.asciidoc
@@ -0,0 +1,212 @@
+[[prebuilt-rule-8-19-24-suspicious-execution-from-inet-cache]]
+=== Suspicious Execution from INET Cache
+
+Identifies the execution of a process with arguments pointing to the INetCache Folder. Adversaries may deliver malicious content via WININET during initial access.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.trendmicro.com/en_us/research/24/b/cve202421412-water-hydra-targets-traders-with-windows-defender-s.html
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Initial Access
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Windows Security Event Logs
+* Data Source: Microsoft Defender XDR
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 213
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Suspicious Execution from INET Cache*
+
+
+
+*Possible investigation steps*
+
+
+- Did the alert execute a payload from INetCache, or did another process only reference cached content?
+  - Focus: `process.executable` and `process.command_line`, checking whether `AppData\Local\Microsoft\Windows\INetCache\IE` or `\Device\HarddiskVolume*\Users\*\INetCache\IE` is the image path, loader input, or only a document/image argument.
+  - Implication: escalate faster when the image runs from cache or feeds cached script, archive, shortcut, or DLL content to a loader; lower suspicion when the cache path is only a file argument to a recognized viewer and later lineage shows no execution.
+
+- Does identity and launch context fit a recognized file-opening, archive, or installer workflow?
+  - Focus: `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.executable`, and `process.parent.command_line`.
+  - Implication: escalate when identity, signer, path, or parent command line conflicts with Explorer/archive-manager file handling; lower suspicion only when identity and launcher context fit one coherent workflow. Identity alone does not clear cache execution.
+
+- Do launcher-scoped file events show a downloaded or disguised lure chain?
+  - Why: parent-scoped provenance distinguishes routine cache use from shortcut, archive, script, or DLL handoff.
+  - Focus: file events from the parent launcher via `process.parent.entity_id`; fallback to `host.id` plus parent PID and alert time, checking `file.path`, `file.origin_url`, `file.origin_referrer_url`, `file.Ext.windows.zone_identifier`, and `file.Ext.original.extension`. !{investigate{"description":"","label":"File events for the launcher process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when provenance shows internet delivery, deceptive extensions, shortcut-to-archive/script transitions, or renamed cache payloads. Missing file telemetry is unresolved, not benign.
+
+- Do process-scoped DNS or connection events show delivery or follow-on infrastructure?
+  - Why: network evidence separates local file-opening from remote retrieval, payload transfer, or follow-on command and control.
+  - Focus: DNS and connection events from `process.entity_id`; fallback to `host.id` plus `process.pid` and alert time, checking DNS `dns.question.name` and `dns.resolved_ip` plus connection `destination.ip` and `destination.port`. !{investigate{"description":"","label":"Network events for the executed 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"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: compare `lookup_result` DNS `dns.resolved_ip` values to connection `destination.ip` before judging infrastructure.
+  - Implication: escalate when the process reaches rare external, WebDAV-like, dotted-quad, or payload-transfer destinations that do not match file provenance; lower suspicion when destinations align with the same recognized vendor workflow. Missing network telemetry is unresolved, not benign.
+
+- Did the cached content lead to script, archive, DLL, or staged executable execution?
+  - Focus: child starts where `process.parent.entity_id` matches `process.entity_id`, checking child `process.name`, `process.executable`, and `process.command_line`. !{investigate{"description":"","label":"Child process starts from the cached-content process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if entity IDs are unavailable, use parent PID plus alert time as a weaker fallback.
+  - Implication: escalate when the chain quickly launches "cmd.exe", "powershell.exe", "rundll32.exe", "mshta.exe", "wscript.exe", "cscript.exe", or another staged executable; lower suspicion when the lineage stops at the original viewer, archiver, or installer.
+
+- If local evidence remains suspicious or unresolved after lineage review, is the same user or host part of broader delivery activity?
+  - Focus: `host.id`, `user.id`, and related alerts that repeat the same cache-path role, parent launcher, child-process family, recovered destination, or provenance pattern.
+  - Hint: pivot same-user alerts. !{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: pivot same-host alerts. !{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 containment when related alerts show the same lure or delivery pattern across the user or host; skip broadening when local evidence supports a coherent benign workflow or single-host containment.
+
+- Escalate on disguised/downloaded cache execution, loader handoff, suspicious infrastructure, or broader delivery; close only when process evidence and recovery bind one coherent benign workflow with no contradictions; when evidence is mixed or visibility incomplete, preserve artifacts and escalate.
+
+
+*False positive analysis*
+
+
+- Browser-driven installers, vendor updaters, and archive-based delivery can launch signed helpers from cache or reference cached installer content. Confirm `process.executable`, hash/signer, parent executable/command line, `user.id`, and `host.id` align with one recognized vendor workflow, and recovered provenance/destinations do not contradict it. Without deployment records, require recurring signer or hash, parent workflow, account, and host pattern without loader children or unrelated external delivery.
+- Archive preview, document viewing, or browser-open workflows can reference cached paths without executing a cached payload. Confirm `process.command_line` uses the cache path as a document, image, or shortcut argument, the parent workflow is stable for `user.id` and `host.id`, and recovered file, network, and child-process evidence lacks `.url/.lnk`, `.cmd/.bat/.js/.hta`, archive-to-script, or DLL-loader transitions.
+- Before creating an exception, validate recurrence across prior alerts from this rule with stable `process.executable`, signer or hash, `process.parent.executable`, cache-path role, `user.id`, and `host.id`. Avoid exceptions on INetCache alone, Explorer alone, archive-manager name alone, or a user alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and record the process identity, command line, parent workflow, account, host, and any recovered provenance or destination evidence that proved the benign workflow. Create an exception only for the recurring signer or hash, cache-path role, parent workflow, `user.id`, and `host.id` combination.
+- If suspicious but unconfirmed, preserve `process.entity_id`, `process.command_line`, parent/child lineage, runtime hash and signer, payload files, origin/referrer URLs, DNS names, destination IPs/ports, and related alert IDs before containment. Apply reversible containment first, such as temporary destination blocking or heightened monitoring for the affected `host.id` and `user.id`; isolate only when loader execution or network evidence suggests active payload delivery or command and control.
+- If confirmed malicious, preserve the same process, file, and network artifacts before destructive action. Isolate the endpoint when host criticality permits, block confirmed malicious domains, destinations, and hashes, collect suspicious payloads, then terminate processes or delete files only after scope and evidence capture are complete.
+- Eradicate only the shortcut, script, archive, DLL, extracted payload, startup item, or persistence artifact identified during the investigation. Verify the original browser-download, archive, WebDAV-like, or cache delivery path no longer reaches the host.
+- Post-incident hardening: retain the evidence set that proved the case, review SmartScreen, Mark-of-the-Web, WebDAV, archive-handling, and web-download controls for the affected host class, and record adjacent variants such as disguised `.url` lures, archive-extracted scripts, or cache-based DLL launchers in the case notes.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/crowdstrike-integration[CrowdStrike]
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+- https://ela.st/audit-process-creation[Windows Process Creation Logs]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+  process.parent.name : ("explorer.exe", "winrar.exe", "7zFM.exe", "Bandizip.exe") and
+  (
+    process.args : "*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\*" or
+    process.executable : (
+      "?:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\*",
+
+      /* Crowdstrike specific condition as it uses NT Object paths */
+      "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\*"
+    )
+  ) and
+  not process.executable : (
+        "?:\\Program Files\\*.exe",
+        "?:\\Program Files (x86)\\*.exe",
+        "?:\\Windows\\System32\\mspaint.exe",
+        "?:\\Windows\\System32\\notepad.exe",
+
+        /* Crowdstrike specific exclusion as it uses NT Object paths */
+        "\\Device\\HarddiskVolume*\\Program Files\\*.exe",
+        "\\Device\\HarddiskVolume*\\Program Files (x86)\\*.exe",
+        "\\Device\\HarddiskVolume*\\Windows\\System32\\mspaint.exe",
+        "\\Device\\HarddiskVolume*\\Windows\\System32\\notepad.exe"
+  )
+
+----------------------------------
+
+*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/
+* Tactic:
+** Name: Command and Control
+** ID: TA0011
+** Reference URL: https://attack.mitre.org/tactics/TA0011/
+* Technique:
+** Name: Ingress Tool Transfer
+** ID: T1105
+** Reference URL: https://attack.mitre.org/techniques/T1105/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: 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-24/prebuilt-rule-8-19-24-suspicious-execution-with-nodejs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-execution-with-nodejs.asciidoc
new file mode 100644
index 0000000000..3f835304d5
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-execution-with-nodejs.asciidoc
@@ -0,0 +1,193 @@
+[[prebuilt-rule-8-19-24-suspicious-execution-with-nodejs]]
+=== Suspicious Execution with NodeJS
+
+Identifies suspicious Node.js execution patterns, including user-writable runtimes, preload arguments, 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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://nodejs.org/api/child_process.html
+* 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*: 4
+
+*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 user-writable AppData "node.exe", 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") and
+
+(
+  (process.executable : ("?:\\Users\\*\\AppData\\*\\node.exe", "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\*\\node.exe") and process.args : "*.js") or
+
+  (process.args : "-r" and process.parent.name : "powershell.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-24/prebuilt-rule-8-19-24-suspicious-file-renamed-via-smb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-file-renamed-via-smb.asciidoc
new file mode 100644
index 0000000000..49568e2908
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-file-renamed-via-smb.asciidoc
@@ -0,0 +1,161 @@
+[[prebuilt-rule-8-19-24-suspicious-file-renamed-via-smb]]
+=== Suspicious File Renamed via SMB
+
+Identifies an incoming SMB connection followed by a suspicious file rename operation. This may indicate a remote ransomware attack via the SMB protocol.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.file-*
+* logs-endpoint.events.network-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://news.sophos.com/en-us/2023/12/21/akira-again-the-ransomware-that-keeps-on-taking/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Impact
+* Resources: Investigation Guide
+* Data Source: Elastic Defend
+
+*Version*: 8
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Suspicious File Renamed via SMB*
+
+
+*Possible investigation steps*
+
+
+- What do the Timeline member events show for the SMB-to-rename sequence?
+  - Focus: use `host.id` as target context; open Investigate in Timeline to recover accepted SMB `source.ip`, rename-event `user.id`, and representative renamed `file.path`.
+  - Implication: escalate on one remote SMB source followed by repeated high-entropy user-file renames; lower concern only when member events show one bounded remote file-management job with stable source, account, path, and extension mapping. Missing member events are unresolved, not benign.
+- Does the recovered source/account pair fit a recognized remote file-management workflow?
+  - Focus: recovered `source.ip`, `user.id`, `user.name`, and `user.domain`.
+  - Implication: escalate when a rare source or privileged account remotely renames user data; lower concern when the same source/account pair recurs as a backup, migration, DLP, or conversion actor for this exact share.
+- Do rename artifacts look like encryption instead of content conversion?
+  - Focus: same target host, SMB-server context, alert window, and recovered `user.id`: `file.Ext.original.extension`, `file.extension`, `file.Ext.entropy`, and `file.size`.
+  - Implication: escalate when common documents or images move to one unfamiliar high-entropy extension family across many paths; lower concern when before/after extensions and file sizes match a recognized converter, archive, or quarantine workflow.
+- How far did the rename burst spread on the target host?
+  - Focus: file rename events from the same target host, SMB-server context, recovered `user.id`, and surrounding window; compare `file.path` roots and `file.Ext.original.extension` families.
+  - Implication: escalate when the burst crosses user profiles, share roots, or document families; lower urgency when it stays a short bounded task in one managed folder with stable extension mapping.
+- Did the target receive ransom-note or payload files around the rename burst?
+  - Why: SMB ransomware may run from the remote source while leaving note or helper files on the target share, making target-side file artifacts decisive corroboration.
+  - Focus: file events on the same `host.id` around the rename window: repeated `file.name`, `file.path`, or `file.extension` patterns for note-like files, scripts, or executables. !{investigate{"description":"","label":"Recent file activity on this host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when repeated note-like names or executable/script drops appear in impacted paths; lower concern when file activity stays limited to the explained rename workflow.
+- Did recovery inhibition or destructive behavior align with the rename burst?
+  - Focus: related alerts on the same `host.id` around the rename window naming recovery inhibition, destructive file activity, or ransomware notes. !{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: escalate and prioritize containment when these alerts align; absence reduces urgency only after source/account and rename evidence fit one exact workflow.
+- If local findings remain suspicious or unresolved, does the same SMB source or account drive similar renames elsewhere?
+  - Focus: across hosts, look for the same recovered `source.ip` or `user.id` paired with inbound SMB accept events and high-entropy rename bursts using the suspicious `file.extension`.
+  - Implication: broaden containment when the same source or account drives similar user-file rename bursts on other hosts; keep scope local only when this pivot is quiet and local evidence is otherwise resolved.
+- Escalate when SMB source/account, rename shape, target breadth, note/payload artifacts, recovery-inhibition alerts, or cross-host spread show remote encryption or destructive file handling over SMB. Close only when recovered telemetry binds one exact backup, migration, DLP, or conversion job on this host, with owner or change records as corroboration only. Preserve evidence and escalate when telemetry is mixed, incomplete, or contradicted.
+
+
+*False positive analysis*
+
+
+- Backup, migration, DLP quarantine, or document-conversion tooling can rename many files over SMB. Confirm that recovered `source.ip`, `user.id`, managed `file.path` scope, extension mapping, and absence of note/payload or recovery-inhibition evidence all support the same workflow on this host. Use owner confirmation or change records only as corroboration; if unavailable, close only when recovered events independently bind one exact workflow.
+- Treat recurrence of the same source/account, folder scope, and extension mapping across prior alerts as candidate tuning evidence, not a standalone benign verdict. Build exceptions from the narrowest stable pattern: recovered `source.ip`, `user.id`, managed `file.path` scope, host cohort, and extension mapping. Do not except on SMB activity, `process.pid` 4, high entropy, rename volume, or one extension alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and document the source host, account, managed folder scope, and extension mapping that explained the rename burst. Create an exception only after the same bounded pattern recurs.
+- If suspicious but unconfirmed, preserve a Timeline export of the sequence member events, representative renamed files, any note or payload files, recovered SMB source/account details, and related alert IDs before containment that could alter evidence.
+- Apply reversible containment first: block SMB from the recovered source, suspend the recovered account session, or temporarily restrict write access to the impacted share. Isolate the source or target host only when active renaming or destructive corroborators show ongoing ransomware activity.
+- If confirmed malicious, isolate the source and impacted target or file server when the environment can tolerate it, disable and reset the recovered account, and stop active SMB sessions only after recording the source, account, renamed-file set, notes or payloads, and destructive alerts.
+- Review other hosts for the same `source.ip`, `user.id`, suspicious extension, or note pattern before restoration so the full ransomware scope is understood.
+- Restore renamed or encrypted files only from trusted backups or replicas after scope is complete, and verify backup repositories were not touched by the same source or account.
+- Post-incident hardening: restrict remote SMB write paths and administrative shares, require MFA or equivalent controls for remote access and high-privilege accounts, protect backup credentials, and retain file and network telemetry needed to recover future SMB rename sequences.
+
+==== 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=1s
+ [network where host.os.type == "windows" and
+  event.action == "connection_accepted" and destination.port == 445 and source.port >= 49152 and process.pid == 4 and
+  source.ip != "127.0.0.1" and source.ip != "::1" and
+  network.type == "ipv4" and not endswith(source.address, destination.address)]
+ [file where host.os.type == "windows" and
+  event.action == "rename" and process.pid == 4 and user.id : ("S-1-5-21*", "S-1-12-*") and
+  file.extension != null and file.Ext.entropy >= 6 and file.path : "C:\\Users\\*" and
+  file.Ext.original.name : ("*.jpg", "*.bmp", "*.png", "*.pdf", "*.doc", "*.docx", "*.xls", "*.xlsx", "*.ppt", "*.pptx", "*.lnk") and
+  not file.extension : ("jpg", "bmp", "png", "pdf", "doc", "docx", "xls", "xlsx", "ppt", "pptx", "lnk")] with runs=3
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Data Destruction
+** ID: T1485
+** Reference URL: https://attack.mitre.org/techniques/T1485/
+* Technique:
+** Name: Data Encrypted for Impact
+** ID: T1486
+** Reference URL: https://attack.mitre.org/techniques/T1486/
+* Technique:
+** Name: Inhibit System Recovery
+** ID: T1490
+** Reference URL: https://attack.mitre.org/techniques/T1490/
+* Tactic:
+** Name: Lateral Movement
+** ID: TA0008
+** Reference URL: https://attack.mitre.org/tactics/TA0008/
+* Technique:
+** Name: Remote Services
+** ID: T1021
+** Reference URL: https://attack.mitre.org/techniques/T1021/
+* Sub-technique:
+** Name: SMB/Windows Admin Shares
+** ID: T1021.002
+** Reference URL: https://attack.mitre.org/techniques/T1021/002/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-imagepath-service-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-imagepath-service-creation.asciidoc
new file mode 100644
index 0000000000..24fe985d01
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-imagepath-service-creation.asciidoc
@@ -0,0 +1,175 @@
+[[prebuilt-rule-8-19-24-suspicious-imagepath-service-creation]]
+=== Suspicious ImagePath Service Creation
+
+Identifies the creation of a suspicious ImagePath value. This could be an indication of an adversary attempting to stealthily persist or escalate privileges through abnormal service creation.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.registry-*
+* endgame-*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-crowdstrike.fdr*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Microsoft Defender XDR
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 315
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Suspicious ImagePath Service Creation*
+
+
+
+*Possible investigation steps*
+
+
+- What exact service "ImagePath" behavior did the alert preserve?
+  - Why: shell and pipe-backed service launches require different execution pivots.
+  - Focus: `registry.path`, `registry.key`, `registry.value`, `registry.data.type`, `registry.data.strings`.
+  - Implication: escalate when the value invokes the command interpreter, chains shell commands, or points to a local named pipe instead of a normal service executable; lower concern only when exact key and value match a recognized same-product service wrapper.
+
+- Who wrote the service value, and does that context fit service management?
+  - Focus: `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `user.id`.
+  - Hint: if the writer is "svchost.exe" or another broker, use `process.parent.executable` and broader lineage before attributing intent. !{investigate{"description":"","label":"Activity from this writer 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":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate for unsigned utilities, script hosts, remote-admin tools, unusual paths, or user contexts that do not fit service changes; lower concern only when signer, path, command line, and user fit a recognized installer or management agent.
+
+- Did the same writer change other values under the service key?
+  - Why: existing-service edits can preserve trust while changing start mode, account context, DLL loading, failure behavior, or security descriptor.
+  - Focus: same-`host.id` registry events scoped by service `registry.key`, reviewing `registry.value` and `registry.data.strings`. !{investigate{"description":"","label":"Registry events for the same service key","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"registry.key","queryType":"phrase","value":"{{registry.key}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when surrounding values make the service autostart, run privileged, load a DLL/parameter path, restart on failure, or become harder to enumerate; lower concern when the writer performs only one bounded product-owned service update.
+
+- Did the service path execute or spawn follow-on activity?
+  - Focus: later same-`host.id` process events where `process.executable` or `process.command_line` matches the recovered service value, plus `process.parent.executable` and lineage. !{investigate{"description":"","label":"Process starts on the host near the service change","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Range: start with the alert window; expand after `@timestamp` only to test delayed service start.
+  - Hint: for command-interpreter paths, search "cmd.exe" and recovered command fragments in `process.command_line`; for named-pipe paths, search "services.exe" lineage, helpers, or service-start failures instead of expecting a file-backed executable.
+  - Implication: escalate when service lineage launches a shell, pipe helper, or unexpected child soon after the write; do not close solely because execution is not visible, since the service may start later or fail during launch.
+
+- If execution occurred, does the launched process fit the expected service?
+  - Focus: recovered launch event: `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.pe.original_file_name`, `process.Ext.relative_file_creation_time`.
+  - Implication: escalate when the binary is unsigned, newly created, renamed, PE-mismatched, or unrelated to the writer signer; lower concern when identity, signer, age, and service value all fit the same recognized product.
+
+- What disposition do service value, writer, adjacent values, execution, and related alerts support?
+  - Hint: if local evidence remains suspicious or unresolved, review user- and host-scoped alerts.
+    - !{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: escalate when shell or named-pipe execution plus writer, adjacent value, execution, or alert context fails to fit one recognized workflow; close only when those categories converge on the exact service-management activity, using outside confirmation when telemetry cannot prove legitimacy; if evidence is mixed or incomplete, preserve registry and process evidence and escalate.
+
+
+*False positive analysis*
+
+
+- Software installation, repair, agent upgrade, remote-support, or deployment tooling can rewrite service "ImagePath" values or register short-lived helper services only when a signed installer, management component, vendor behavior, or internal test plan owns the service end-to-end. Confirm `process.executable`, signer/trust, `user.id`, `registry.key`, `registry.data.strings`, and later parent/command-line activity align with that workflow, not an ad hoc shell or pipe helper.
+- Shell or pipe "ImagePath" behavior is an anti-pattern unless the vendor or test plan accounts for that exact helper. Without records, require current-case telemetry that writer, signer, service key/value, `user.id`, `host.id`, later execution, and related alerts align without contradiction.
+- Before creating an exception, use prior alerts only to prove exception stability, not to close the case. Validate consistent service value, writer, user, host, and execution behavior across the same workflow. Treat a first occurrence as a candidate exception, not a suppression. Build the exception from the minimum confirmed pattern: writer signer and path, exact service key, exact `registry.data.strings`, `user.id`, and `host.id`. Avoid exceptions on `registry.value` = "ImagePath", "services.exe", or the rule name alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, preserve the case export and document the writer identity, exact service key and value, affected `user.id` and `host.id`, and later service-start behavior that proved the recognized workflow before reversing temporary containment. Keep any exception narrow and require recurrence of the same workflow pattern.
+- If suspicious but unconfirmed, preserve a case export of the triggering registry event, exact service key/value, writer process details, launched-process details, and volatile service state before containment. Then apply reversible containment tied to those findings, such as disabling the affected service, preventing the referenced command from starting, or isolating the host only after weighing service criticality. Escalate to account or broader host action only when related alerts or later execution show wider compromise.
+- If confirmed malicious, preserve the same registry and process evidence before destructive action. Disable and remove the malicious or hijacked service, restore the expected "ImagePath", quarantine the referenced executable or command artifact when present, and review the same `process.entity_id`, `registry.key`, and service lineage for additional unauthorized service changes before cleanup. Use endpoint response tooling to contain the host or terminate the recovered malicious process when available; if direct response is unavailable, escalate with the preserved identifiers to the team that can act.
+- After containment, review other hosts for the same `registry.data.strings`, service-key pattern, signer, hash, or command fragment before deleting artifacts, then verify that no additional services reference the same shell, named pipe, or staged payload.
+- Post-incident hardening: restrict service creation and service-registry writes to trusted installers and management tools, retain registry and process telemetry needed to correlate "ImagePath" changes to later execution, and record any adjacent service-abuse variant surfaced during 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/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+registry where host.os.type == "windows" and event.type == "change" and
+  registry.value : "ImagePath" and
+  registry.path : "*\\SYSTEM\\ControlSet*\\Services\\*\\ImagePath" and
+  /* add suspicious registry ImagePath values here */
+  registry.data.strings : ("%COMSPEC%*", "*\\.\\pipe\\*")
+
+----------------------------------
+
+*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: 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-24/prebuilt-rule-8-19-24-suspicious-javascript-execution-via-deno.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-javascript-execution-via-deno.asciidoc
new file mode 100644
index 0000000000..ae991c225d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-javascript-execution-via-deno.asciidoc
@@ -0,0 +1,188 @@
+[[prebuilt-rule-8-19-24-suspicious-javascript-execution-via-deno]]
+=== Suspicious JavaScript Execution via Deno
+
+Detects execution of JavaScript via Deno with suspicious command-line patterns (base64, eval, http, or import in a javascript context). Adversaries may abuse Deno to run malicious JavaScript for execution or staging.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* endgame-*
+* logs-crowdstrike.fdr*
+* logs-endpoint.events.process-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-system.security*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://reliaquest.com/blog/threat-spotlight-casting-a-wider-net-clickfix-deno-and-leaknets-scaling-threat
+* https://deno.com/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Execution
+* Resources: Investigation Guide
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Data Source: Microsoft Defender XDR
+* Data Source: Crowdstrike
+* Data Source: Elastic Endgame
+* Data Source: Windows Security Event Logs
+
+*Version*: 4
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Suspicious JavaScript Execution via Deno*
+
+
+
+*Possible investigation steps*
+
+
+- What execution mode and permission scope did Deno use?
+  - Focus: `process.command_line`: inline `eval(`, `data:application/javascript;base64`, remote `http` / `https`, inline JavaScript `import`, local `.js` / `.ts` targets, and broad `-A` or `--allow-*` flags.
+  - Implication: escalate faster when inline/base64 code or remote-code strings pair with broad permissions; lower concern only for a stable local task with narrow permissions. Treat `http` alone as unresolved until later evidence shows import, callback, or benign package retrieval.
+
+- Is the runtime the expected Deno binary and path?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted` for `Deno Land Inc.`, portable copies, renamed binaries, or user-writable paths.
+  - Implication: escalate when identity, signer, path, or hash history suggests a renamed or opportunistic runtime; lower concern when signed path and hash history match a managed install. Runtime identity never clears suspicious arguments.
+
+- Does launch lineage fit development/build or social-engineered execution?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, `host.name`, and child recovery; separate terminals, IDEs, and CI runners from VBS, PowerShell, MSI, browser, chat, or document launchers.
+  - Implication: escalate when Deno follows a script host, installer, browser, chat client, or document process on a non-developer endpoint; lower concern when user, host, parent, and command pattern match a recognized developer, build, or lab host.
+
+- Did Deno start follow-on processes?
+  - Focus: child events from `process.entity_id`; if absent, use `host.id`, `process.parent.pid`, and a tight alert window. Review child `process.executable`, `process.command_line`, and `process.hash.sha256`. !{investigate{"description":"","label":"Child process events from Deno","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when Deno spawns shells, downloaders, installers, schedulers, PsExec-like tools, `klist`, or other utilities; keep scope narrower when the tree ends at Deno and no suspicious child process appears.
+
+- Do DNS/network destinations fit the Deno command mode?
+  - Focus: DNS/network events for `process.entity_id`; if absent, use `host.id`, `process.pid`, and a tight alert window. Review `dns.question.name`, `dns.resolved_ip`, `destination.ip`, and `destination.port`. !{investigate{"description":"","label":"Network events from Deno","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: separate DNS lookups from connections, then map `dns.resolved_ip` to `destination.ip` before judging module source/callback fit.
+  - Implication: escalate when Deno reaches rare user/host domains, public hosting, new module sources, S3-like staging, or polling/C2 endpoints unrelated to the task; lower concern when traffic stays with recognized internal registries, package mirrors, or vendor services. Missing network telemetry is unresolved, not benign.
+
+- Did Deno stage scripts, modules, or persistence artifacts?
+  - Focus: file events for `process.entity_id`; if absent, use `host.id`, `process.pid`, and a tight alert window. Review `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and later `process.executable` reuse of written paths. !{investigate{"description":"","label":"File events from Deno","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Range: start with the alert window; after the first suspicious write, check later execution of that artifact.
+  - Implication: escalate when Deno writes scripts, binaries, cache content, or startup material into user-writable or persistence paths, or provenance shows internet delivery; lower concern when artifacts stay inside a recognized source tree, build workspace, or Deno cache expected for the command. Missing file telemetry is unresolved, not benign.
+
+- Do related alerts change scope?
+  - Focus: related alerts for the same `user.id` in 48 hours; compare Deno path, parent launcher, command mode, permission flags, and module or destination pattern. !{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 user scope is quiet or ambiguous, compare related alerts for the same `host.id` in 48 hours to see whether the pattern stays local or recurs in execution alerts. !{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 response when the same Deno path, flags, launcher, or remote-code pattern appears in other suspicious alerts; keep the case local only when local evidence fits one recognized workflow and alert history does not contradict it.
+
+- Escalate for broad permissions, abnormal lineage, follow-on execution, remote code retrieval, staging, repeated delivery, or related-alert expansion; close only when all evidence binds to one recognized developer, build, or lab workflow; preserve evidence and escalate on conflict or incomplete visibility.
+
+
+*False positive analysis*
+
+
+- Developer workstations and CI/build runners can legitimately use Deno. Confirm only when runtime identity, parent launcher, command/permission scope, and available DNS/network evidence align with the same repository, package registry, internal module host, or build workflow, with no suspicious child process or off-workspace artifact. Require available repository metadata, build definitions, or developer-host inventory; without them, do not close on recurrence alone. Use prior alerts only after alert-local and recovered evidence bind activity to one exact workflow, and require outside confirmation where telemetry cannot prove it.
+- Authorized lab or automation testing can use inline eval, remote imports, or data URLs, but should stay on lab/automation hosts with bounded permissions. Confirm only when broad `-A` or `--allow-all` is absent or test-harness-justified, the parent launcher fits that lab, file/network evidence shows no callback or staging, and `user.id` or `host.id` scope explains the activity.
+- Build exceptions from the minimum confirmed workflow: stable `process.executable` or `process.code_signature.subject_name`, `process.parent.executable`, exact `process.command_line` permission/import pattern, and proven `user.id` or `host.id` scope. Avoid exceptions on `process.name`, `user.name`, `deno.exe`, signer, or broad permission flags alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and record evidence proving the workflow: runtime identity, command mode and permissions, parent launcher, `user.id` / `host.id` scope, and available destination or artifact evidence. Create an exception only after that same narrow workflow recurs across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve the alert document, process tree, exact command line, parent and child process events, Deno cache/workspace artifacts, and available file/DNS/network records before containment. Apply reversible containment first: temporary blocking of the confirmed module or callback destination, heightened monitoring on affected `host.id` and `user.id`, or host isolation only when follow-on execution, payload staging, or repeated suspicious destinations indicate active compromise and asset tolerates isolation.
+- If confirmed malicious, isolate the host when operationally tolerable or terminate Deno only after preserving volatile process evidence. Block confirmed malicious domains, IPs, hashes, executable paths, and staged artifact paths; then review hosts/users for the same parent launcher, Deno command mode, permission pattern, and destination set before removing staged scripts, unauthorized Deno runtimes, startup material, scheduled tasks, or persistence tied to the chain.
+- Post-incident hardening: restrict Deno to recognized developer, build, and lab hosts; review whether `-A` or broad `--allow-*` permissions are necessary; retain process plus file/network telemetry needed for triage; and record adjacent variants such as `data:` URLs, remote `https:` imports, `npm:` / `jsr:` modules, and Deno launched from script hosts with the case outcome.
+
+
+==== 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 : "deno.exe" or ?process.pe.original_file_name == "deno.exe" or ?process.code_signature.subject_name == "Deno Land Inc.") and
+ process.command_line : ("*javascript*base64*", "*eval(*", "*http*", "*javascript*import*")
+
+----------------------------------
+
+*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: 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-kerberos-authentication-ticket-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-kerberos-authentication-ticket-request.asciidoc
new file mode 100644
index 0000000000..0167fcb47f
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-kerberos-authentication-ticket-request.asciidoc
@@ -0,0 +1,206 @@
+[[prebuilt-rule-8-19-24-suspicious-kerberos-authentication-ticket-request]]
+=== Suspicious Kerberos Authentication Ticket Request
+
+Correlates network connections to the standard Kerberos port by an unusual process from the source machine with a Kerberos authentication ticket request from the target domain controller.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.network-*
+* logs-windows.sysmon_operational-*
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/its-a-feature/bifrost
+* https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768
+* https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769
+
+*Tags*: 
+
+* Domain: Endpoint
+* Domain: Identity
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Lateral Movement
+* Use Case: Active Directory Monitoring
+* Data Source: Active Directory
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 5
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Suspicious Kerberos Authentication Ticket Request*
+
+
+
+*Possible investigation steps*
+
+
+- Which Timeline member events define this Kerberos sequence?
+  - Focus: Timeline members keyed by alert `source.ip` and `source.port`; recover source `process.executable`, Kerberos `destination.ip`, and auth `event.code`.
+  - Hint: record `host.id` and `process.entity_id`; verify auth `winlog.computer_name` is the DC.
+  - Implication: escalate when one non-"lsass.exe" source process maps to a DC "4768" or "4769" event in the sequence window; lower concern for socket reuse, a different process, or non-DC destination.
+
+- Is the recovered source process a recognized Kerberos-capable client?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Hint: open process start with recovered `host.id` and `process.entity_id`; if absent, use `host.id`, `process.pid`, and sequence window.
+  - Implication: escalate when the binary is unsigned, renamed, user-writable, signer-mismatched, or outside known AD audit, Kerberos diagnostic, or security-test tooling; lower concern only when path, signer, hash history, command, and parent converge on one known tool.
+
+- Does command-line and parentage show ticket-tool intent?
+  - Focus: recovered `process.command_line`, `process.parent.executable`, `process.parent.command_line`, and broader process lineage when needed.
+  - Implication: escalate on Bifrost-like verbs or flags such as asktgt, asktgs, s4u, ptt, kerberoast, service/SPN targets, hashes, keytabs, RC4, or base64 tickets, especially from shell or script parents; bounded diagnostics from a recognized admin tool reduce but do not clear concern.
+
+- Which ticket path and target account did the DC member event show?
+  - Focus: recovered auth `event.code`, `winlog.event_data.TargetUserName`, and `winlog.event_data.TargetDomainName`.
+  - Implication: escalate when "4769" shows service-ticket activity or "4768" shows TGT handling for privileged, service, machine, or delegation-sensitive targets from the unusual process; fan-out increases concern.
+
+- Does the source user and session context fit one bounded admin or audit source?
+  - Focus: recovered `user.id`, `user.name`, `user.domain`, and `winlog.event_data.TargetUserName`.
+  - Implication: escalate when privileged, service, or user-account tickets originate from a workstation, user session, or non-management tool; lower concern only when source host, user, process identity, command/parent, and target account recur as one bounded Kerberos diagnostic or audit pattern.
+
+- Do surrounding Kerberos events show repetition or account fan-out?
+  - Focus: same-source Kerberos network and authentication events, checking additional "4768"/"4769" events and `winlog.event_data.TargetUserName`.
+    - !{investigate{"description":"","label":"Kerberos network events from the same source IP","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"destination.port","queryType":"phrase","value":"88","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Authentication events for the same source IP","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"authentication","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when requests repeat or fan out across accounts; a single bounded request narrows scope but does not close if process identity or command intent remains suspicious. Missing network or authentication telemetry is unresolved, not benign.
+
+- Do later logon or explicit-credential events suggest ticket use?
+  - Focus: same-source authentication results, checking later `event.code` "4624"/"4648", `winlog.event_data.TargetUserName`, and 4648 `winlog.event_data.TargetServerName`.
+  - Implication: escalate when post-ticket logon or explicit-credential activity reaches sensitive accounts or servers from the same source; absence narrows impact but does not close if the ticket request remains suspicious. Missing same-source authentication telemetry leaves ticket use unresolved, not benign.
+
+- If local evidence remains suspicious or unresolved, does the same source show related alerts?
+  - Focus: related alerts for `source.ip`; manually pivot on recovered `process.hash.sha256` or `winlog.event_data.TargetUserName` when locally suspicious. !{investigate{"description":"","label":"Alerts associated with the same source IP","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when credential-access, Kerberoasting, relay, or lateral-movement alerts share the source, process, or target account; keep local only when related alerts are absent and recovered evidence resolves cleanly.
+
+- Escalate when sequence recovery, source-process identity, command intent, DC ticket target, account context, or surrounding ticket/logon activity show unauthorized direct Kerberos; close only when telemetry binds one recognized tool, source host, user, and target account and outside confirmation verifies exact activity when telemetry cannot; preserve and escalate when visibility is incomplete or evidence conflicts.
+
+
+*False positive analysis*
+
+
+- AD audit tools, Kerberos diagnostics, interoperability testing, or security testing can request tickets directly instead of through "lsass.exe". Confirm only when process path, signer/hash, parent, command line, `source.ip`, `user.id`, `event.code`, and target account align with the same recognized tool on a dedicated admin, lab, or audit source; without outside records, require the same process identity, source host/user, target account, and bounded ticket pattern across prior alerts from this rule.
+- Treat partial matches as unresolved when process identity fits but the command targets unusual SPNs, privileged accounts, RC4/kerberoast behavior, or follow-on "4624"/"4648" activity. Do not close on signer, source IP, or event code alone when ticket target or command intent contradicts benign workflow.
+- Before creating an exception, anchor it to the minimum stable workflow: dedicated `source.ip` or source host, process signer/hash/path, parent workflow, `user.id`, target account, and bounded `event.code` pattern. Avoid exceptions on `source.port`, `event.code`, process name, or broad account patterns alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and document the recovered source host/IP, process identity, command line, source user, DC ticket event, and target account that proved the recognized workflow. Create an exception only after the same dedicated source and process pattern recurs consistently.
+- If suspicious but unconfirmed, preserve the alert, Timeline member events, suspicious process binary and command line, source socket, DC authentication record, and any follow-on "4624" or "4648" evidence before containment or process action.
+- Apply reversible containment next: restrict the recovered source host's Kerberos/DC access or isolate the host when its role tolerates isolation, and suspend the recovered process only after process and authentication artifacts are captured.
+- If confirmed malicious, isolate the recovered source host, terminate or suspend the recovered process after recording its `process.entity_id`, expire exposed Kerberos tickets where operationally appropriate, and reset or rotate impacted credentials, prioritizing privileged, service, machine, and delegation-capable accounts.
+- Before cleanup, search for the same source IP, recovered process hash, target account, and related credential-access, Kerberoasting, relay, or lateral-movement activity so scope is not limited to the first sequence.
+- After containment, retain DC "4768"/"4769" auditing and endpoint network telemetry, restrict direct Kerberos tooling to controlled admin/testing hosts, and document the recovered tool pattern and any logging gaps in the case record.
+
+
+==== 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-3-setup[Sysmon Event ID 3 - Network Connection]
+- https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-kerberos-authentication-service[Audit Kerberos Authentication Service]
+- https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-kerberos-service-ticket-operations[Audit Kerberos Service Ticket Operations]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by source.port, source.ip with maxspan=3s
+ [network where host.os.type == "windows" and destination.port == 88 and
+  process.executable != null and process.pid != 4 and 
+  not process.executable : (
+        "?:\\Windows\\system32\\lsass.exe",
+        "\\device\\harddiskvolume*\\windows\\system32\\lsass.exe",
+        "\\device\\harddiskvolume*\\windows\\system32\\svchost.exe"
+  ) and
+  not (
+    process.executable : (
+      "C:\\Windows\\System32\\svchost.exe",
+      "C:\\Program Files\\VMware\\VMware View\\Server\\bin\\ws_TomcatService.exe",
+      "C:\\Program Files\\Omnissa\\Horizon\\Server\\bin\\ws_TomcatService.exe",
+      "F:\\IGEL\\RemoteManager\\*\\bin\\tomcat10.exe"
+    ) and
+    user.id in ("S-1-5-20", "S-1-5-18")
+  ) and   
+  source.ip != "127.0.0.1" and destination.ip != "::1" and destination.ip != "127.0.0.1"]
+ [authentication where host.os.type == "windows" and event.code in ("4768", "4769")]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Lateral Movement
+** ID: TA0008
+** Reference URL: https://attack.mitre.org/tactics/TA0008/
+* Technique:
+** Name: Use Alternate Authentication Material
+** ID: T1550
+** Reference URL: https://attack.mitre.org/techniques/T1550/
+* Sub-technique:
+** Name: Pass the Ticket
+** ID: T1550.003
+** Reference URL: https://attack.mitre.org/techniques/T1550/003/
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Steal or Forge Kerberos Tickets
+** ID: T1558
+** Reference URL: https://attack.mitre.org/techniques/T1558/
+* Sub-technique:
+** Name: Kerberoasting
+** ID: T1558.003
+** Reference URL: https://attack.mitre.org/techniques/T1558/003/
+* Sub-technique:
+** Name: AS-REP Roasting
+** ID: T1558.004
+** Reference URL: https://attack.mitre.org/techniques/T1558/004/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-macos-ms-office-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-macos-ms-office-child-process.asciidoc
new file mode 100644
index 0000000000..6b70927897
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-macos-ms-office-child-process.asciidoc
@@ -0,0 +1,259 @@
+[[prebuilt-rule-8-19-24-suspicious-macos-ms-office-child-process]]
+=== Suspicious macOS MS Office Child Process
+
+Identifies suspicious child processes of frequently targeted Microsoft Office applications (Word, PowerPoint, and Excel). These child processes are often launched during exploitation of Office applications or by documents with malicious macros.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://blog.malwarebytes.com/cybercrime/2017/02/microsoft-office-macro-malware-targets-macs/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: macOS
+* Use Case: Threat Detection
+* Tactic: Initial Access
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 213
+
+*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 macOS MS Office Child Process*
+
+
+Microsoft Office applications on macOS can be exploited by adversaries to execute malicious child processes, often through malicious macros or document exploits. These child processes may include scripting languages or utilities that can be leveraged for unauthorized actions. The detection rule identifies such suspicious activity by monitoring for unexpected child processes spawned by Office apps, while filtering out known benign behaviors and false positives, thus helping to pinpoint potential threats.
+
+
+*Possible investigation steps*
+
+
+- Review the parent process name and executable path to confirm if the Office application is legitimate and expected on the host.
+- Examine the child process name and command line arguments to identify any potentially malicious or unexpected behavior, such as the use of scripting languages or network utilities like curl or nscurl.
+- Check the process arguments for any indicators of compromise or suspicious patterns that are not filtered out by the rule, such as unexpected network connections or file modifications.
+- Investigate the effective parent executable path to ensure it is not associated with known benign applications or services that are excluded by the rule.
+- Correlate the alert with any recent phishing attempts or suspicious email activity that might have led to the execution of malicious macros or document exploits.
+- Analyze the host's recent activity and system logs to identify any other anomalies or related alerts that could provide additional context or evidence of compromise.
+
+
+*False positive analysis*
+
+
+- Product version discovery commands can trigger false positives. Exclude processes with arguments like "ProductVersion" and "ProductBuildVersion" to reduce noise.
+- Office error reporting may cause alerts. Exclude paths related to Microsoft Error Reporting to prevent unnecessary alerts.
+- Network setup and management tools such as "/usr/sbin/networksetup" can be benign. Exclude these executables if they are part of regular system operations.
+- Third-party applications like ToDesk and JumpCloud Agent might be flagged. Exclude their executables if they are verified as safe and part of normal operations.
+- Zotero integration can cause false positives with shell processes. Exclude specific command lines involving "CFFIXED_USER_HOME/.zoteroIntegrationPipe" to avoid these alerts.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected macOS device from the network to prevent further malicious activity or lateral movement.
+- Terminate any suspicious child processes identified by the alert, such as those involving scripting languages or utilities like curl, bash, or osascript.
+- Conduct a thorough review of the parent Microsoft Office application and associated documents to identify and remove any malicious macros or document exploits.
+- Restore the affected system from a known good backup if malicious activity has compromised system integrity or data.
+- Update all Microsoft Office applications to the latest version to patch any known vulnerabilities that could be exploited by similar threats.
+- Implement application whitelisting to restrict the execution of unauthorized scripts and utilities, reducing the risk of exploitation through Office applications.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from Elastic Defend.
+
+
+*Elastic Defend Integration Setup*
+
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+
+
+*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide].
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide].
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where event.action == "exec" and host.os.type == "macos" and
+    process.parent.name: (
+      "Microsoft Word",
+      "Microsoft Outlook",
+      "Microsoft Excel",
+      "Microsoft PowerPoint",
+      "Microsoft OneNote"
+    ) and
+  process.name : (
+    "curl",
+    "nscurl",
+    "bash",
+    "sh",
+    "osascript",
+    "python*",
+    "perl*",
+    "mktemp",
+    "chmod",
+    "php",
+    "nohup",
+    "openssl",
+    "plutil",
+    "PlistBuddy",
+    "xattr",
+    "mktemp",
+    "sqlite3",
+    "funzip",
+    "popen"
+  ) and
+
+  // Filter FPs related to product version discovery and Office error reporting behavior
+  not process.args:
+    (
+      "ProductVersion",
+      "hw.model",
+      "ioreg",
+      "ProductName",
+      "ProductUserVisibleVersion",
+      "ProductBuildVersion",
+      "/Library/Application Support/Microsoft/MERP*/Microsoft Error Reporting.app/Contents/MacOS/Microsoft Error Reporting",
+      "open -a Safari *",
+      "defaults read *",
+      "sysctl hw.model*",
+      "ioreg -d2 -c IOPlatformExpertDevice *",
+      "ps aux | grep 'ToDesk_Desktop' | grep -v grep",
+      "PIPE=\"$CFFIXED_USER_HOME/.zoteroIntegrationPipe*"
+    ) and
+
+   not process.parent.executable :
+        (
+          "/Applications/ToDesk.app/Contents/MacOS/ToDesk_Service",
+          "/usr/local/Privacy-i/PISupervisor",
+          "/Library/Addigy/lan-cache",
+          "/Library/Elastic/Agent/*",
+          "/opt/jc/bin/jumpcloud-agent",
+          "/usr/sbin/networksetup"
+        ) and
+   not (process.name : "sh" and process.command_line : "*$CFFIXED_USER_HOME/.zoteroIntegrationPipe*") and
+
+   not process.Ext.effective_parent.executable : (
+        "/Applications/ToDesk.app/Contents/MacOS/ToDesk_Service",
+        "/usr/local/Privacy-i/PISupervisor",
+        "/Library/Addigy/auditor",
+        "/Library/Elastic/Agent/*",
+        "/opt/jc/bin/jumpcloud-agent",
+        "/usr/sbin/networksetup"
+      ) and
+    not (
+      process.name in ("sh", "bash") and
+      process.command_line like "*com.microsoft.Outlook/Data/tmp/Outlook*Temp*" and
+      process.parent.executable in (
+        "/Applications/Microsoft Outlook.app/Contents/MacOS/Microsoft Outlook",
+        "/Applications/Microsoft Outlook 2.app/Contents/MacOS/Microsoft Outlook",
+        "/Applications/Microsoft/Microsoft Outlook.app/Contents/MacOS/Microsoft Outlook"
+      )
+    )
+
+----------------------------------
+
+*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/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: AppleScript
+** ID: T1059.002
+** Reference URL: https://attack.mitre.org/techniques/T1059/002/
+* Sub-technique:
+** Name: Unix Shell
+** ID: T1059.004
+** Reference URL: https://attack.mitre.org/techniques/T1059/004/
+* Sub-technique:
+** Name: Python
+** ID: T1059.006
+** Reference URL: https://attack.mitre.org/techniques/T1059/006/
+* Technique:
+** Name: Exploitation for Client Execution
+** ID: T1203
+** Reference URL: https://attack.mitre.org/techniques/T1203/
+* 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-24/prebuilt-rule-8-19-24-suspicious-module-loaded-by-lsass.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-module-loaded-by-lsass.asciidoc
new file mode 100644
index 0000000000..bf80670231
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-module-loaded-by-lsass.asciidoc
@@ -0,0 +1,229 @@
+[[prebuilt-rule-8-19-24-suspicious-module-loaded-by-lsass]]
+=== Suspicious Module Loaded by LSASS
+
+Identifies LSASS loading an unsigned or untrusted DLL. Windows Security Support Provider (SSP) DLLs are loaded into LSSAS process at system start. Once loaded into the LSA, SSP DLLs have access to encrypted and plaintext passwords that are stored in Windows, such as any logged-on user's Domain password or smart card PINs.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.library-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://blog.xpnsec.com/exploring-mimikatz-part-2/
+* https://github.com/jas502n/mimikat_ssp
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 15
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Suspicious Module Loaded by LSASS*
+
+
+The Local Security Authority Subsystem Service (LSASS) is crucial for managing security policies and handling user authentication in Windows environments. Adversaries exploit LSASS by loading malicious or untrusted DLLs to access sensitive credentials. The detection rule identifies such threats by monitoring LSASS for unsigned or untrusted DLLs, excluding known safe signatures and hashes, thus flagging potential credential dumping activities.
+
+
+*Possible investigation steps*
+
+
+- Review the process details for lsass.exe to confirm the presence of any unsigned or untrusted DLLs loaded into the process. Pay particular attention to the DLL's code signature status and hash values.
+- Cross-reference the identified DLL's hash against known malicious hashes in threat intelligence databases to determine if it is associated with any known threats.
+- Investigate the source and path of the suspicious DLL to understand how it was introduced into the system. This may involve checking recent file creation or modification events in the system directories.
+- Analyze the system's event logs for any related activities or anomalies around the time the suspicious DLL was loaded, such as unusual user logins or privilege escalation attempts.
+- Check for any recent changes in the system's security settings or policies that might have allowed the loading of untrusted DLLs into LSASS.
+- If the DLL is confirmed to be malicious, isolate the affected system to prevent further credential access or lateral movement within the network.
+
+
+*False positive analysis*
+
+
+- Legitimate software from trusted vendors not included in the exclusion list may trigger false positives. Users can update the exclusion list with additional trusted signatures or hashes from verified vendors to prevent these alerts.
+- Custom or in-house developed DLLs used within the organization might be flagged as suspicious. Organizations should ensure these DLLs are signed with a trusted certificate and add their signatures to the exclusion list if necessary.
+- Security software updates or patches from vendors not currently listed may cause false positives. Regularly review and update the exclusion list to include new trusted signatures from security software providers.
+- Temporary or expired certificates for legitimate DLLs can result in false positives. Users should verify the legitimacy of these DLLs and update the exclusion list with their signatures if they are confirmed safe.
+- DLLs from newly installed software that are not yet recognized as trusted may be flagged. Users should validate the software's source and add its signatures to the exclusion list if it is deemed secure.
+
+
+*Response and remediation*
+
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the LSASS process if it is confirmed to be running a malicious or untrusted DLL, ensuring that this action does not disrupt critical services.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants.
+- Review and reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges.
+- Implement application whitelisting to prevent unauthorized DLLs from being loaded into critical processes like LSASS in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Update security monitoring tools to enhance detection capabilities for similar threats, ensuring that alerts are generated for any future attempts to load untrusted DLLs into LSASS.
+
+==== 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]
+----------------------------------
+library where host.os.type == "windows" and event.action == "load" and
+  process.executable : "?:\\Windows\\System32\\lsass.exe" and
+  not (
+        dll.code_signature.subject_name : (
+            "Algorithmic Research LTD.",
+            "Amazon Web Services, Inc.",
+            "Apple Inc.",
+            "Audinate Pty Ltd",
+            "AuriStor, Inc.",
+            "Bit4id",
+            "Carbon Black, Inc.",
+            "Check Point Software Technologies Ltd.",
+            "Citrix Systems, Inc.",
+            "CyberArk Software Ltd.",
+            "Dell Inc",
+            "DigitalPersona, Inc.",
+            "EasyAntiCheat Oy",
+            "Entrust Corporation",
+            "Entrust Datacard Corporation",
+            "Entrust, Inc.",
+            "F5 Networks Inc",
+            "Fortinet, Inc.",
+            "Fortinet Technologies (Canada) Inc.",
+            "FrontRange Solutions Deutschland GmbH",
+            "GEMALTO SA",
+            "gemalto",
+            "Hewlett-Packard Company",
+            "HID Global",
+            "HID Global Corporation",
+            "HYPR Corp",
+            "IDEMIA IDENTITY & SECURITY FRANCE SAS",
+            "IDEMIA France SAS",
+            "Intel(R) Software Development Products",
+            "Istituto Poligrafico e Zecca dello Stato S.p.A.",
+            "LogMeIn, Inc.",
+            "McAfee, Inc.",
+            "McAfeeSysPrep",
+            "Micro Focus (US), Inc.",
+            "Micro Focus International plc",
+            "Microsoft Corporation",
+            "Microsoft Windows",
+            "Microsoft Windows Hardware Compatibility Publisher",
+            "Microsoft Windows Publisher",
+            "Microsoft Windows Software Compatibility Publisher",
+            "Morphisec Information Security 2014 Ltd",
+            "Musarubra US LLC",
+            "National Instruments Corporation",
+            "Novell, Inc.",
+            "Nubeva Technologies Ltd",
+            "NVIDIA Corporation PE Sign v2016",
+            "Palo Alto Networks (Netherlands) B.V.",
+            "Parallels International GmbH",
+            "PGP Corporation",
+            "QUEST SOFTWARE INC.",
+            "SecMaker AB",
+            "Secure Endpoints, Inc.",
+            "SecureLink, Inc.",
+            "SentinelOne Inc.",
+            "SentryBay Limited",
+            "Sophos Ltd",
+            "Symantec Corporation",
+            "Thales DIS CPL USA, Inc.",
+            "Tidexa OU",
+            "Trend Micro, Inc.",
+            "VMware, Inc.",
+            "Yubico AB"
+        ) and
+        dll.code_signature.status : ("trusted", "errorExpired", "errorCode_endpoint*", "errorChaining")
+  ) and
+
+  not dll.hash.sha256 : (
+          "811a03a5d7c03802676d2613d741be690b3461022ea925eb6b2651a5be740a4c",
+          "1181542d9cfd63fb00c76242567446513e6773ea37db6211545629ba2ecf26a1",
+          "ed6e735aa6233ed262f50f67585949712f1622751035db256811b4088c214ce3",
+          "26be2e4383728eebe191c0ab19706188f0e9592add2e0bf86b37442083ae5e12",
+          "9367e78b84ef30cf38ab27776605f2645e52e3f6e93369c674972b668a444faa",
+          "d46cc934765c5ecd53867070f540e8d6f7701e834831c51c2b0552aba871921b",
+          "0f77a3826d7a5cd0533990be0269d951a88a5c277bc47cff94553330b715ec61",
+          "4aca034d3d85a9e9127b5d7a10882c2ef4c3e0daa3329ae2ac1d0797398695fb",
+          "86031e69914d9d33c34c2f4ac4ae523cef855254d411f88ac26684265c981d95",
+          "4af1fee3369d9a993a84f54eafb72a661633c33e9e12fb3dd151a6a2cddbd404"
+  ) and
+  not dll.path : (
+        "C:\\Windows\\System32\\CertPolEng.dll",
+        "C:\\Windows\\System32\\FWPUCLNT.DLL",
+        "C:\\Windows\\System32\\keyiso.dll",
+        "C:\\Windows\\System32\\ngcpopkeysrv.dll",
+        "C:\\Windows\\System32\\SecureTimeAggregator.dll",
+        "C:\\Windows\\System32\\vaultsvc.dll"
+  )
+
+----------------------------------
+
+*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/
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Boot or Logon Autostart Execution
+** ID: T1547
+** Reference URL: https://attack.mitre.org/techniques/T1547/
+* Sub-technique:
+** Name: Security Support Provider
+** ID: T1547.005
+** Reference URL: https://attack.mitre.org/techniques/T1547/005/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-print-spooler-point-and-print-dll.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-print-spooler-point-and-print-dll.asciidoc
new file mode 100644
index 0000000000..e55c95544e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-print-spooler-point-and-print-dll.asciidoc
@@ -0,0 +1,174 @@
+[[prebuilt-rule-8-19-24-suspicious-print-spooler-point-and-print-dll]]
+=== Suspicious Print Spooler Point and Print DLL
+
+Detects attempts to exploit a privilege escalation vulnerability (CVE-2020-1030) related to the print spooler service. Exploitation involves chaining multiple primitives to load an arbitrary DLL into the print spooler process running as SYSTEM.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.registry-*
+* endgame-*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+* 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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.accenture.com/us-en/blogs/cyber-defense/discovering-exploiting-shutting-down-dangerous-windows-print-spooler-vulnerability
+* https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES/blob/master/Privilege%20Escalation/privesc_sysmon_cve_20201030_spooler.evtx
+* https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-1030
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Data Source: Elastic Endgame
+* Use Case: Vulnerability
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Resources: Investigation Guide
+* Data Source: SentinelOne
+* Data Source: Microsoft Defender XDR
+
+*Version*: 215
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Suspicious Print Spooler Point and Print DLL*
+
+
+
+*Possible investigation steps*
+
+
+- Do the source registry events describe one printer object?
+  - Why: sequence alerts joined only on `host.id` can omit stage-specific registry and writer fields; recover member events before interpreting the grouped alert.
+  - Focus: compare the printer segment in `registry.path`, `registry.value`, and `registry.data.strings`; keep `user.id` and any `process.entity_id` pivots.
+  - Implication: escalate when one printer key sets SpoolDirectory to "C:\Windows\System32\spool\drivers\x64\4" then CopyFiles\Payload\Module under that path; lower concern only when recovery breaks the same-printer chain or value match.
+
+- Which process and user wrote the values, and does context fit printer administration?
+  - Focus: source-event writer context: `user.id`, `process.executable`, `process.command_line`, `process.parent.executable`, and recovered `process.entity_id`.
+  - Implication: escalate when reg.exe, rundll32.exe, a scripting host, a user-writable binary, or an unexpected interactive user wrote the values; lower concern when writer identity, parentage, and service context match the same confirmed driver deployment.
+
+- What DLL path did Module name, and was it staged?
+  - Focus: recovered Module `registry.data.strings`; if file telemetry exists, exact-path `file.path`, `file.Ext.original.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier`. Missing file telemetry leaves staging unresolved, not benign.
+  - Implication: escalate when the path names a newly written, renamed, internet-marked, or script-staged DLL in the spool drivers tree; lower concern when the exact path is a stable signed printer-driver package tied to the recovered printer object and writer workflow.
+
+- Did Print Spooler or print isolation consume the module?
+  - Why: CVE-2020-1030 abuse becomes higher impact when the CopyFiles\Payload\Module value is loaded or spooler restart behavior forces the changed configuration into effect.
+  - Focus: in library or process telemetry, check spoolsv.exe or PrintIsolationHost.exe loading the recovered path with `dll.path`, `dll.hash.sha256`, `dll.code_signature.subject_name`, and `dll.code_signature.trusted`. !{investigate{"description":"","label":"Spooler or print isolation loads on the host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"spoolsv.exe","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"PrintIsolationHost.exe","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: pivot on the recovered Module path because the sequence alert may not preserve that value; spooler termination or restart around the writes can be a force-load clue.
+  - Implication: escalate immediately when spooler loads the recovered DLL, restarts unexpectedly, or shows abnormal child activity soon after the writes; absent load telemetry does not clear a matching registry chain.
+
+- If suspicious or unresolved, does the pattern appear beyond this alert?
+  - Focus: related alerts for `host.id`, then exact matches for recovered `registry.data.strings`, printer `registry.path`, or `dll.hash.sha256` across other hosts when available. !{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 response when the same module path, DLL hash, printer-object pattern, or spooler-abuse alert appears on unrelated hosts; keep scope local when the pattern stays confined to the same confirmed driver workflow.
+
+- What disposition do registry chain, writer, payload, spooler, and scope evidence support?
+  - Focus: decide from same-printer registry stages, writer identity, DLL staging/load, workflow fit, and scope: escalate suspicious or unresolved chains, close only when telemetry cleanly aligns with one signed driver or print-management workflow, and preserve artifacts when evidence is mixed or incomplete.
+
+
+*False positive analysis*
+
+
+- Recognized signed printer-driver installation, print-management, imaging, or endpoint-build workflows can update SpoolDirectory and CopyFiles\Payload\Module or stage spool-directory drivers. Confirm recovered `registry.path`, exact `registry.data.strings`, stable signed DLL identity, writer `process.executable`, parent workflow, current-case `host.id`, and any spooler follow-on all point to the same driver or management workflow without ad hoc scripting, unsigned payloads, or suspicious child processes. Change or deployment records may corroborate; prior-alert recurrence can scope exceptions but must not substitute for current-case telemetry.
+- Build exceptions only from the minimum confirmed workflow pattern: `host.id`, recovered printer object from `registry.path`, exact recovered Module path, stable DLL identity, and the confirmed writer or deployment process. Avoid exceptions on the spool drivers directory alone, the printer name alone, or spoolsv.exe activity alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, record `host.id`, the recovered printer object, exact Module path, stable DLL identity, and deployment workflow that justified closure before reversing temporary containment. Create an exception only from that exact confirmed workflow pattern; use prior alerts to narrow scope, not to prove benignity.
+- If suspicious but unconfirmed, preserve the Timeline member events, exact `registry.path` and `registry.data.strings`, exported affected registry keys, recovered DLL file if present, file or library hashes, writer `process.executable`, user context, and any spoolsv.exe or PrintIsolationHost.exe follow-on evidence before containment. Apply reversible containment first, such as restricting remote printer administration, disabling Point and Print exposure, or pausing nonessential printing on the affected host.
+- If confirmed malicious, preserve the DLL if feasible, export the affected printer keys, and retain related spoolsv.exe or PrintIsolationHost.exe process and library telemetry before containment. Then use endpoint response to isolate the host when registry-chain, payload, or spooler-side evidence shows malicious activity and host criticality allows it. Review other hosts for the same recovered DLL path, DLL hash, or printer-object pattern before stopping spoolsv.exe, deleting the DLL, restoring registry values, and removing the mechanism that staged the payload.
+- Post-incident hardening: apply the Microsoft fix for CVE-2020-1030, restrict Point and Print and printer-driver installation rights where feasible, disable the Print Spooler service on hosts that do not need it, retain registry, file, and library telemetry for spooler abuse, and document confirmed printer-object and DLL patterns 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/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by host.id with maxspan=30s
+[registry where host.os.type == "windows" and
+   registry.value : "SpoolDirectory" and
+   registry.path : "*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Print\\Printers\\*\\SpoolDirectory" and
+   registry.data.strings : "C:\\Windows\\System32\\spool\\drivers\\x64\\4"]
+[registry where host.os.type == "windows" and
+   registry.value : "Module" and
+   registry.path : "*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Print\\Printers\\*\\CopyFiles\\Payload\\Module" and
+   registry.data.strings : "C:\\Windows\\System32\\spool\\drivers\\x64\\4\\*"]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Exploitation for Privilege Escalation
+** ID: T1068
+** Reference URL: https://attack.mitre.org/techniques/T1068/
+* Technique:
+** Name: Hijack Execution Flow
+** ID: T1574
+** Reference URL: https://attack.mitre.org/techniques/T1574/
+* 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-24/prebuilt-rule-8-19-24-suspicious-seincreasebasepriorityprivilege-use.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-seincreasebasepriorityprivilege-use.asciidoc
new file mode 100644
index 0000000000..705ef0d7c1
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-seincreasebasepriorityprivilege-use.asciidoc
@@ -0,0 +1,147 @@
+[[prebuilt-rule-8-19-24-suspicious-seincreasebasepriorityprivilege-use]]
+=== Suspicious SeIncreaseBasePriorityPrivilege Use
+
+Identifies attempts to use the SeIncreaseBasePriorityPrivilege privilege by an unusual process. This could be related to hijack execution flow of a process via threats priority manipulation.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/Octoberfest7/ThreadCPUAssignment_POC/tree/main
+* https://x.com/sixtyvividtails/status/1970721197617717483
+* https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4674
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 3
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Suspicious SeIncreaseBasePriorityPrivilege Use*
+
+
+
+*Possible investigation steps*
+
+
+- What priority-change path did 4674 preserve?
+  - Why: this privilege manipulates process or thread priority; the target object matters as much as the requester.
+  - Focus: Security 4674 on `host.id`: `winlog.event_data.PrivilegeList`, `winlog.event_data.AccessMask`, `winlog.event_data.ProcessName`, `winlog.event_data.ObjectType`, and `winlog.event_data.ObjectName`.
+  - Hint: sparse or numeric-only `winlog.event_data.ObjectName` is the main visibility gap; keep the target unresolved and use same-session Security records, not assumed self-tuning.
+  - Implication: escalate when the object is a "Process" or "Thread" tied to security tooling, LSASS, or another user's workload; lower suspicion only when requester, object, and `host.name` fit bounded tuning or testing.
+
+- Is the requesting image path expected for priority control on this host?
+  - Focus: `winlog.event_data.ProcessName`, `winlog.event_data.ProcessId`, `winlog.event_data.SubjectUserSid`, `host.name`, and `@timestamp`.
+  - Hint: `winlog.event_data.ProcessId` is hexadecimal; use it only inside a tight host/time window; PID reuse can mislead.
+  - Implication: escalate when the path is user-writable, temporary, renamed, or unrelated to local tuning; treat a recurring full path and SID as identity support, not closure, until object and session evidence align.
+
+- Which subject and local session requested this privilege use?
+  - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, and `winlog.event_data.SubjectLogonId`.
+  - Implication: escalate when a normal user, rare admin, machine account, or service account lacks a clear scheduling-priority role; matching SID, domain, and session support benignity only with matching requester and object evidence.
+
+- Does the 4624 session origin fit a priority-tuning operator?
+  - Focus: on the same `host.id`, match alert `winlog.event_data.SubjectLogonId` to 4624 `winlog.event_data.TargetLogonId`, then read `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`.
+  - Hint: query `event.code` 4624 with alert `host.id` and `winlog.event_data.TargetLogonId`; search backward from `@timestamp` because the session can predate 4674. !{investigate{"description":"","label":"Linked logon for the priority-change session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} Missing 4624 or empty `source.ip` is unresolved, not benign.
+  - Implication: escalate when source, logon type, or authentication method is rare for `host.name` or subject SID; matching origin supports authorized tuning only after requester path and target object fit.
+
+- Do surrounding Security records show repeated or multi-target priority use by the same requester?
+  - Focus: Security events around `@timestamp` on the same `host.id`, grouped by `winlog.event_data.SubjectLogonId`, `winlog.event_data.ProcessId`, `winlog.event_data.ProcessName`, and `winlog.event_data.ObjectName`.
+  - Hint: start in the alert window with `event.code` 4674 and alert `winlog.event_data.SubjectLogonId`; expand only if the same session continues around `@timestamp`. Add `event.outcome` to separate failed attempts from successful use. !{investigate{"description":"","label":"4674 priority-use events from this requester session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4674","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ProcessId","queryType":"phrase","value":"{{winlog.event_data.ProcessId}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4674","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ProcessName","queryType":"phrase","value":"{{winlog.event_data.ProcessName}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when one session or requester touches multiple process/thread objects, repeats against security targets, or continues after failures; a single 4674 keeps scope local but still requires requester, object, and session answers for closure.
+
+- If local evidence is suspicious or unresolved, do related alerts expand scope or urgency?
+  - Focus: related alerts for the same `host.id`, prioritizing privilege abuse, defense evasion, security-tool interference, service-control, or authentication findings. !{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"}}
+  - Hint: if the subject remains suspicious, use the subject pivot; use the `user.id` provider only after confirming it maps to `winlog.event_data.SubjectUserSid`. !{investigate{"description":"","label":"Alerts associated with the subject","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}],[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the host or user also shows privilege escalation, defense evasion, or unusual authentication; keep scope local when related alerts are absent and 4674/session evidence supports bounded work.
+
+- Escalate for unauthorized process/thread priority manipulation or security-tool interference; close only when object, requester, subject, session, and related alerts bind to one authorized tuning or troubleshooting workflow; preserve 4674 and recovered 4624 evidence and escalate when sparse object or session evidence leaves suspicious findings unresolved.
+
+
+*False positive analysis*
+
+
+- Performance engineering, benchmark, QA, vendor, or internal support work can trigger when an administrator adjusts scheduling priority or CPU assignment for a test or latency-sensitive workload. Confirm only when `winlog.event_data.ProcessName`, `winlog.event_data.ObjectType`, `winlog.event_data.ObjectName`, `winlog.event_data.SubjectUserSid`, recovered `source.ip`, and `winlog.logon.type` align with the same recognized host, accounts, and workload. If records are unavailable, require telemetry-only recurrence of the same full requester path, SID, object family, and host class before treating as benign.
+- If the target object is sparse or numeric-only, do not close solely on tool name or user claim.
+- Before creating an exception, validate that `winlog.event_data.ProcessName`, `winlog.event_data.ObjectType`, `winlog.event_data.ObjectName`, `winlog.event_data.SubjectUserSid`, `host.id`, and recovered `source.ip` or `winlog.logon.type` stay stable across known-benign occurrences. Build the exception from that minimum confirmed pattern; avoid exceptions on `winlog.event_data.PrivilegeList` or `user.name` alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and document the validated `winlog.event_data.ProcessName`, `winlog.event_data.ObjectType`, `winlog.event_data.ObjectName`, `winlog.event_data.SubjectUserSid`, recovered `source.ip`, `winlog.logon.type`, and `host.id` values proving the tuning or troubleshooting workflow. Create an exception only after the same pattern repeats benignly.
+- If suspicious but unconfirmed, preserve a case export of triggering 4674, recovered 4624 session record, surrounding same-session Security records, and related-alert links before containment. Record requester path and PID, subject SID, target object, session origin, and event time as case anchors.
+- If suspicious but unconfirmed, apply reversible containment first, such as restricting the subject's remote access, pausing the support workflow, or raising monitoring on `host.id`. Escalate to host isolation or account disablement only if the target maps to a security-critical process, related alerts show additional privilege abuse or defense evasion, or the recovered session suggests credential misuse.
+- If confirmed malicious, isolate the host when the object, requester, session, or related-alert evidence shows unauthorized priority manipulation of a security-critical process or another user's workload. Record the requester path and PID, subject SID, target object, recovered session origin, and event time before stopping processes or deleting tooling.
+- Reset or suspend the implicated account only when the recovered session and related alerts show likely credential misuse, and review other hosts for the same `winlog.event_data.ProcessName`, `winlog.event_data.ObjectName`, or `winlog.event_data.SubjectUserSid` before eradicating artifacts so scoping finishes before evidence is destroyed.
+- Eradicate only the unauthorized tuning or interference tooling and any persistence or launcher artifacts identified during the investigation, then restore affected security or service configurations to a known-good state.
+- Hardening: restrict assignment of "SeIncreaseBasePriorityPrivilege" to the smallest admin cohort, retain Security 4674 and 4624 visibility, and record visibility gaps that limited the case decision.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Audit Sensitive Privilege Use must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-sensitive-privilege-use
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.category:iam and host.os.type:"windows" and event.code:"4674" and
+winlog.event_data.PrivilegeList:"SeIncreaseBasePriorityPrivilege" and event.outcome:"success" and
+winlog.event_data.AccessMask:"512" and not winlog.event_data.SubjectUserSid:("S-1-5-18" or "S-1-5-19" or "S-1-5-20")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Access Token Manipulation
+** ID: T1134
+** Reference URL: https://attack.mitre.org/techniques/T1134/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc
new file mode 100644
index 0000000000..9b6181f8ed
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc
@@ -0,0 +1,180 @@
+[[prebuilt-rule-8-19-24-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process]]
+=== Suspicious SolarWinds Web Help Desk Java Module Load or Child Process
+
+Identifies the SolarWinds Web Help Desk Java process loading an untrusted or remote native module (DLL) or spawning a suspicious child process such as cmd, PowerShell, or rundll32. This behavior is uncommon for the Web Help Desk server and may indicate successful exploitation of deserialization vulnerabilities (CVE-2025-40536, CVE-2025-40551), which allow attackers to load malicious SQLite extensions and achieve remote code execution.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.library-*
+* 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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://horizon3.ai/attack-research/cve-2025-40551-another-solarwinds-web-help-desk-deserialization-issue/
+* https://github.com/rapid7/metasploit-framework/pull/20917
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Initial Access
+* Use Case: Vulnerability
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 3
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Suspicious SolarWinds Web Help Desk Java Module Load or Child Process*
+
+
+
+*Possible investigation steps*
+
+
+- Which path fired, and what alert-local evidence defines it?
+  - Why: The single-event branch decides whether DLL fields or child-process fields carry the decisive evidence.
+  - Focus: `event.category`, Java path in `process.executable` or `process.parent.executable`, `dll.path`, and child `process.command_line`.
+  - Hint: record `process.entity_id` for library alerts and `process.parent.entity_id` for child-process alerts before later pivots.
+  - Implication: Escalate quickly for Web Help Desk Java loading remote or untrusted native code, or spawning "cmd.exe", "powershell.exe", or "rundll32.exe" with payload behavior. Lower concern only when the exact branch maps to a recognized local extension, authorized validation, or vendor support action and process or DLL evidence stays consistent.
+
+- Does the Java-side identity match the expected Web Help Desk service instance?
+  - Focus: Java path from step 1 and Java command line: `process.command_line` for library alerts or `process.parent.command_line` for child-process alerts.
+  - Implication: Escalate when the Java path falls outside the WebHelpDesk install tree or the service command line is abnormal for the deployed server. Identity lowers suspicion only when exact Java path and service context match the installed server; it does not clear a remote DLL load or shell child.
+
+- For the DLL-load path, does the module look like a remote SQLite-extension payload or unsupported native component?
+  - Why: Malicious SQLite-extension style native loading makes DLL path and trust state the strongest branch evidence.
+  - Focus: `dll.path`, `dll.hash.sha256`, `dll.code_signature.exists`, `dll.code_signature.trusted`, and `dll.code_signature.subject_name`.
+  - Implication: Escalate when `dll.path` shows "\Device\Mup\", a UNC-style share, temp or unrelated writable path, unsigned or untrusted module, or signer unrelated to Web Help Desk or its controlled extension set. Lower concern only when the module is local to the Web Help Desk or JDBC layout and has a recognized hash or signer.
+
+- For the child-process path, does the Java-spawned child show post-exploitation intent?
+  - Focus: `process.name`, `process.command_line`, and `process.parent.command_line`.
+  - Implication: Escalate when the command line decodes or stages payloads, loads DLLs, launches scripts, performs discovery, or changes persistence. Lower concern only for exact recognized validation or vendor-support command on this server with no contradictory DLL evidence.
+
+- Did the same Web Help Desk Java instance produce more DLL loads or suspicious children around the alert?
+  - Focus: process and library events scoped by `host.id` plus Java-side `process.entity_id` or `process.parent.entity_id`; review `process.command_line`, `dll.path`, and `dll.hash.sha256`. !{investigate{"description":"","label":"Process and DLL activity tied to the Web Help Desk Java instance","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":"library","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: Escalate when the same Java instance loads multiple remote or untrusted DLLs, starts multiple shell or loader children, or shows child execution after a suspicious DLL load. No surrounding process or library events narrows scope, but does not clear the original alert.
+
+- If local evidence remains suspicious or unresolved, are there related exploit or post-exploitation alerts on this server?
+  - Focus: related alerts on `host.id`, especially Web Help Desk exploitation, suspicious Java children, DLL loads, persistence, or credential access. !{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 related alerts align with the same Java process, DLL hash, or child command pattern. Keep the case local when related-alert review is clean, but do not use alert isolation alone to close.
+
+- Escalate on remote or untrusted DLL loading, malicious child execution, or same-Java corroboration; close only when branch evidence tightly matches a recognized local extension, authorized validation, or vendor support action on this host with no contradictory process or DLL evidence; if visibility or authorization is incomplete, preserve evidence and escalate.
+
+
+*False positive analysis*
+
+
+- Local native extension, JDBC, or vendor-support testing can explain the DLL path only when the module stays local to the Web Help Desk or controlled plugin layout; `dll.hash.sha256`, `dll.code_signature.subject_name`, and `dll.code_signature.trusted` match the expected component; Java identity matches the installed server; and no Java-spawned shell or loader appears. Without support or change records, require telemetry-only alignment across `host.id`, Java `process.executable` or `process.parent.executable`, `dll.path`, and `dll.hash.sha256`; otherwise treat as unresolved.
+- Java-spawned "cmd.exe", "powershell.exe", or "rundll32.exe" is a Web Help Desk operational anti-pattern. Close only for authorized validation or vendor support where `process.name`, `process.command_line`, `process.parent.executable`, and `host.id` match that exact activity and no remote or untrusted DLL evidence appears. Without exact support or validation context, treat the branch as suspicious.
+- Before creating an exception, validate stable benign behavior for the exact workflow and host. For DLL loads, anchor on Java identity, `dll.path`, `dll.hash.sha256`, `dll.code_signature.subject_name`, and `host.id`; for child processes, anchor on Java parent identity, exact `process.command_line`, and `host.id`. Avoid exceptions on "java.exe", the WebHelpDesk path prefix, a DLL directory prefix, or the server alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and document the Java identity, DLL hash/path or child command line, `host.id`, and support, validation, or extension evidence that proved the workflow. Create an exception only from the narrow branch-specific anchors that proved that workflow.
+- If suspicious but unconfirmed, preserve the alert export, process tree, Java and child command lines, loaded DLL file, DLL hash/signature, and any "\Device\Mup\" share path before containment. Apply reversible containment first, such as restricting Web Help Desk exposure or blocking the observed remote share path, and escalate to endpoint isolation only when DLL or child-process evidence suggests active payload execution.
+- If confirmed malicious, preserve process, DLL, and case artifacts before destructive action. Isolate the endpoint when the Java process is executing payloads or reaching remote native-code staging, block the malicious share path or DLL hash, collect the loaded DLL and relevant process evidence before termination, then remove only the payloads, persistence items, and service changes identified during the investigation.
+- Remediate the entry vector by upgrading or patching Web Help Desk to the vendor-fixed release, confirming the exposed service is no longer vulnerable, and reviewing whether public access, outbound SMB from the server, or native-extension/plugin controls need tighter restrictions.
+- Post-incident hardening: retain the process and library telemetry that proved the case, document remote SQLite-extension loading or Java-spawned shell activity for future triage, and record any authorized validation or support exception with its exact branch-specific anchors.
+
+
+==== 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]
+----------------------------------
+any where host.os.type == "windows" and
+(
+ (event.category == "library" and
+  process.executable : ("C:\\Program Files\\WebHelpDesk\\*\\java*.exe", "C:\\Program Files (x86)\\WebHelpDesk\\*\\java*.exe") and
+  (dll.path : "\\Device\\Mup\\*" or dll.code_signature.trusted == false or ?dll.code_signature.exists == false)) or
+
+ (event.category == "process" and process.name : ("cmd.exe", "powershell.exe", "rundll32.exe") and
+  process.parent.executable : ("C:\\Program Files\\WebHelpDesk\\*\\java*.exe", "C:\\Program Files (x86)\\WebHelpDesk\\*\\java*.exe"))
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Exploit Public-Facing Application
+** ID: T1190
+** Reference URL: https://attack.mitre.org/techniques/T1190/
+* Tactic:
+** Name: 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/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
+* Sub-technique:
+** Name: Windows Command Shell
+** ID: T1059.003
+** Reference URL: https://attack.mitre.org/techniques/T1059/003/
+* Technique:
+** Name: Shared Modules
+** ID: T1129
+** Reference URL: https://attack.mitre.org/techniques/T1129/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-startup-shell-folder-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-startup-shell-folder-modification.asciidoc
new file mode 100644
index 0000000000..64f7082069
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-startup-shell-folder-modification.asciidoc
@@ -0,0 +1,200 @@
+[[prebuilt-rule-8-19-24-suspicious-startup-shell-folder-modification]]
+=== Suspicious Startup Shell Folder Modification
+
+Identifies suspicious startup shell folder modifications to change the default Startup directory in order to bypass detections monitoring file creation in the Windows Startup folder.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.registry-*
+* endgame-*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-crowdstrike.fdr*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.elastic.co/security-labs/elastic-security-uncovers-blister-malware-campaign
+* https://www.elastic.co/security-labs/revisiting-blister-new-developments-of-the-blister-loader
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Resources: Investigation Guide
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Microsoft Defender XDR
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+
+*Version*: 320
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Suspicious Startup Shell Folder Modification*
+
+
+
+*Possible investigation steps*
+
+
+- What shell-folder scope changed, and which local path now receives Startup items?
+  - Why: `registry.value` separates per-user "Startup" from all-users "Common Startup"; all-users scope broadens persistence beyond one profile.
+  - Focus: `registry.path`, `registry.value`, `registry.hive`, `registry.data.type`, `registry.data.strings`.
+  - Implication: escalate when `registry.data.strings` points to a user-writable, hidden, deceptive, or all-users local path; lower concern here only for a recognized managed redirection target, then continue through process and user/host checks.
+
+- Which process and lineage changed the shell-folder value?
+  - Focus: `process.executable`, `process.command_line`, `process.parent.executable`, `process.parent.command_line`, `process.code_signature.subject_name`.
+  - Implication: escalate when the writer is a COM broker such as dllhost.exe, script host, LOLBin, renamed binary, user-writable executable, or unrelated parent chain; lower concern for management or packaging tooling only when command line and lineage explain this exact shell-folder write. Signed identity never clears the behavior by itself.
+
+- Was a startup artifact staged or executed from the redirected path?
+  - Why: the registry change can be setup only; persistence is proven by startup content in the redirected directory, and delayed staging or value reversion can hide the chain.
+  - Focus: same-process activity, redirected-directory file events, and command lines referencing `registry.data.strings`.
+    - !{investigate{"description":"","label":"Activity from this process instance 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"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"File events in the redirected Startup path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.directory","queryType":"phrase","value":"{{registry.data.strings}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Process command lines referencing the redirected path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.command_line","queryType":"phrase","value":"{{registry.data.strings}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Hint: if file telemetry is available, check file-event writes to that directory; missing file-event visibility is unresolved, not benign.
+  - Implication: escalate when the modifier or later process writes, launches, or reverts around shortcuts, scripts, or binaries in the redirected directory.
+
+- Does the creating identity and host context fit one recognized redirection workflow?
+  - Focus: `user.id`, `user.name`, `user.domain`, `host.id`, `host.name`.
+  - Implication: escalate when an interactive or ad hoc identity changes Startup resolution on a host that does not normally customize shell folders; lower concern only when identity, host cohort, path, and lineage converge on one recognized management or packaging workflow.
+
+- If local evidence is suspicious or unresolved, does same-host activity change scope?
+  - Why: sibling autostart `registry.path` changes can preserve persistence if the redirected Startup folder is noticed, restored, or cleaned.
+  - Focus: use !{investigate{"description":"","label":"Recent activity on this host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} for the same `host.id`, then filter for the exact `registry.data.strings` path, sibling autostart `registry.path` changes, and process starts referencing the redirected path.
+  - Implication: broaden response when the host shows additional shell-folder or Run-key changes, execution from the redirected path, or repeated attempts to use it; keep scope local only when the pivot finds no matching autostart or execution evidence.
+
+- Do the path, process, payload-use, and context findings support startup-folder evasion?
+  - Implication: escalate for an unexpected process or actor, suspicious local path, shortcut/script/binary content, redirected-path execution, or same-host persistence/evasion; close only when telemetry narrows the case to one exact recognized workflow and outside confirmation verifies legitimacy where telemetry alone cannot; preserve and escalate when file visibility, process context, or workflow evidence is incomplete.
+
+
+*False positive analysis*
+
+
+- Managed shell-folder redirection or application packaging can repoint "Startup" or "Common Startup" to a nondefault local path, but this is operationally sensitive. Treat these explanations as benign only when alert-window telemetry proves the exact redirected folder, process lineage, expected startup content, and managed host cohort all match one management or packaging job. Use deployment records, management configuration, packaging job logs, or owner confirmation when telemetry alone cannot prove legitimacy; do not close on a management label without this evidence.
+- Before exceptioning, validate recurrence of the same `registry.value`, `registry.data.strings`, `process.executable`, `process.command_line`, `process.parent.executable`, `user.id`, and `host.id` pattern after confirming the benign workflow. Build the exception from that minimum workflow, and avoid exceptions on all Startup shell-folder modifications, the whole Explorer shell-folder key family, or the rule name alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, record the exact registry path/value/data, process lineage, `user.id`, and `host.id` pattern that proved the recognized workflow, then reverse temporary containment. Keep any exception narrow and require recurrence of that same workflow.
+- If suspicious but unconfirmed, preserve the alert, Timeline or case exports, the current shell-folder value, process tree, command line, and redirected-directory contents or metadata when available before changing state. Apply reversible containment first, such as blocking execution from the redirected directory or increasing monitoring on the host. Restore the legitimate Startup path only after evidence capture, dependency review, and validation of the correct per-user or Common Startup path. Isolate the host only when payload execution or related alerts show active compromise.
+- If confirmed malicious, collect staged shortcuts, scripts, binaries, hashes, and registry evidence before eradication. Contain the endpoint when its role allows, contain the creating account when the evidence shows account misuse, validate the correct per-user or Common Startup value, restore that value, and remove only the artifacts identified in the investigation. If direct response is unavailable, escalate with the preserved evidence to the team that can act on the host.
+- Before cleanup, review other user profiles and the all-users Startup scope for the same redirected path, then verify no process execution still points to that directory. After recovery, restrict shell-folder redirection to controlled management tooling, retain registry/process and available file telemetry needed to connect redirection to later payload staging, and document delayed-staging or value-reversion blind spots for future cases.
+
+
+==== 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-reg-setup[Sysmon Registry Events]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+registry where host.os.type == "windows" and event.type == "change" and
+ registry.value : ("Common Startup", "Startup") and
+ registry.path : (
+     "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Common Startup",
+     "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Common Startup",
+     "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup",
+     "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup",
+     "HKU\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup",
+     "HKU\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup",
+     "HKCU\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup",
+     "HKCU\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup",
+     "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Common Startup",
+     "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Common Startup",
+     "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup",
+     "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup",
+     "MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Common Startup",
+     "MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Common Startup",
+     "USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup",
+     "USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup"
+     ) and
+  registry.data.strings != null and
+  /* Normal Startup Folder Paths */
+  not registry.data.strings : (
+           "C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup",
+           "%ProgramData%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup",
+           "%USERPROFILE%\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup",
+           "%%USERPROFILE%%\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup",
+           "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup",
+           "\\\\*"
+           )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Boot or Logon Autostart Execution
+** ID: T1547
+** Reference URL: https://attack.mitre.org/techniques/T1547/
+* Sub-technique:
+** Name: Registry Run Keys / Startup Folder
+** ID: T1547.001
+** Reference URL: https://attack.mitre.org/techniques/T1547/001/
+* 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-24/prebuilt-rule-8-19-24-suspicious-suid-binary-execution-auditd-sequence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-suid-binary-execution-auditd-sequence.asciidoc
new file mode 100644
index 0000000000..08a5608b7b
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-suid-binary-execution-auditd-sequence.asciidoc
@@ -0,0 +1,129 @@
+[[prebuilt-rule-8-19-24-suspicious-suid-binary-execution-auditd-sequence]]
+=== Suspicious SUID Binary Execution (Auditd Sequence)
+
+Detects suspicious sequences where a non-root user launches a high-risk parent process (interpreter, shell one-liner, or execution from user-writable paths) and then quickly executes a common privilege elevation helper (su, sudo, pkexec, passwd, chsh, newgrp) that gains an effective UID of 0 while the real UID remains non-root. This can indicate misuse of SUID/SGID helpers, polkit/sudo abuse, or interactive privilege escalation attempts captured via Auditd Manager telemetry.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* 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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1548/
+* https://docs.elastic.co/integrations/auditd_manager
+
+*Tags*: 
+
+* Data Source: Auditd Manager
+* Domain: Endpoint
+* OS: Linux
+* 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 Suspicious SUID Binary Execution (Auditd Sequence)*
+
+
+Confirm whether the non-root real user should be invoking su, sudo, pkexec, or account utilities as root. Review the
+parent process chain and whether the parent executable location or shell invocation suggests a one-liner or staging
+from user-writable paths.
+
+
+*Possible investigation steps*
+
+
+- Review process details for script paths, temp directory execution, or suspicious interpreters.
+- Check sudoers / polkit policy changes and recent authentication events for the user.
+- Pivot for follow-on persistence (cron, systemd units) or credential access from the same session.
+
+
+*Response and remediation*
+
+
+- If unauthorized, contain the session, revoke elevated access, and review sudoers and polkit configuration for tampering.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by host.id with maxspan=30s
+  [process where host.os.type == "linux" and event.type == "start" and
+   event.action == "executed" and
+   user.id != "0" and user.effective.id != "0" and
+   (
+     process.name like ("python*", "perl*", "ruby*", "php*", "lua*", ".*") or
+     process.name in ("node", "bun", "java") or
+     process.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/user/*", "/var/run/user/*", "/home/*/*") or
+     (
+       process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh") and
+       process.args in ("-c", "--command", "-ic", "-ci", "-cl", "-lc")
+     )
+   )
+  ] by process.pid
+
+  [process where host.os.type == "linux" and event.type == "start" and
+   event.action == "executed" and
+   user.effective.id == "0" and user.id != "0" and
+   (
+     (process.name in ("sudo", "pkexec") and
+      not process.args like "-*" and
+      not process.args : ("/usr/*", "/bin/*", "/sbin/*", "/opt/*")) or
+     (process.name == "su" and
+      not process.args in ("--command", "-c", "--shell", "-s")) or
+     (process.name in ("passwd", "chsh", "newgrp") and
+      not process.args in ("--shell", "-s", "--help"))
+   )
+  ] by process.parent.pid
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Abuse Elevation Control Mechanism
+** ID: T1548
+** Reference URL: https://attack.mitre.org/techniques/T1548/
+* Sub-technique:
+** Name: Setuid and Setgid
+** ID: T1548.001
+** Reference URL: https://attack.mitre.org/techniques/T1548/001/
+* Sub-technique:
+** Name: Sudo and Sudo Caching
+** ID: T1548.003
+** Reference URL: https://attack.mitre.org/techniques/T1548/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-suid-binary-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-suid-binary-execution.asciidoc
new file mode 100644
index 0000000000..f8efab0d3e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-suid-binary-execution.asciidoc
@@ -0,0 +1,122 @@
+[[prebuilt-rule-8-19-24-suspicious-suid-binary-execution]]
+=== Suspicious SUID Binary Execution
+
+Detects execution of SUID binaries that may be used for privilege escalation under the root effective user when the real user and parent user are not root, combined with minimal argument counts and suspicious parent context (interpreters, short shell -c invocations, or parents running from user-writable paths) to indicate potential misuse of SUID binaries for privilege escalation.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1548/
+
+*Tags*: 
+
+* Data Source: Elastic Defend
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Suspicious SUID Binary Execution*
+
+
+Confirm whether the non-root real user should be invoking SUID binaries as root. Review the parent process tree, script path, and any preceding download or decode activity.
+
+
+*Possible investigation steps*
+
+
+- Inspect `process.parent.command_line` and working directory for obfuscation or one-liners.
+- Check authentication and sudoers policy for the user.
+- Pivot on the host for additional privilege escalation or persistence in the same session.
+
+
+*Response and remediation*
+
+
+- If unauthorized, contain the session, revoke elevated access, and review sudoers and polkit policy for tampering.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
+  (process.user.id == "0" and process.real_user.id != "0" and process.parent.user.id != "0") or
+  (process.group.id == "0" and process.real_group.id != "0" and process.parent.group.id != "0")
+) and
+(
+  (process.name in ("su", "passwd", "unix_chkpwd") and process.args_count <= 2) or
+  (
+    process.name in ("sudo", "pkexec", "fusermount", "fusermount3", "mount", "umount", "newgrp", "chsh") and
+    process.args_count == 1
+  ) or
+  process.name in (
+    "sudoedit", "gpasswd", "chfn", "polkit-agent-helper-1", "dbus-daemon-launch-helper", "ssh-keysign",
+    "pam_extrausers_chkpwd", "expiry", "chage", "crontab", "wall", "bsd-write", "ssh-agent", "ping",
+    "ping6", "traceroute", "mtr", "ntfs-3g", "Xorg.wrap", "chrome-sandbox", "bwrap"
+  )
+) and
+(
+  process.parent.name like (".*", "python*", "perl*", "ruby*", "lua*", "php*", "node", "deno", "bun", "java") or
+  process.parent.executable like ("./*", "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/user/*", "/var/run/user/*", "/home/*/*") or
+  (
+    process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh") and
+    process.parent.args in ("-c", "-cl", "-lc", "--command", "-ic", "-ci", "-bash", "-sh", "-zsh", "-dash", "-fish", "-ksh", "-mksh") and
+    process.parent.args_count <= 4
+  )
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Abuse Elevation Control Mechanism
+** ID: T1548
+** Reference URL: https://attack.mitre.org/techniques/T1548/
+* Sub-technique:
+** Name: Setuid and Setgid
+** ID: T1548.001
+** Reference URL: https://attack.mitre.org/techniques/T1548/001/
+* Sub-technique:
+** Name: Sudo and Sudo Caching
+** ID: T1548.003
+** Reference URL: https://attack.mitre.org/techniques/T1548/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-windows-command-shell-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-windows-command-shell-arguments.asciidoc
new file mode 100644
index 0000000000..776b463eef
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-suspicious-windows-command-shell-arguments.asciidoc
@@ -0,0 +1,261 @@
+[[prebuilt-rule-8-19-24-suspicious-windows-command-shell-arguments]]
+=== Suspicious Windows Command Shell Arguments
+
+Identifies the execution of the Windows Command Shell process (cmd.exe) with suspicious argument values. This behavior is often observed during malware installation.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* 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*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* 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
+
+*Version*: 209
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Suspicious Windows Command Shell Arguments*
+
+
+
+*Possible investigation steps*
+
+
+- What abuse path and launch context does the alerting "cmd.exe" show?
+  - Focus: `process.command_line`, `process.args`, `process.executable`, `process.parent.executable`, and `process.parent.command_line`; classify reconstruction, remote retrieval, WebDAV or UNC execution, obfuscated environment setup, or handoff to "regsvr32.exe", "wscript.exe", "mshta.exe", PowerShell, or AutoIt.
+  - Implication: escalate when the command reconstructs scripts, pulls remote content, starts from a remote share, chains to proxy execution, runs from a non-native path, or has a parent conflicting with command purpose; lower suspicion only when parent-command, user-host, child, artifact, and destination evidence form one consistent current activity. Identity or recurrence alone does not clear suspicious arguments.
+
+- Did the same "cmd.exe" instance launch a second stage?
+  - Focus: child starts where `host.id` and `process.parent.entity_id` map to `process.entity_id`; review child `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child process starts from the same cmd.exe instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `process.entity_id` is absent, use `host.id` plus `process.pid` in a tight alert-time window.
+  - Implication: escalate when the shell launches PowerShell, "regsvr32.exe", "wscript.exe", "mshta.exe", archive tools, script files, or newly staged payloads; lower suspicion when no child follows or stays inside the parent directory or command-named output path.
+
+- If endpoint file telemetry is available, did the shell reconstruct or stage executable content?
+  - Focus: file activity tied to `process.entity_id` or, if needed, `host.id` plus `process.pid`, checking `file.path`, `file.Ext.original.path`, `file.Ext.header_bytes`, and `file.Ext.windows.zone_identifier`. !{investigate{"description":"","label":"File activity for the alerting cmd.exe instance","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.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the shell writes scriptable files, rebuilds archive or PE content, renames staged payloads, or leaves internet-marked content in temp, public, or user-writable paths; lower suspicion when paths stay under the parent directory or command-named output path and no written content later executes. Missing file telemetry is unresolved, not benign.
+
+- If endpoint network telemetry is available, did the shell retrieve content or execute from WebDAV or UNC infrastructure?
+  - Focus: process-scoped DNS and connections for `host.id` and `process.entity_id`; compare DNS `dns.question.name` or `dns.resolved_ip` and connection `destination.ip` or `destination.port` with UNC, "DavWWWRoot", or URL fragments in `process.command_line`. !{investigate{"description":"","label":"Network activity for the alerting cmd.exe instance","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.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `dns.resolved_ip` is present, correlate it to `destination.ip` on the same host and process before judging the destination.
+  - Implication: escalate when the shell reaches rare public hosts, unexpected WebDAV endpoints, or shares unrelated to the parent; lower suspicion when DNS and connections match the share, URL, or host pattern visible in the command and parent. Missing network telemetry is unresolved, not benign.
+
+- If local findings remain suspicious or unresolved, does the pattern recur on the same host or user?
+  - Focus: recent alerts for the same `host.id`, emphasizing execution, delivery, persistence, or proxy-execution detections that reuse the same command-shell pattern. !{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"}}
+  - Hint: if the host is shared or quiet, compare recent alerts for the same `user.id` to test whether the user carries the pattern to other systems. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same host or user also shows delivery, shell, or persistence alerts; keep local when related alerts are clean and telemetry binds one parent-command, child, artifact, destination, and user-host tuple.
+
+- What disposition does the parent-command, child, artifact, destination, and user-host tuple support?
+  - Escalate for staged execution, remote retrieval, script reconstruction, proxy execution, or broader compromise; close only when alert-local command, parent, child, artifact, destination, user-host, and related-alert evidence bind one exact benign tuple with no contradictions. Preserve evidence and escalate on conflicts or incomplete visibility.
+
+
+*False positive analysis*
+
+
+- Packaging, build, installer, or developer activity can use "cmd.exe" to reconstruct files, call package managers, or hand off to helper utilities. Confirm `process.parent.executable`, `process.parent.command_line`, `process.command_line`, `user.id`, and `host.id` align with the same current parent path, helper command, package cache, build output, or database-export output, and that recovered child, file, or destination evidence does not conflict. Build records or change tickets are corroboration only.
+- Remote-support or software-distribution activity can reference UNC paths or "DavWWWRoot". When network or file telemetry exists, confirm `process.command_line`, `process.parent.executable`, `host.id`, and any recovered `dns.question.name`, `destination.ip`, or `file.path` stay inside one current distribution share, vendor endpoint, support-client cache, or deployment path and no unexpected child appears. Missing file or network telemetry is unresolved, not benign. Support records or inventories are corroboration only.
+- Before creating an exception, validate that the same `process.parent.executable`, `process.command_line`, `user.id`, `host.id`, and recovered artifact or destination anchors recur across prior alerts from this rule. Avoid exceptions on "cmd.exe" alone, one argument token, one destination, or parent name.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and document the parent command, alerting command, user-host scope, and recovered artifact or destination evidence. Create an exception only after the same tuple is stable across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve the alert, Timeline records, full command lines, process tree, recovered child details, staged files, and DNS or connection evidence before destructive action. Apply reversible containment first, such as temporary destination restrictions or heightened monitoring on `host.id` and `user.id`; isolate only when follow-on execution, staged payloads, or remote retrieval justifies disruption.
+- If confirmed malicious, isolate the host when identity, lineage, artifact, or destination evidence establishes unauthorized execution, then block confirmed malicious domains, destinations, or hashes. Record malicious shell and child identifiers before termination, scope related hosts and users before artifact removal, then remove only the scripts, archives, rebuilt payloads, persistence artifacts, or launcher components identified during the investigation.
+- Post-incident hardening: retain process, file, and network telemetry. If browser, explorer, script-host, or AutoIt launch paths were involved, review controls for user-driven shell launches; if WebDAV, UNC, or URL retrieval was involved, review remote-share and WebDAV execution controls. Note adjacent "mshta.exe", "wscript.exe", "regsvr32.exe", PowerShell, AutoIt, and explorer-driven clickfix-style variants for future triage.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires telemetry from one of the configured source integrations to be enabled and ingested.
+
+
+*Supported data sources*
+
+
+This rule can use the following 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 : "cmd.exe" and
+  (
+    process.command_line : (
+        "*).Run(*", "*GetObject*", "* curl*regsvr32*", "*echo*wscript*", "*echo*ZONE.identifier*",
+        "*ActiveXObject*", "*dir /s /b *echo*", "*unescape(*",  "*findstr*TVNDRgAAAA*", "*findstr*passw*", "*start*\\\\*\\DavWWWRoot\\*",
+        "* explorer*%CD%*", "*%cd%\\*.js*", "*attrib*%CD%*", "*/?cMD<*", "*/AutoIt3ExecuteScript*..*", "*&cls&cls&cls&cls&cls&*",
+        "*&#*;&#*;&#*;&#*;*", "* &&s^eT*", "*& ChrW(*", "*&explorer /root*", "*start __ & __\\*", "*findstr /V /L *forfiles*",
+        "*=wscri& set *", "*http*!COmpUternaME!*", "*start *.pdf * start /min cmd.exe /c *\\\\*", "*pip install*System.Net.WebClient*",
+        "*Invoke-WebReques*Start-Process*", "*-command (Invoke-webrequest*", "*copy /b *\\\\* ping *-n*", "*echo*.ToCharArray*"
+    ) or
+
+    (process.args : "echo" and process.parent.name : ("wscript.exe", "mshta.exe")) or
+    
+    process.args : ("1>?:\\*.vbs", "1>?:\\*.js") or
+
+    (process.args : "explorer.exe" and process.args : "type" and process.args : ">" and process.args : "start") or
+
+    (
+      process.parent.name : "explorer.exe" and
+      process.command_line : (
+        "*&&S^eT *",
+        "*&& set *&& set *&& set *&& set *&& set *&& call*",
+        "**\\u00??\\u00??\\u00??\\u00??\\u00??\\u00??\\u00??\\u00??*"
+      )
+    ) or
+
+    (process.parent.name : "explorer.exe" and process.args : "copy" and process.args : "&&" and process.args : "\\\\*@*\\*")
+  ) and
+
+  /* false positives */
+  not (process.args : "%TEMP%\\Spiceworks\\*" and process.parent.name : "wmiprvse.exe") and
+  not ?process.parent.executable : (
+        "?:\\Perl64\\bin\\perl.exe",
+        "?:\\Program Files\\nodejs\\node.exe",
+        "?:\\Program Files\\HP\\RS\\pgsql\\bin\\pg_dumpall.exe",
+        "?:\\Program Files (x86)\\PRTG Network Monitor\\64 bit\\PRTG Server.exe",
+        "?:\\Program Files (x86)\\Spiceworks\\bin\\spiceworks-finder.exe",
+        "?:\\Program Files (x86)\\Zuercher Suite\\production\\leds\\leds.exe",
+        "?:\\Program Files\\Tripwire\\Agent\\Plugins\\twexec\\twexec.exe",
+        "D:\\Agents\\?\\_work\\_tasks\\*\\SonarScanner.MSBuild.exe",
+        "?:\\Program Files\\Microsoft VS Code\\Code.exe",
+        "?:\\programmiweb\\NetBeans-*\\netbeans\\bin\\netbeans64.exe",
+        "?:\\Program Files (x86)\\Public Safety Suite Professional\\production\\leds\\leds.exe",
+        "?:\\Program Files (x86)\\Tier2Tickets\\button_gui.exe",
+        "?:\\Program Files\\NetBeans-*\\netbeans\\bin\\netbeans*.exe",
+        "?:\\Program Files (x86)\\Public Safety Suite Professional\\production\\leds\\leds.exe",
+        "?:\\Program Files (x86)\\Tier2Tickets\\button_gui.exe",
+        "?:\\Program Files (x86)\\Helpdesk Button\\button_gui.exe",
+        "?:\\VTSPortable\\VTS\\jre\\bin\\javaw.exe",
+        "?:\\Program Files\\Bot Framework Composer\\Bot Framework Composer.exe",
+        "?:\\Program Files\\KMSYS Worldwide\\eQuate\\*\\SessionMgr.exe",
+        "?:\\Program Files (x86)\\Craneware\\Pricing Analyzer\\Craneware.Pricing.Shell.exe",
+        "?:\\Program Files (x86)\\jumpcloud-agent-app\\jumpcloud-agent-app.exe",
+        "?:\\Program Files\\PostgreSQL\\*\\bin\\pg_dumpall.exe",
+        "?:\\Program Files (x86)\\Vim\\vim*\\vimrun.exe") and
+  not (
+        /* Crowdstrike doesn't populate process.parent.executable */
+        data_stream.dataset == "crowdstrike.fdr" and
+        process.parent.name : (
+          "perl.exe", "node.exe", "pg_dumpall.exe", "PRTG Server.exe", "spiceworks-finder.exe", "leds.exe", "twexec.exe",
+          "SonarScanner.MSBuild.exe", "Code.exe", "netbeans64.exe", "javaw.exe", "Bot Framework Composer.exe", "SessionMgr.exe",
+          "Craneware.Pricing.Shell.exe", "jumpcloud-agent-app.exe", "vimrun.exe"
+        )
+      ) and
+  not (process.args :  "?:\\Program Files\\Citrix\\Secure Access Client\\nsauto.exe" and process.parent.name : "userinit.exe") and
+  not process.args : (
+        "?:\\Program Files (x86)\\PCMatic\\PCPitstopScheduleService.exe",
+        "?:\\Program Files (x86)\\AllesTechnologyAgent\\*",
+        "https://auth.axis.com/oauth2/oauth-authorize*"
+  ) and
+  not process.command_line : (
+    "\"cmd\" /c %NETBEANS_MAVEN_COMMAND_LINE%",
+    "?:\\Windows\\system32\\cmd.exe /q /d /s /c \"npm.cmd ^\"install^\" ^\"--no-bin-links^\" ^\"--production^\"\""
+  ) and
+  not (process.name : "cmd.exe" and process.args : "%TEMP%\\Spiceworks\\*" and process.args : "http*/dataloader/persist_netstat_data") and
+  not (process.args == "echo" and process.args == "GEQ" and process.args == "1073741824")
+
+----------------------------------
+
+*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: Windows Command Shell
+** ID: T1059.003
+** Reference URL: https://attack.mitre.org/techniques/T1059/003/
+* 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/
+* Technique:
+** Name: System Binary Proxy Execution
+** ID: T1218
+** Reference URL: https://attack.mitre.org/techniques/T1218/
+* Sub-technique:
+** Name: Mshta
+** ID: T1218.005
+** Reference URL: https://attack.mitre.org/techniques/T1218/005/
+* Sub-technique:
+** Name: Regsvr32
+** ID: T1218.010
+** Reference URL: https://attack.mitre.org/techniques/T1218/010/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-system-public-ip-discovery-via-dns-query.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-system-public-ip-discovery-via-dns-query.asciidoc
new file mode 100644
index 0000000000..efce71e204
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-system-public-ip-discovery-via-dns-query.asciidoc
@@ -0,0 +1,235 @@
+[[prebuilt-rule-8-19-24-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 <<rule-schedule, `Additional look-back time`>>)
+
+*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*: 4
+
+*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 == "S-1-5-18"
+)
+
+----------------------------------
+
+*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-24/prebuilt-rule-8-19-24-uac-bypass-attempt-via-windows-directory-masquerading.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-uac-bypass-attempt-via-windows-directory-masquerading.asciidoc
new file mode 100644
index 0000000000..1dccffa304
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-uac-bypass-attempt-via-windows-directory-masquerading.asciidoc
@@ -0,0 +1,194 @@
+[[prebuilt-rule-8-19-24-uac-bypass-attempt-via-windows-directory-masquerading]]
+=== UAC Bypass Attempt via Windows Directory Masquerading
+
+Identifies an attempt to bypass User Account Control (UAC) by masquerading as a Microsoft trusted Windows directory. Attackers may bypass UAC to stealthily execute code with elevated permissions.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://medium.com/tenable-techblog/uac-bypass-by-mocking-trusted-directories-24a96675f6e
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Resources: Investigation Guide
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Windows Security Event Logs
+* Data Source: Microsoft Defender XDR
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+
+*Version*: 323
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating UAC Bypass Attempt via Windows Directory Masquerading*
+
+
+
+*Possible investigation steps*
+
+
+- Does the alert-local path prove execution from a mock trusted Windows directory?
+  - Why: This technique abuses a trailing-space "C:\Windows " tree that AppInfo checks can normalize while the fake path still executes.
+  - Focus: `process.executable` and `process.command_line`, especially "C:\Windows \System32\" or "C:\Windows \SysWOW64\" instead of the canonical Windows path.
+  - Implication: escalate when executable or argument paths contain the trailing-space trusted-directory clone; lower suspicion only when `process.executable` and `process.command_line` resolve to the canonical Windows path and later evidence does not contradict that.
+
+- Is the binary a copied auto-elevating Windows executable?
+  - Focus: `process.name`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.hash.sha256`.
+  - Implication: escalate when a signed Microsoft auto-elevating binary runs from the fake tree, name or PE metadata imitates one, or the hash is unfamiliar; if not auto-elevating, keep suspicious as path masquerading or staging until lineage and artifacts explain it.
+
+- Do the parent, user, and token context fit a UAC-bypass transition?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, `process.Ext.token.integrity_level_name`, and `process.Ext.token.elevation_level`.
+  - Implication: escalate when a browser, document process, script host, installer, or remote-admin parent launches the copied binary with high or full integrity; lower suspicion when parent, user, token state, and host cohort align with confirmed compatibility or security testing.
+
+- Did file events show the fake tree being staged before or by the alerting process?
+  - Focus: same-`host.id` file events where `file.path` is under "C:\Windows \", plus alert-process file events scoped by `process.entity_id` when present. !{investigate{"description":"","label":"File events for the suspicious process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: File telemetry is conditional; missing file events leave staging unresolved, not benign. Use `file.Ext.original.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier` only when the fake-tree writer is unclear.
+  - Implication: escalate when any process creates "C:\Windows \", copies the auto-elevating executable, or drops a same-directory DLL; lower suspicion only when fake-tree artifacts are bounded to controlled lab testing with no contradictory DLL or child-process evidence.
+
+- Did the copied binary load a sidecar DLL from the fake tree?
+  - Focus: library events scoped by `host.id` plus `process.entity_id` when present; review `dll.path`, `dll.hash.sha256`, and `dll.code_signature.subject_name`. !{investigate{"description":"","label":"Library events for the suspicious process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: Library telemetry is conditional; missing library events leave DLL payload execution unresolved, not benign.
+  - Implication: escalate when the copied binary loads a same-directory DLL from the fake tree, especially unsigned, unfamiliar, or mismatched; if no DLL evidence appears, continue to child-process review before treating execution as unresolved.
+
+- Did the copied binary spawn elevated follow-on code?
+  - Focus: same-`host.id` child processes where `process.parent.entity_id` matches `process.entity_id`; review child `process.command_line` and `process.Ext.token.integrity_level_name`. !{investigate{"description":"","label":"Child processes launched by the copied binary","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the copied binary spawns high-integrity shells, scripts, payloads, or unexpected admin tools; if no child appears, treat execution as unresolved unless path, binary, parent, file, and DLL evidence all support controlled lab testing.
+
+- If local evidence is suspicious or incomplete, is the same fake path or host showing related activity?
+  - Focus: related alerts for the same `process.executable` fake path, especially UAC-bypass, masquerading, or payload-staging detections; check same-host alert history for privilege-escalation, defense-evasion, or suspicious file-staging context.
+    - !{investigate{"description":"","label":"Alerts associated with the same fake executable path","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+    - !{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: escalate scope when the same fake path appears across hosts or the same host has surrounding staging, privilege-escalation, or defense-evasion alerts; keep scope local only when local evidence also supports controlled lab testing.
+
+- What disposition do the fake path, binary identity, lineage, artifacts, execution, and scope support?
+  - Escalate when path, binary identity, lineage, artifacts, execution, or scope show fake-tree UAC bypass; close only when all categories align with controlled lab testing and no contradictions remain; preserve artifacts and escalate when mixed or incomplete.
+
+
+*False positive analysis*
+
+
+- This behavior is an operational anti-pattern outside explicit testing. Authorized compatibility or security research can trigger it only when a team deliberately constructs a trailing-space Windows tree in a controlled lab. Confirm exact `process.executable`, stable `process.hash.sha256`, Microsoft signer and original file name, `process.parent.executable`, `user.id`, `host.id`, and sidecar-DLL behavior against the same test. If test plans exist, require alignment; otherwise rely on prior alerts for the same path, hash, parent workflow, and lab cohort without unexpected elevated children.
+- Do not treat a signed Microsoft binary or lab host as sufficient. Same-directory DLL load, elevated shell, suspicious parent, internet-provenance file event, or recurrence outside the expected cohort keeps the alert suspicious until the exact test scope explains it.
+- Before an exception, validate recurrence of the minimum workflow pattern: exact `process.executable`, stable `process.hash.sha256`, `process.parent.executable`, expected sidecar-DLL behavior, and bounded `host.id` or `user.id` cohort. Avoid exceptions on "C:\Windows " alone, binary name alone, or `host.id` alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and record the exact fake-tree path, copied binary hash, parent workflow, user/host cohort, and sidecar-DLL behavior that proved the recognized workflow. Create an exception only after that same pattern recurs consistently for this rule.
+- If suspicious but unconfirmed, preserve a case export for the alert process, parent chain, token context, fake-tree directory, copied binary, sidecar DLLs and hashes, and any elevated child details before containment. Apply reversible containment next, such as restricting execution from the fake tree or isolating the affected host if sidecar loading, elevated children, or broader post-exploitation evidence is active.
+- If confirmed malicious, collect the copied auto-elevating binary and sidecar DLLs, preserve process, file, and library telemetry, then isolate the host after weighing business criticality. Scope other hosts for the same fake path, copied binary hash, and DLL pattern before killing processes, deleting the fake "system32" tree, and remediating the launcher or access path that staged it.
+- Post-incident hardening: remove the fake trailing-space directory tree, restrict creation or execution of copied Windows binaries from user-writable or fake trusted paths, retain file/library/process telemetry for same-directory DLL hijacking, and record the recovered auto-elevating-binary and DLL pair 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/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.args : ("C:\\Windows \\system32\\*.exe", "C:\\Windows \\SysWOW64\\*.exe")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Abuse Elevation Control Mechanism
+** ID: T1548
+** Reference URL: https://attack.mitre.org/techniques/T1548/
+* Sub-technique:
+** Name: Bypass User Account Control
+** ID: T1548.002
+** Reference URL: https://attack.mitre.org/techniques/T1548/002/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Masquerading
+** ID: T1036
+** Reference URL: https://attack.mitre.org/techniques/T1036/
+* Sub-technique:
+** Name: Match Legitimate Resource Name or Location
+** ID: T1036.005
+** Reference URL: https://attack.mitre.org/techniques/T1036/005/
+* Technique:
+** Name: Abuse Elevation Control Mechanism
+** ID: T1548
+** Reference URL: https://attack.mitre.org/techniques/T1548/
+* Sub-technique:
+** Name: Bypass User Account Control
+** ID: T1548.002
+** Reference URL: https://attack.mitre.org/techniques/T1548/002/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc
new file mode 100644
index 0000000000..e89b0a8871
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc
@@ -0,0 +1,187 @@
+[[prebuilt-rule-8-19-24-uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface]]
+=== UAC Bypass Attempt with IEditionUpgradeManager Elevated COM Interface
+
+Identifies attempts to bypass User Account Control (UAC) by abusing an elevated COM Interface to launch a rogue Windows ClipUp program. Attackers may attempt to bypass UAC to stealthily execute code with elevated permissions.
+
+*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*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/hfiref0x/UACME
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Microsoft Defender XDR
+* Data Source: SentinelOne
+* Resources: Investigation Guide
+
+*Version*: 314
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating UAC Bypass Attempt with IEditionUpgradeManager Elevated COM Interface*
+
+
+
+*Possible investigation steps*
+
+
+- Does the alert show the IEditionUpgradeManager ClipUp bypass path?
+  - Focus: `process.name`, `process.executable`, `process.parent.name`, `process.parent.args`, and `process.Ext.token.elevation_level`.
+  - Hint: absent token metadata does not lower suspicion; the path and COM parent args still define the bypass path.
+  - Implication: a "dllhost.exe" broker, IEditionUpgradeManager CLSID, "ClipUp.exe" name, and non-System32 path warrant UAC bypass investigation; high or full elevation raises priority. Concern drops only when later identity and child checks bind to exact servicing or authorized testing.
+
+- Is the non-system ClipUp image a genuine Microsoft servicing component or an attacker-defined payload?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Hint: absent hash, signature, or PE metadata does not lower suspicion; fall back to path, COM args, command line, and child behavior.
+  - Implication: treat the image as attacker-controlled when unsigned, not Microsoft-signed, mismatched to "ClipUp.exe", or in a user-writable root. A Microsoft signer, matching original name, and stable hash reduce suspicion only when the same path ties to the servicing package under review.
+
+- Does the path or runtime metadata fit system-directory spoofing or lookalike staging?
+  - Why: the alert already proves ClipUp ran outside genuine System32; a writable root ending in "\system32\clipup.exe" is the staging clue.
+  - Focus: `process.executable`, `process.Ext.relative_file_creation_time`, `process.Ext.relative_file_name_modify_time`, and `process.command_line`.
+  - Hint: absent relative timing fields leave the issue unresolved; use path root, command line, signer/hash, and local process history.
+  - Implication: temp, profile, writable-share, or other non-Windows roots ending in "\system32\clipup.exe" indicate system-directory spoofing, especially with recent create or rename timing. Stable path age and servicing arguments reduce concern only after image identity also fits.
+
+- Did the elevated ClipUp instance start follow-on tooling?
+  - Focus: child process starts where `process.parent.entity_id` matches `process.entity_id`, reviewing `process.name`, `process.executable`, `process.command_line`, and `process.Ext.token.integrity_level_name`. !{investigate{"description":"","label":"Child processes launched by the rogue ClipUp instance","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"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `process.entity_id` is absent, recover children with `host.id` + `process.pid` in a tight alert-time window; an empty child search is unresolved, not benign.
+  - Implication: shells, script hosts, LOLBins, installers, or security-control tooling turn the alert into post-elevation execution. No visible child keeps the case scoped to the bypass launch, not closed.
+
+- Where else did this exact ClipUp pattern run?
+  - Focus: matching process starts by `process.hash.sha256`, `process.executable`, `process.parent.args`, and `process.Ext.token.elevation_level`, scoped by `host.id` and `user.id`.
+  - Hint: if the hash or elevation field is absent, pivot on the exact `process.executable` + `process.parent.args` pair and keep the time window tight. !{investigate{"description":"","label":"Process events for the same ClipUp path and COM interface","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"},{"excluded":false,"field":"process.parent.args","queryType":"phrase","value":"{{process.parent.args}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: after local evidence remains suspicious or unresolved, use matching path, hash, COM args, and elevation state to scope hosts or users; recurrence is supporting context, not a reason to close over contradictory local evidence.
+
+- Escalate when the COM-brokered non-system ClipUp launch pairs with attacker-defined identity, system-directory spoofing clues, unexpected elevation, or suspicious children. Close only when alert-local process evidence and supported child/history recovery bind to one confirmed servicing package or authorized OS-image test; require external confirmation when telemetry cannot prove that exact activity. Preserve evidence and escalate when answers remain mixed or incomplete.
+
+
+*False positive analysis*
+
+
+- Windows edition upgrade, activation, or repair servicing can explain ClipUp activity only when evidence converges on one workflow: Microsoft-signed `process.hash.sha256`, expected `process.executable`, IEditionUpgradeManager `process.parent.args`, compatible `process.Ext.token.integrity_level_name` when present, and no suspicious children. If change records are unavailable, require telemetry confirmation from the same signed hash, path, parent args, `host.id`, and `user.id` pattern on the same host.
+- Treat non-System32 ClipUp as an operational anti-pattern outside servicing. The only other benign path is an authorized OS-image or lab test where `process.executable`, `process.hash.sha256`, `process.command_line`, `process.parent.executable`, `process.parent.args`, and `user.id` all match the exact test case. Any unsigned image, writable-profile path, or elevated child tooling contradicts this explanation.
+- Before creating an exception, require a stable benign pattern for `process.executable`, `process.hash.sha256`, `process.parent.args`, `process.Ext.token.integrity_level_name`, and relevant `host.id` or `user.id`. Avoid exceptions on `process.name`, `process.parent.name`, or the COM CLSID alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and record the image identity, broker context, token state, `host.id`, and `user.id` that proved the servicing or deployment workflow. Create an exception only after the same full pattern repeats benignly.
+- If suspicious but unconfirmed, preserve the alert, endpoint timeline export, process tree, non-system ClipUp path and hash, IEditionUpgradeManager parent context, token details, and recovered child-process evidence before containment.
+- If suspicious but unconfirmed, apply reversible containment tied to the findings: block the non-system ClipUp path or hash, end the associated user session when needed, or raise monitoring on the affected `host.id`. Isolate the host only if elevated children, control tampering, or broader suspicious process history raises impact.
+- If confirmed malicious, isolate the host, terminate the rogue ClipUp instance and elevated children after recording their process identifiers, and block the confirmed path or hash. Review the same hash, path, COM parent args, and user across other hosts before deleting artifacts.
+- Eradicate only the staged ClipUp copy, launched payloads, persistence, or launcher artifacts identified during the investigation, then restore affected controls and validate that the Windows servicing path uses the genuine System32 binary.
+- Post-incident hardening: restrict system-binary lookalikes from user-writable paths with WDAC or AppLocker, retain process lineage and token telemetry for elevated COM abuse, and document any missing telemetry or uncovered variant with the preserved evidence set.
+
+
+==== 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.name : "Clipup.exe" and
+  not process.executable : "C:\\Windows\\System32\\ClipUp.exe" and process.parent.name : "dllhost.exe" and
+  /* CLSID of the Elevated COM Interface IEditionUpgradeManager */
+  process.parent.args : "/Processid:{BD54C901-076B-434E-B6C7-17C531F4AB41}"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Abuse Elevation Control Mechanism
+** ID: T1548
+** Reference URL: https://attack.mitre.org/techniques/T1548/
+* Sub-technique:
+** Name: Bypass User Account Control
+** ID: T1548.002
+** Reference URL: https://attack.mitre.org/techniques/T1548/002/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Abuse Elevation Control Mechanism
+** ID: T1548
+** Reference URL: https://attack.mitre.org/techniques/T1548/
+* Sub-technique:
+** Name: Bypass User Account Control
+** ID: T1548.002
+** Reference URL: https://attack.mitre.org/techniques/T1548/002/
+* 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-24/prebuilt-rule-8-19-24-uac-bypass-via-icmluautil-elevated-com-interface.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-uac-bypass-via-icmluautil-elevated-com-interface.asciidoc
new file mode 100644
index 0000000000..6415e2d44e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-uac-bypass-via-icmluautil-elevated-com-interface.asciidoc
@@ -0,0 +1,189 @@
+[[prebuilt-rule-8-19-24-uac-bypass-via-icmluautil-elevated-com-interface]]
+=== UAC Bypass via ICMLuaUtil Elevated COM Interface
+
+Identifies User Account Control (UAC) bypass attempts via the ICMLuaUtil Elevated COM interface. Attackers may attempt to bypass UAC to stealthily execute code with elevated permissions.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-endpoint.events.process-*
+* logs-windows.sysmon_operational-*
+* endgame-*
+* 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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/hfiref0x/UACME
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Microsoft Defender XDR
+* Resources: Investigation Guide
+
+*Version*: 215
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating UAC Bypass via ICMLuaUtil Elevated COM Interface*
+
+
+
+*Possible investigation steps*
+
+
+- What did the auto-elevated COM broker launch?
+  - Focus: `process.name`, `process.executable`, `process.command_line`, `process.pe.original_file_name`, and `process.parent.args`.
+  - Implication: escalate when the CLSID-specific broker launched a shell, script host, LOLBin, installer, user-writable binary, or relaunched payload; lower suspicion when the child is a signed Windows or endpoint-management helper whose protected path and arguments fit one recognized servicing or support workflow.
+
+- Does the elevated child look like a stable trusted binary or a staged payload?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.Ext.relative_file_creation_time`.
+  - Implication: escalate when the child is unsigned, new, user-writable, renamed, hash-new, or PE-mismatched; lower suspicion only when identity, signer, age, and path fit a stable installed component.
+
+- Did the child receive an elevation state that changes risk for this user session?
+  - Focus: `process.Ext.token.integrity_level_name`, `process.Ext.token.elevation_level`, `process.Ext.authentication_id`, and `user.id`.
+  - Implication: escalate when a limited or interactive user context produced a high-integrity or full-elevation child without a matching maintenance task; lower suspicion when token and session align with a recognized elevated admin utility for the same user.
+
+- Which process initiated the brokered elevation behind `dllhost.exe`?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.effective_parent.executable`, and `process.Ext.effective_parent.name`.
+  - Hint: if effective-parent fields are absent or repeat `dllhost.exe`, recover broader lineage and keep origin attribution unresolved rather than treating the COM broker as the real launcher.
+  - Implication: escalate when the logical initiator is a script host, archive/temp path, renamed binary, remote-access tool, or unexplained user process; lower suspicion when it resolves to the same signed Windows or endpoint-management workflow as the child.
+
+- Did the elevated child spawn payloads, shells, or other post-elevation tools?
+  - Focus: child process events from `process.entity_id`, checking `process.name`, `process.executable`, `process.command_line`, and `process.parent.executable`. !{investigate{"description":"","label":"Child processes launched by the elevated child 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"}}
+  - Hint: if `process.entity_id` is absent, recover children with `host.id` plus `process.pid` in a tight alert-time window and treat PID reuse as ambiguous.
+  - Implication: escalate when the elevated child starts shells, script hosts, LOLBins, security-tool tampering, or payloads outside the recognized workflow; if no child process appears, scope the case to the broker launch rather than assuming the bypass failed.
+
+- If local evidence is suspicious or incomplete, does surrounding alert context expand scope?
+  - Focus: related alerts for `host.id`, especially privilege-escalation, defense-evasion, masquerading, suspicious child-process, or tampering findings tied to `process.parent.args` or `process.executable`. !{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"}}
+  - Hint: compare `user.id` alerts only to decide whether elevation is host-local or follows the user. !{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: pivot on same executable and COM parent arguments. !{investigate{"description":"","label":"Process events for the same child and COM interface","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"},{"excluded":false,"field":"process.parent.args","queryType":"phrase","value":"{{process.parent.args}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden response scope when the same host or user also shows UAC-bypass, masquerading, or post-elevation execution; keep scope local when surrounding alerts are clean and broker, child, token, and follow-on evidence are coherent.
+
+- What disposition do the broker, child identity, launcher, token, follow-on activity, and scope support?
+  - Escalate on unauthorized brokered CLSID launch, child identity, launcher, token, child-process, or alert-scope evidence; close only when alert-local and recovered process evidence bind one exact recognized workflow with no contradictory follow-on activity; preserve and escalate on mixed or incomplete evidence.
+
+
+*False positive analysis*
+
+
+- Legitimate closure is narrow: signed Windows or enterprise endpoint-management helpers may use the elevated COM broker during servicing or support. Align identity (`process.executable`, signer, hash, and PE original name), broker context (`process.parent.args` and effective parent), token state, and absence of contradictory child-process or alert-scope evidence. Recently staged helpers also need `process.Ext.relative_file_creation_time`, hash or signer, parent context, and command line to fit the same update workflow; require outside confirmation when telemetry cannot explain the elevation.
+- If workflow context is unavailable, recurrence for the same `host.id` or `user.id` can support the conclusion but cannot override contradictory local evidence.
+- Before creating an exception, validate that child identity, signer or hash, `process.parent.args`, token state, and host or user scope stay stable across benign occurrences. Build the exception from that minimum confirmed pattern, and avoid exceptions on `process.parent.name`, `dllhost.exe`, or CLSID values alone.
+
+
+*Response and remediation*
+
+
+- First, export the alert details, process tree, command line, hash/signature identity, token state, effective-parent evidence, and recovered child-process or related-alert records.
+- If confirmed benign after preservation, reverse temporary containment and document the validated child identity, broker CLSID, effective parent, token state, `host.id`, and `user.id` values that proved the workflow. Create an exception only after the same complete pattern repeats benignly.
+- If suspicious but unconfirmed, apply reversible containment tied to the finding: block the suspicious `process.executable`, end the associated user session, or raise monitoring on the same `host.id`. Use host isolation only when the elevated child spawned payloads or coincided with tampering or lateral-movement evidence.
+- If confirmed malicious, isolate the host when needed to prevent lateral movement, then terminate the elevated child and payloads using the preserved `process.entity_id`, `process.hash.sha256`, command line, broker CLSID, token state, and `@timestamp`. If direct response is unavailable, hand off the preserved process, child-process, and scope evidence to the response team.
+- Review other hosts and users for the same `process.parent.args`, `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, or `user.id` before removing artifacts so scoping completes before evidence is destroyed.
+- Eradicate only the staged helper binary, launched payloads, persistence changes, and launcher artifacts identified during the investigation, then restore affected controls and service configuration to a known-good state.
+- Post-incident hardening: reduce local administrator membership where possible, set UAC to the highest practical enforcement level, restrict system lookalike or helper binaries from user-writable paths, prefer WDAC or AppLocker coverage for admin helpers, and retain process telemetry around elevated COM abuse.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+ process.parent.name == "dllhost.exe" and
+ process.parent.args in ("/Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}", "/Processid:{D2E7041B-2927-42FB-8E9F-7CE93B6DC937}") and
+ process.pe.original_file_name != "WerFault.exe" and
+ not (process.executable : "?:\\Program Files\\WireGuard\\wireguard.exe" and process.args : "/installmanagerservice")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Abuse Elevation Control Mechanism
+** ID: T1548
+** Reference URL: https://attack.mitre.org/techniques/T1548/
+* Sub-technique:
+** Name: Bypass User Account Control
+** ID: T1548.002
+** Reference URL: https://attack.mitre.org/techniques/T1548/002/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Abuse Elevation Control Mechanism
+** ID: T1548
+** Reference URL: https://attack.mitre.org/techniques/T1548/
+* Sub-technique:
+** Name: Bypass User Account Control
+** ID: T1548.002
+** Reference URL: https://attack.mitre.org/techniques/T1548/002/
+* 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-24/prebuilt-rule-8-19-24-untrusted-driver-loaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-untrusted-driver-loaded.asciidoc
new file mode 100644
index 0000000000..0a0b90fe7c
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-untrusted-driver-loaded.asciidoc
@@ -0,0 +1,164 @@
+[[prebuilt-rule-8-19-24-untrusted-driver-loaded]]
+=== Untrusted Driver Loaded
+
+Identifies an untrusted driver loaded by the Windows kernel. Adversaries may modify code signing policies to enable execution of unsigned or self-signed kernel code.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.library-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/hfiref0x/TDL
+* https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn653559(v=vs.85)?redirectedfrom=MSDN
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+* Data Source: Elastic Defend
+
+*Version*: 14
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Untrusted Driver Loaded*
+
+
+
+*Possible investigation steps*
+
+
+- What exact kernel driver loaded, and what trust failure made it alert?
+  - Focus: `process.pid`, `dll.path`, `dll.code_signature.exists`, `dll.code_signature.trusted`, and `dll.code_signature.status`.
+  - Implication: escalate when System loaded an unsigned or untrusted driver from a non-vendor, user-writable, temp, or renamed path; lower concern only when the trust failure fits a controlled driver-development or hardware-validation host class.
+
+- Does the driver identity map to a known vulnerable driver, BYOVD chain, or offensive loader?
+  - Why: TDL-style and BYOVD activity may be easier to recognize by stable hash, original PE name, or signer than current file name.
+  - Focus: `dll.hash.sha256`, `dll.pe.original_file_name`, `dll.code_signature.subject_name`, and `dll.code_signature.thumbprint_sha256`.
+  - Implication: escalate when hash, original name, or signer maps to a vulnerable-driver blocklist, signature-bypass loader, or malicious kernel tooling; lower concern only when the same artifact is tied to a controlled lab or validation cohort.
+
+- Does recency or rename timing show the driver was staged for this load?
+  - Focus: `dll.Ext.relative_file_creation_time`, `dll.Ext.relative_file_name_modify_time`, and `dll.path`; if file-event telemetry is available, use the same `host.id` and path to identify who wrote or renamed it. !{investigate{"description":"","label":"File events for the loaded driver path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{dll.path}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the driver appeared just before load, was recently renamed, or was written by an unrelated staging process. Missing file-event telemetry leaves provenance unresolved, not benign.
+
+- What resident service or device identity is tied to the loaded image?
+  - Focus: compare `dll.path`, `dll.hash.sha256`, and `dll.code_signature.subject_name` with current Osquery driver inventory and service output.
+  - Hint: For non-Microsoft drivers by `image`, `service`, `signed`, `subject_name`, and `VtLink`; use it as current-state context, and keep the alert as the historical load record if no matching image exists.
+    - !{osquery{"label":"Osquery - Retrieve All Non-Microsoft Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE NOT (provider == \"Microsoft\" AND signed == \"1\")\n"}}
+  - Hint: For unsigned current drivers when the alert shows missing or untrusted signature metadata; current signed or service values do not prove what existed at `@timestamp`.
+    - !{osquery{"label":"Osquery - Retrieve All Unsigned Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE signed == \"0\"\n"}}
+  - Implication: escalate when current inventory lacks a coherent image or service entry, the service is unexpected for the host, or other unsigned drivers do not fit the host role. Treat osquery as corroboration; do not delay escalation when alert-local identity, trust, or recency evidence is decisive.
+
+- Did signing or code-integrity control activity make this load possible?
+  - Why: 64-bit Windows normally enforces kernel-mode driver signing, while test-signing, DSE tampering, or vulnerable-driver loaders can open a path for untrusted kernel code.
+  - Focus: same-host process events around the load using `host.id`, `process.name`, `process.executable`, and `process.command_line` for bcdedit test-signing/nointegritychecks changes or known vulnerable-driver loader activity. !{investigate{"description":"","label":"Process events on the driver host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when surrounding process evidence shows test-signing changes, code-integrity bypass tooling, or vulnerable-driver loader execution; absent process evidence weakens this corroborator but does not clear an unexplained untrusted driver load.
+
+- Does the host cohort and prevalence fit a controlled driver workflow?
+  - Focus: `host.id`, `host.name`, and the smallest stable indicator, usually `dll.hash.sha256`, `dll.path`, or `dll.code_signature.subject_name`.
+  - Hint: broaden only when identity, recency, inventory, or tampering evidence remains suspicious or unresolved. !{investigate{"description":"","label":"Alerts associated with the driver identity","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"dll.hash.sha256","queryType":"phrase","value":"{{dll.hash.sha256}}","valueType":"string"}],[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"dll.path","queryType":"phrase","value":"{{dll.path}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate when the driver appears on production systems, user-writable paths, unrelated hosts, or outside the expected lab cohort; lower concern only when artifact, path pattern, signer, and host cohort consistently match a controlled validation workflow.
+
+- Using identity, trust failure, staging/provenance, osquery inventory, signing-control evidence, and host-cohort spread: escalate unauthorized kernel code, BYOVD, or signature-bypass evidence; close only when telemetry binds the load to one controlled driver workflow; preserve artifacts and escalate mixed or incomplete cases.
+
+
+*False positive analysis*
+
+
+- Controlled driver-development, OEM hardware validation, and authorized security or EDR compatibility testing can load test-signed or unsigned drivers on isolated lab hosts. Confirm first with telemetry: `dll.hash.sha256`, `dll.path`, `dll.code_signature.status` or `dll.code_signature.subject_name`, current osquery image and service output, and `host.id` cohort must align with one workflow. Use build, test, or change records only after telemetry binds the exact artifact and cohort; if unavailable, require prior alerts for the same driver artifact and host cohort before exceptioning. If any evidence dimension contradicts the workflow, do not close as benign.
+- Build exceptions only from the minimum confirmed pattern, such as `dll.hash.sha256` plus `dll.path` plus bounded `host.id` cohort or service identity. Avoid exceptions on `dll.name`, signer, or generic unsigned-driver conditions alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign:
+  - Reverse temporary containment and document the driver artifact, host cohort, current osquery image and service values, and any corroborating external record. Keep exceptions narrow to the confirmed hash, path, host cohort, or service identity.
+- If suspicious but unconfirmed:
+  - Preserve the driver file if accessible, the alert event export, osquery driver inventory results, surrounding signing-control process events, and the case timeline before containment or cleanup.
+  - Apply reversible containment first, such as temporary network restriction or heightened monitoring, while scoping the same `dll.hash.sha256` or `dll.path` across other hosts.
+  - Escalate to host isolation before reboot, uninstall, or cleanup only if evidence shows code-integrity tampering, vulnerable-driver loader activity, post-load abuse, or spread outside the expected lab cohort.
+- If confirmed malicious:
+  - Isolate the host after preserving the driver artifact, service or boot-start context, signing-control evidence, and affected `host.id` or `host.name`. If endpoint response is unavailable, hand off that evidence set to the team that can contain the system.
+  - Scope other hosts for the same `dll.hash.sha256`, `dll.path`, or `dll.code_signature.subject_name` before uninstalling the driver, deleting the file, removing the backing service, or rebooting.
+  - Remove the malicious driver, related service or boot-start entry, and code-signing or DSE changes identified during investigation, then remediate the loader or vulnerable-driver path that introduced it.
+- Post-incident hardening:
+  - Re-enable or enforce driver-signing and code-integrity controls on the affected host class, block confirmed malicious or vulnerable `dll.hash.sha256` values and `dll.path` locations, and restrict test-signing to isolated lab systems.
+  - Document any BYOVD family, loader service name, or host-cohort pattern uncovered during triage for future response cases.
+
+
+==== 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]
+----------------------------------
+driver where host.os.type == "windows" and process.pid == 4 and
+  (dll.code_signature.trusted == false or dll.code_signature.exists == false) and
+  /* errorExpired and errorRevoked are handled by d12bac54-ab2a-4159-933f-d7bcefa7b61d */
+  not dll.code_signature.status : ("errorExpired", "errorRevoked", "errorCode_endpoint:*") and
+  
+  /* HP DOT4 printer driver family FPs (Dot4.sys, Dot4Prt.sys, Dot4usb.sys, Dot4Scan.sys) */
+  not dll.hash.sha256 : (
+        "f21c1d478180bc5e932bb2c2e4618e3ed463ca87acedeb139682d218435f82f1",
+        "7e2f2a139e897eae56038b920bda9381094bc0ae9e626f6634e6b444b8b0c91f",
+        "12ffdf5f48a79b1b4adbb88ba2cb6c59dd6719554e8ea6beefe99b3e3c66f1ac",
+        "dbc6afaf80141e2480e19878f581edfe9c2b018da2ec527c4025ff04d5587afd"
+  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Masquerading
+** ID: T1036
+** Reference URL: https://attack.mitre.org/techniques/T1036/
+* Sub-technique:
+** Name: Invalid Code Signature
+** ID: T1036.001
+** Reference URL: https://attack.mitre.org/techniques/T1036/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-unusual-child-process-of-dns-exe.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-unusual-child-process-of-dns-exe.asciidoc
new file mode 100644
index 0000000000..f4436a4870
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-unusual-child-process-of-dns-exe.asciidoc
@@ -0,0 +1,185 @@
+[[prebuilt-rule-8-19-24-unusual-child-process-of-dns-exe]]
+=== Unusual Child Process of dns.exe
+
+Identifies an unexpected process spawning from dns.exe, the process responsible for Windows DNS server services, which may indicate activity related to remote code execution or other forms of exploitation.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/
+* https://msrc-blog.microsoft.com/2020/07/14/july-2020-security-update-cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/
+* https://github.com/maxpl0it/CVE-2020-1350-DoS
+* https://www.elastic.co/security-labs/detection-rules-for-sigred-vulnerability
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Lateral Movement
+* Resources: Investigation Guide
+* Data Source: Elastic Endgame
+* Use Case: Vulnerability
+* Data Source: Elastic Defend
+* Data Source: Windows Security Event Logs
+* Data Source: Microsoft Defender XDR
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+
+*Version*: 320
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Unusual Child Process of dns.exe*
+
+
+*Possible investigation steps*
+
+
+- What did "dns.exe" launch, and does that define a crash path or live execution path?
+  - Focus: `process.name`, `process.executable`, `process.command_line`, and `process.parent.executable`.
+  - Implication: escalate quickly for shells, script hosts, downloaders, service tools, or non-Windows paths spawned by "dns.exe"; a bounded "WerFault.exe" crash-reporting child points toward DNS service fault or SIGRed DoS, but still needs follow-on checks.
+- Is the child binary a recognized system or DNS-support component, or a disguised payload?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the child is unsigned, renamed, user-writable, newly seen, or PE-mismatched; a recognized Microsoft or vendor identity lowers only identity concern and does not clear unexpected execution from "dns.exe".
+- What intent does the child command line express?
+  - Focus: `process.command_line`, `process.name`, and `process.Ext.token.integrity_level_name`.
+  - Implication: escalate for discovery, script interpretation, download, service change, credential, or persistence behavior under the DNS service token; crash-reporting or bounded diagnostic arguments support fault handling.
+- Do lineage and session context fit the Windows DNS service?
+  - Focus: `process.parent.command_line`, `process.parent.entity_id`, `process.Ext.session_info.logon_type`, and `user.id`.
+  - Implication: escalate when parent, service, or user context does not fit a stable Windows DNS service launch; expected service lineage supports but does not prove a benign child.
+- Did the child produce follow-on execution or artifacts after the spawn?
+  - Focus: recovered file, registry, network, DNS, and descendant process events for `host.id` + child `process.entity_id`, or `host.id` + `process.pid` in a tight alert window.
+    - !{investigate{"description":"","label":"File and registry events for the same child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Network events for the same child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Child process events from the dns.exe child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: prioritize descendant `process.command_line`, `file.path`, `registry.path`, and `destination.ip`. Missing network telemetry is unresolved, not benign.
+  - Implication: escalate when recovered events show descendants, payload staging, persistence changes, or outbound activity; no follow-on activity supports a crash-only hypothesis but cannot clear the alert alone.
+- If local evidence remains suspicious or unresolved, do same-host alerts show the same DNS-service execution pattern?
+  - Focus: same-parent process starts and related alerts on `host.id`, prioritizing `process.parent.name` of "dns.exe", the same child `process.executable`, or the same `process.hash.sha256`.
+    - !{investigate{"description":"","label":"Process events from the same dns.exe parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","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"}}
+  - Hint: broaden scope only after child identity, command intent, lineage, or follow-on recovery remains suspicious or incomplete.
+  - Implication: escalate scope when related alerts repeat the "dns.exe" child pattern or child binary identity; unrelated or nonmatching alerts keep the case narrower.
+- Escalate for live execution intent, suspicious identity or lineage, or recovered post-exploitation artifacts; close only when evidence tightly binds one crash-handling or recognized DNS-support workflow on this host; preserve artifacts and escalate when evidence is mixed or incomplete.
+
+
+*False positive analysis*
+
+
+- Crash handling can legitimately produce "WerFault.exe" after a DNS service fault or SIGRed DoS attempt. Confirm that child identity, `process.command_line`, signer, and `host.id` form a crash-reporting pattern and recovered follow-on endpoint activity does not contradict it. Use incident records only as corroboration; telemetry-only closure requires a crash-reporter-only pattern on the same `host.id` without payload descendants or artifact creation.
+- Named DNS/security tooling, such as ReasonLabs DNS components in the rule exclusions, explains the alert only when exact `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `process.parent.executable`, and `host.id` match that product workflow. Treat generic vendor claims, partial matches, or a trusted signer without matching behavior as unresolved.
+- Before creating an exception, anchor it on exact child path, signer or certificate thumbprint when available, command line, parent DNS service path, and affected `host.id`. Avoid exceptions on `process.parent.name` of "dns.exe", `process.name` alone, or the entire host.
+
+
+*Response and remediation*
+
+
+- If suspicious but unconfirmed, preserve the child `process.entity_id`, `process.executable`, `process.hash.sha256`, signer details, `process.command_line`, `process.parent.command_line`, crash dumps, recovered endpoint events, and any collected payload artifacts before containment.
+- Apply reversible containment before destructive action: remove the server from DNS rotation, restrict external resolver exposure, or heighten monitoring on the affected `host.id`. Move to host isolation only when follow-on execution or broader compromise evidence shows the server cannot serve safely.
+- If confirmed benign, reverse temporary containment and record the exact child path, signer, command line, parent DNS service path, and `host.id` that proved the crash-handling or DNS-support workflow. Create an exception only after the same pattern is stable across prior alerts.
+- If confirmed malicious, weigh DNS/domain-controller criticality, then isolate the server when feasible, terminate the suspicious child and descendants after evidence capture, and block confirmed malicious domains, IPs, hashes, or payload paths identified during triage.
+- Scope other DNS servers and domain controllers for the same child path, hash, command line, signer, or "dns.exe" child-process pattern before deleting artifacts or rebuilding systems.
+- Eradicate only payloads, persistence changes, or malicious child processes identified during the investigation, restore DNS service configuration from known-good state, and reset credentials only if evidence shows credential exposure or lateral movement from the server.
+- Post-incident hardening: apply the Microsoft DNS security update for CVE-2020-1350, remove temporary SIGRed workarounds only after patching is verified, and retain process plus file, registry, and network telemetry for DNS servers where gaps limited 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/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+- https://ela.st/audit-process-creation[Windows Process Creation Logs]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+  process.parent.name : "dns.exe" and
+  not process.executable : (
+    "?:\\Windows\\System32\\conhost.exe",
+    "?:\\Windows\\System32\\dns.exe",
+
+    /* Crowdstrike specific exclusion as it uses NT Object paths */
+    "\\Device\\HarddiskVolume*\\Windows\\System32\\conhost.exe",
+    "\\Device\\HarddiskVolume*\\Windows\\System32\\dns.exe",
+    "\\Device\\HarddiskVolume*\\Program Files\\ReasonLabs\\*"
+  ) and
+  not ?process.parent.executable : "?:\\Program Files\\ReasonLabs\\DNS\\ui\\DNS.exe"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Lateral Movement
+** ID: TA0008
+** Reference URL: https://attack.mitre.org/tactics/TA0008/
+* Technique:
+** Name: Exploitation of Remote Services
+** ID: T1210
+** Reference URL: https://attack.mitre.org/techniques/T1210/
+* Tactic:
+** Name: 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-24/prebuilt-rule-8-19-24-unusual-execution-via-microsoft-common-console-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-unusual-execution-via-microsoft-common-console-file.asciidoc
new file mode 100644
index 0000000000..97136b1ebf
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-unusual-execution-via-microsoft-common-console-file.asciidoc
@@ -0,0 +1,213 @@
+[[prebuilt-rule-8-19-24-unusual-execution-via-microsoft-common-console-file]]
+=== Unusual Execution via Microsoft Common Console File
+
+Identifies the execution of a child process from a Microsoft Common Console file. Adversaries may embed a malicious command in an MSC file in order to trick victims into executing malicious commands.
+
+*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*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.genians.co.kr/blog/threat_intelligence/facebook
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Execution
+* Tactic: Initial Access
+* Resources: Investigation Guide
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Microsoft Defender XDR
+* Data Source: SentinelOne
+
+*Version*: 208
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Unusual Execution via Microsoft Common Console File*
+
+
+
+*Possible investigation steps*
+
+
+- What ".msc" path and immediate child process triggered the alert?
+  - Focus: `process.parent.executable`, `process.parent.args`, `process.parent.command_line`, `process.executable`, and `process.command_line`.
+  - Implication: escalate when "mmc.exe" opens a user-writable, download, cloud-sync, archive-extraction, or document-like ".msc" and the child is a shell, script host, "mshta.exe", "schtasks.exe", or another LOLBin; lower suspicion only when the exact ".msc" path and child command fit a recognized administrative console workflow on this host.
+
+- Does the child command line expose second-stage or persistence intent?
+  - Focus: `process.command_line`, checking for "WScript.Shell", "schtasks /create", "OneDriveUpdate", "wscript.exe /b", "start /min", "mshta", ".hta", remote URLs, or script/batch names.
+  - Hint: review same-child file and network events for staged scripts, task artifacts, or remote retrieval. Missing network telemetry is unresolved, not benign. !{investigate{"description":"","label":"File and network events for the MMC-launched child","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.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the command creates tasks, hides/minimizes execution, starts script hosts, or embeds remote retrieval; lower suspicion only when the arguments perform a narrow helper action expected from the same console.
+
+- Does the child identity and session context fit expected administration?
+  - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.Ext.relative_file_creation_time`, and the `user.id` + `host.id` pair.
+  - Implication: escalate when the child runs from a user-writable or recently created path, has a signer mismatch, or appears under an unexpected administrative user/session; identity confirmation alone never clears an unsafe command line.
+
+- Do descendants continue the MSC-launched chain into scripting, tasks, or delayed execution?
+  - Why: MSC lures can store task commands that create a scheduled task, run VBS, then launch HTA through "mshta.exe"; the first child may be only the handoff.
+  - Focus: descendant starts on the same `host.id`, linked by `process.parent.entity_id` or `process.Ext.ancestry`, checking `process.name` and `process.command_line`. !{investigate{"description":"","label":"Descendant processes from the MMC-launched child","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"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if entity linkage is absent, match `process.parent.pid` to the alerting `process.pid` within a tight alert-time window and treat matches as weaker.
+  - Hint: after a suspicious descendant, expand that descendant's file and network events from Timeline.
+  - Implication: escalate when descendants show "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe", "powershell.exe", "pwsh.exe", "schtasks.exe", repeated shells, Microsoft-themed task names, or command-line URLs; lower suspicion when the tree ends at one expected helper with no delayed script or task process.
+
+- If local evidence remains suspicious or unresolved, what related alerts change scope or containment?
+  - Focus: related alerts for the same `user.id`, especially document delivery, script execution, task creation, or outbound 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: review same-`host.id` alerts to separate one-host lure execution from repeated activity across assets. !{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 containment when the same user or host also shows initial-access, script-host, scheduled-task, or outbound-staging alerts; keep response local when those alerts are absent, but leave benign closure to the process-chain synthesis.
+
+- Escalate for lure-driven ".msc" execution, script staging, scheduled-task creation, remote retrieval, or suspicious descendants; close only when alert-local evidence and process recovery bind one exact recognized console workflow with no contradictory descendants; preserve artifacts and escalate when evidence is mixed or visibility incomplete.
+
+
+*False positive analysis*
+
+
+- Custom administrative consoles, vendor MMC snap-ins, or IT troubleshooting bundles stored outside default Windows console paths can launch helpers, browsers, viewers, or support utilities. Confirm that `process.parent.args`, `process.parent.command_line`, `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `user.id`, and `host.id` all align with one exact console package or affected cohort. If inventory, ticketing, or owner confirmation is unavailable, close only when process and descendant telemetry still prove that helper workflow with no unresolved script, task, hidden execution, or remote-retrieval behavior.
+- Before creating an exception, validate prior alerts from this rule for the same ".msc" path in `process.parent.args`, child `process.executable`, signer in `process.code_signature.subject_name`, stable `process.command_line`, and bounded `user.id` and `host.id` scope. Build the exception from that full workflow pattern; avoid exceptions on `process.parent.name` value "mmc.exe" or the child `process.executable` alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse any temporary containment and document the exact ".msc" path, child command pattern, signer, `user.id`, and `host.id`. Create an exception only after the same workflow pattern recurs consistently across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve a case export for the alerting process instance (`host.id` plus `process.entity_id` or `process.pid` and alert time), the parent MSC path, child and descendant command lines, executable hash/signer, task names, script names, and URLs visible in command lines before making destructive changes. Apply reversible containment first, such as temporary URL/domain blocking, disabling a newly created scheduled task after preserving its command, or heightened monitoring on the affected `host.id` and `user.id`.
+- If confirmed malicious, isolate the host or contain the affected account only after preserving the process chain, scheduled-task names, script names, hashes, and command-line indicators. Terminate malicious child or descendant processes after preservation, block confirmed command-line URLs or domains, and hand off the preserved artifact set if endpoint response is unavailable.
+- Eradicate only the malicious ".msc", scripts, scheduled tasks, and staged payloads identified during the investigation, then remediate the delivery path that let the lure execute. Review related hosts and users for the same `process.parent.args` path or descendant `process.command_line` pattern before broad cleanup.
+- Post-incident hardening: restrict or warn on ".msc" launches from user-writable, download, archive-extraction, or cloud-sync paths, and retain process lineage and command-line telemetry needed to distinguish future admin consoles from MSC lures.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+  process.parent.executable : "?:\\Windows\\System32\\mmc.exe" and endswith~(process.parent.args, ".msc") and
+  not (
+    process.parent.args : (
+      "?:\\Windows\\System32\\*.msc",
+      "?:\\Windows\\SysWOW64\\*.msc",
+      "?:\\Program files\\*.msc",
+      "?:\\Program Files (x86)\\*.msc"
+    ) or
+    (
+      process.executable : "?:\\Windows\\System32\\mmc.exe" and
+      process.command_line : "\"C:\\WINDOWS\\system32\\mmc.exe\" \"C:\\Windows\\System32\\gpme.msc\" /s /gpobject:\"LDAP://*"
+    ) or
+    (
+      process.executable : (
+        "?:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe",
+        "?:\\Program Files\\Mozilla Firefox\\firefox.exe",
+        "?:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
+        "?:\\Program Files\\internet explorer\\iexplore.exe"
+      ) and
+      process.args : "http*://go.microsoft.com/fwlink/*"
+    ) or
+    process.executable : (
+      "?:\\Windows\\System32\\vmconnect.exe",
+      "?:\\Windows\\System32\\WerFault.exe",
+      "?:\\Windows\\System32\\wermgr.exe"
+    )
+  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: User Execution
+** ID: T1204
+** Reference URL: https://attack.mitre.org/techniques/T1204/
+* Sub-technique:
+** Name: Malicious File
+** ID: T1204.002
+** Reference URL: https://attack.mitre.org/techniques/T1204/002/
+* Tactic:
+** Name: 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: 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: MMC
+** ID: T1218.014
+** Reference URL: https://attack.mitre.org/techniques/T1218/014/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-user-added-to-the-admin-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-user-added-to-the-admin-group.asciidoc
new file mode 100644
index 0000000000..5121da79bc
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-user-added-to-the-admin-group.asciidoc
@@ -0,0 +1,125 @@
+[[prebuilt-rule-8-19-24-user-added-to-the-admin-group]]
+=== User Added to the Admin Group
+
+Identifies users being added to the admin group. This could be an indication of privilege escalation activity.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-jamf_protect*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.loobins.io/binaries/dscl/
+* https://managingosx.wordpress.com/2010/01/14/add-a-user-to-the-admin-group-via-command-line-3-0/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: macOS
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Data Source: Jamf Protect
+* Resources: Investigation Guide
+
+*Version*: 6
+
+*Rule authors*: 
+
+* Thijs Xhaflaire
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+To thoroughly investigate the actions that occurred **after a user was elevated to administrator**, it's essential to conduct a search on the Timeline. This allows you to review and understand the sequence of events that followed the elevation, helping to identify any potentially malicious or unauthorized activities that might have taken place. **Analyzing these actions is crucial for maintaining security and ensuring that the elevation was not exploited for harmful purposes.**
+
+**Consider reviewing these actions:**
+
+- Have persistency items been added?
+- Is any software installed after elevation?
+- Were any additional users created after elevation?
+
+!{investigate{"label":"Show events having the same responsible process","providers":[[{"excluded":false,"field":"host.hostname","queryType":"phrase","value":"{{host.hostname}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.group_leader.entity_id}}","valueType":"string"}]]}}
+!{investigate{"label":"Show events having the same parent process","providers":[[{"excluded":false,"field":"host.hostname","queryType":"phrase","value":"{{host.hostname}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]]}}
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from Jamf Protect.
+
+
+*Jamf Protect Integration Setup*
+
+Jamf Protect is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events incoming events and send data to the Elastic.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Jamf Protect.
+- 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 Jamf Protect integration:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Jamf Protect" and select the integration to see more details about it.
+- Click "Add Jamf Protect".
+- Configure the integration name.
+- Click "Save and Continue".
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+configuration where host.os.type == "macos" and event.type == "change" and
+  event.action == "od_group_add" and group.name:"admin"
+
+----------------------------------
+
+*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: Local Accounts
+** ID: T1078.003
+** Reference URL: https://attack.mitre.org/techniques/T1078/003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Sub-technique:
+** Name: Additional Local or Domain Groups
+** ID: T1098.007
+** Reference URL: https://attack.mitre.org/techniques/T1098/007/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc
new file mode 100644
index 0000000000..c2e7c85afa
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc
@@ -0,0 +1,162 @@
+[[prebuilt-rule-8-19-24-volume-shadow-copy-deleted-or-resized-via-vssadmin]]
+=== Volume Shadow Copy Deleted or Resized via VssAdmin
+
+Identifies use of vssadmin.exe for shadow copy deletion or resizing on endpoints. This commonly occurs in tandem with ransomware or other destructive attacks.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Impact
+* 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*: 318
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Volume Shadow Copy Deleted or Resized via VssAdmin*
+
+
+
+*Possible investigation steps*
+
+
+- What recovery-inhibition path does the alert-local command express?
+  - Focus: `process.command_line` and `process.args`; separate "delete shadows" with "/all", "/quiet", "/for=", "/oldest", or "/shadow=" from "resize shadowstorage" with "/for=", "/on=", and "/maxsize=".
+  - Implication: escalate faster when the command deletes all shadows, suppresses prompts, targets broad restore scope, or forces a tiny maximum; lower suspicion when it targets one volume, one shadow ID, or capacity-aligned resize inside a recognized retention, storage, or reset workflow.
+
+- Is the VssAdmin binary identity consistent with the tool being invoked?
+  - Focus: `process.executable`, `process.pe.original_file_name`, and, when available, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when path, PE metadata, hash, signer, or trust does not fit Microsoft VssAdmin; lower suspicion when identity matches the expected Microsoft tool, but identity never clears broad deletion or forced shrinkage.
+
+- Does the launcher and account explain why VssAdmin changed shadow-copy state?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, `user.name`, and `user.domain`.
+  - Implication: escalate when Office, a browser, script host, remote-access tool, or unusual account launches the command; lower suspicion when the parent and account match the same backup agent, deployment runner, storage-management console, image-prep script, or lab-reset workflow.
+
+- Are surrounding process events part of the same recovery-inhibition or impact chain?
+  - Why: destructive operators often pair VssAdmin with recovery tampering ("wmic shadowcopy delete", "diskshadow", "wbadmin delete catalog", "bcdedit recoveryenabled no", "reagentc /disable"), service stops, or encryption launchers.
+  - Focus: same-parent starts by `host.id` plus `process.parent.entity_id`; compare `process.name`, `process.command_line`, parent context, and timing. !{investigate{"description":"","label":"Process events from the same parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Range: start with the alert window through the next 15 minutes; expand only if the same lineage shows recovery tampering or encryption prep.
+  - Implication: escalate when the same lineage or short window shows backup deletion, recovery disablement, service stops, security-tool interference, or encryption tooling; lower suspicion when activity stays within one coherent maintenance or reset sequence.
+
+- If endpoint file telemetry is available, is destructive file impact already visible from this process or host?
+  - Focus: file events by `host.id` plus `process.entity_id`; fallback to `host.id`, `process.pid`, and a tight alert window, checking `file.path`, `file.extension`, and `file.Ext.original.extension`. !{investigate{"description":"","label":"File events from VssAdmin","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when file activity shows mass renames, unfamiliar extensions, ransom-note drops, or destructive cleanup after VssAdmin starts; absence of file telemetry is unresolved, not benign.
+
+- Do same-user or same-host alerts show spread beyond this VssAdmin event?
+  - Focus: same-`user.id` related alerts, especially impact, backup tampering, execution, credential, or lateral-movement activity. !{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 local scope, lineage, process activity, or file impact remains suspicious or unresolved, review the same `host.id` for other shadow-copy, backup-catalog, service-stop, encryption, or ransom-note alerts. !{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 containment when same-user or same-host alerts show additional recovery inhibition, encryption, credential access, or lateral movement; keep scope local when both pivots match the same exact retention, storage-maintenance, image-prep, or lab-reset pattern.
+
+- Escalate when command intent plus launch context or surrounding process/file evidence supports unauthorized recovery inhibition; close only when command scope, identity, lineage, account, host, and follow-on telemetry bind to one exact recognized workflow, with outside confirmation if telemetry cannot prove legitimacy. Preserve evidence and escalate on conflict or incomplete visibility.
+
+
+*False positive analysis*
+
+
+- Backup retention, storage maintenance, disaster-recovery testing, image preparation, and lab resets can delete one shadow copy or resize shadow storage. Confirm command scope (`process.command_line`), lineage (`process.parent.executable` and `process.parent.command_line`), actor/asset (`user.id`, `host.id`, `host.name`), and follow-on evidence with no same-window recovery tampering, encryption, ransom-note, or destructive cleanup outside that workflow. External records can corroborate after telemetry matches; otherwise require recurring command scope, parent, account, and host pattern across prior alerts without contradictory process or file evidence.
+- Before creating an exception, validate recurring `process.executable`, `process.pe.original_file_name`, `process.parent.executable`, stable `process.command_line` scope, `user.id` or `user.name`, and `host.id` for the confirmed workflow. Keep it constrained to that workflow and avoid exceptions on `process.name`, "vssadmin.exe", "resize", "delete", or "shadows" alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary controls and record the command scope, parent lineage, account, host, and external evidence that tied the event to recognized maintenance or reset activity. Create an exception only if the same command scope, lineage, account, and host recur consistently across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve the alert document, raw process event, parent tree, full command line, account and host identifiers, same-window process activity, and any file-impact artifacts before containment. Apply reversible containment first: isolate the host if destructive activity appears and host criticality allows it; otherwise restrict the implicated admin channel or account while scope is confirmed. Broaden containment only if same-user or same-host pivots show spread.
+- If confirmed malicious, keep the preserved evidence and isolate the endpoint to stop further impact while retaining telemetry. Suspend related accounts or admin channels when session, lineage, or related-alert evidence shows misuse. Record `process.entity_id` and `process.command_line` before termination. Remove only malicious scripts, payloads, scheduled tasks, services, ransom notes, and backup-tampering changes identified during the investigation.
+- Restore affected VSS, backup, and recovery settings, validate that snapshots or backup jobs work again, and recover impacted data from trusted backups after containment and eradication are complete.
+- Post-incident hardening: restrict VSS-management workflows on sensitive hosts, limit backup-administration rights, protect offline or out-of-band backups from the same accounts, and validate controls for adjacent recovery-inhibition variants such as "wmic shadowcopy delete", "diskshadow", "wbadmin delete catalog", "bcdedit", and "reagentc".
+
+
+==== 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 : "vssadmin.exe" or ?process.pe.original_file_name == "VSSADMIN.EXE") and
+  process.args : ("delete", "resize") and process.args : "shadows*"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Inhibit System Recovery
+** ID: T1490
+** Reference URL: https://attack.mitre.org/techniques/T1490/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-volume-shadow-copy-deletion-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-volume-shadow-copy-deletion-via-powershell.asciidoc
new file mode 100644
index 0000000000..d5c76d1d41
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-volume-shadow-copy-deletion-via-powershell.asciidoc
@@ -0,0 +1,186 @@
+[[prebuilt-rule-8-19-24-volume-shadow-copy-deletion-via-powershell]]
+=== Volume Shadow Copy Deletion via PowerShell
+
+Identifies the use of the Win32_ShadowCopy class and related cmdlets to achieve shadow copy deletion. This commonly occurs in tandem with ransomware or other destructive attacks.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/previous-versions/windows/desktop/vsswmi/win32-shadowcopy
+* https://powershell.one/wmi/root/cimv2/win32_shadowcopy
+* https://www.fortinet.com/blog/threat-research/stomping-shadow-copies-a-second-look-into-deletion-methods
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Impact
+* 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*: 319
+
+*Rule authors*: 
+
+* Elastic
+* Austin Songer
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Volume Shadow Copy Deletion via PowerShell*
+
+
+
+*Possible investigation steps*
+
+
+- Does the alert-local PowerShell command show broad shadow-copy deletion, remote targeting, or obscured execution?
+  - Focus: `process.command_line`, checking whether "Win32_ShadowCopy" is paired with WMI or CIM enumeration and deletion.
+  - Hint: treat `Get-WmiObject`, `gwmi`, `Get-CimInstance`, `gcim`, `Remove-WmiObject`, `rwmi`, `Remove-CimInstance`, `rcim`, "$_.Delete()", `-ComputerName`, and `-CimSession` as high-signal command cues. This rule requires plaintext cmdlet tokens in `process.args`; fully encoded commands or script-file invocations that hide the deletion logic will not fire this rule.
+  - Implication: escalate when the command deletes all returned shadow-copy instances, targets remote systems, or hides WMI or CIM deletion behind aliases; lower suspicion only when narrowly scoped to one recognized backup-retention, image-reset, or lab-test workflow on the expected host.
+
+- Is the PowerShell host binary expected rather than renamed or tampered?
+  - Focus: `process.executable`, `process.name`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when path, signer, trust state, or original file name does not match the expected PowerShell host; lower suspicion when identity matches a trusted system PowerShell installation, but continue because legitimate PowerShell can still delete recovery points.
+
+- Does the parent process and user context explain why this host removed shadow copies?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, `user.name`, and `user.domain`.
+  - Implication: escalate when Office, a browser, a script host, an unexpected remote-management chain, or a standard user launches deletion; lower suspicion when parent, account, and host match a recognized backup, imaging, disaster-recovery, or lab-reset workflow.
+
+- Do surrounding process events show recovery inhibition or ransomware preparation from the same host or lineage?
+  - Why: ransomware commonly pairs shadow-copy deletion with other recovery removal or encryption preparation before impact.
+  - Focus: process starts on `host.id` and, when present, the same `process.entity_id` or lineage, using `process.name`, `process.command_line`, and `process.parent.executable`. !{investigate{"description":"","label":"Process starts on the same host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Range: start with the alert window and following 15 minutes; expand only when the same lineage shows recovery tampering or encryption behavior.
+  - Implication: escalate when the same window shows `vssadmin`, `wmic`, `diskshadow`, `wbadmin`, backup service stops, recovery-setting changes, or likely encryptor launchers; lower suspicion when activity stays bounded to the same parent-launched cleanup or reset sequence and no other recovery-inhibition utilities appear.
+
+- If command or lineage remains suspicious and endpoint file telemetry is available, does file activity show encryption or destructive cleanup?
+  - Focus: recover file events with `host.id` + `process.entity_id`; if absent, use `host.id` + `process.pid` plus a tight alert window as a weaker fallback, then review `file.path`, `file.extension`, and `file.Ext.original.extension`. !{investigate{"description":"","label":"File events from the PowerShell process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when recovered file events show mass renames, unfamiliar extensions, replaced user files, or ransom-note paths after deletion; lower suspicion only when changes stay inside the recovered backup or reset target. Missing endpoint file telemetry leaves file impact unanswered; do not treat absence of file evidence as benign.
+
+- If local evidence remains suspicious or unresolved, does related alerting show the same VSS deletion or backup-tampering pattern?
+  - Focus: related impact or execution alerts for the same `user.id` involving VSS deletion, backup tampering, credential access, or the same parent tool. !{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: check the same `host.id` for shadow-copy deletion by other binaries, encryption, ransom-note creation, backup tampering, or service tampering. !{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 same user touches multiple hosts or the same host shows a broader ransomware chain; keep the case local only when related alerts are absent and local telemetry already fits one recognized workflow.
+
+- Escalate broad or remote shadow-copy deletion that lacks a recognized workflow, has suspicious lineage, destructive process or file evidence, or related spread; close only when narrow command scope, identity, lineage, and supported surrounding telemetry fit one workflow; preserve and escalate mixed or visibility-limited evidence.
+
+
+*False positive analysis*
+
+
+- PowerShell WMI or CIM shadow-copy deletion is suspicious by default outside controlled backup-retention cleanup, disaster-recovery testing, gold-image preparation, lab reset, or ransomware simulation. Close as benign only when `process.command_line` is narrowly scoped, `process.parent.executable` matches the backup, orchestration, reset, or test tool, `user.id` or `user.name` matches the expected admin or service account, `host.id` plus `host.name` fit the target, and surrounding telemetry shows no destructive process or file impact. Use change records or lab schedules only as corroboration; generic storage maintenance is not enough.
+- Before creating an exception, validate historical stability for the same `process.executable`, `process.parent.executable`, stable `process.command_line` scope, `user.id` or `user.name`, and `host.id`. Build the exception from that minimum confirmed workflow pattern. Avoid exceptions on "powershell.exe", `process.name`, or "Win32_ShadowCopy" alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse any temporary containment and record the `process.command_line`, `process.parent.executable`, `user.id` or `user.name`, `host.id`, and maintenance evidence that proved the workflow. Create an exception only if the same command scope, lineage, account, and host recur consistently across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve the alert, `process.entity_id`, full `process.command_line`, `process.args`, parent chain, `user.id`, `user.name`, `host.id`, surrounding process commands, and any recovered file-impact examples before containment. Apply reversible containment first: isolate the host only when destructive process or file evidence suggests ongoing impact and the host can tolerate isolation; otherwise restrict the implicated admin channel or account while scope is confirmed. Expand containment to related hosts or accounts only if the same-user or same-host pivots show spread.
+- If confirmed malicious, preserve the same process, command, lineage, and recovered file-impact artifacts before destructive action. Prefer endpoint isolation to stop further impact while keeping telemetry available; if direct response is unavailable, escalate with the preserved `host.id`, `user.id`, `user.name`, `process.entity_id`, `process.command_line`, and suspected ransom-note or renamed-extension indicators to the team that can isolate the host and suspend related accounts or services. If the malicious process chain is still active, record `process.entity_id` and `process.command_line` before suspending or terminating it.
+- After scope review, remove only the malicious scripts, scheduled tasks, services, payloads, or dropped notes identified during the investigation, then restore affected backup or recovery settings and validate that snapshots or backup jobs are functioning before closure.
+- Post-incident hardening: restrict VSS-management workflows and remote CIM deletion patterns to controlled administrative channels, retain the process and file telemetry that proved the case, and review whether adjacent VSS methods such as "vssadmin", "wmic", `diskshadow`, `wbadmin`, COM-based deletion, or diff-area resizing need the same controls.
+
+
+==== 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", "pwsh.exe", "powershell_ise.exe") and
+  process.args : ("*Get-WmiObject*", "*gwmi*", "*Get-CimInstance*", "*gcim*") and
+  process.args : ("*Win32_ShadowCopy*") and
+  process.args : ("*.Delete()*", "*Remove-WmiObject*", "*rwmi*", "*Remove-CimInstance*", "*rcim*")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Inhibit System Recovery
+** ID: T1490
+** Reference URL: https://attack.mitre.org/techniques/T1490/
+* 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/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-volume-shadow-copy-deletion-via-wmic.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-volume-shadow-copy-deletion-via-wmic.asciidoc
new file mode 100644
index 0000000000..321b583f67
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-volume-shadow-copy-deletion-via-wmic.asciidoc
@@ -0,0 +1,167 @@
+[[prebuilt-rule-8-19-24-volume-shadow-copy-deletion-via-wmic]]
+=== Volume Shadow Copy Deletion via WMIC
+
+Identifies use of wmic.exe for shadow copy deletion on endpoints. This commonly occurs in tandem with ransomware or other destructive attacks.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Impact
+* 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*: 318
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Volume Shadow Copy Deletion via WMIC*
+
+
+
+*Possible investigation steps*
+
+
+- What recovery data did WMIC try to delete?
+  - Focus: `process.command_line` scope: "shadowcopy delete", "ID=", "VolumeName=", "where", "/node:", or broad no-filter deletion.
+  - Implication: escalate when the command removes all shadows, targets a remote node, or lacks a narrow snapshot or volume filter; lower suspicion only when it targets one expected snapshot or volume and parent, account, host, and later process evidence fit that task.
+
+- Is this the expected Microsoft WMIC binary for the host?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when WMIC is renamed, runs outside a Windows system path, has a non-Microsoft or untrusted signature, or mismatches its original file name; Microsoft-signed system-path WMIC lowers identity risk but does not clear shadow-copy deletion.
+
+- Which launcher and account initiated the deletion?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, `user.name`, and `user.domain`.
+  - Implication: escalate when a document, browser, archive tool, script host, interactive user, or unexplained remote-management parent launches WMIC; lower suspicion only when parent command, account, and host identify the exact recovery, imaging, lab-reset, or authorized test runner.
+
+- Did the same host or lineage run other recovery-inhibition or encryption-prep commands?
+  - Why: ransomware often mixes WMIC with "vssadmin.exe", "wbadmin.exe", "bcdedit.exe", "REAgentC.exe", "diskshadow.exe", service-stop commands, or encryption tooling.
+  - Focus: same-`host.id` process starts, scoped to `process.parent.entity_id` when present, for recovery-inhibition utilities, service stops, backup-agent tampering, or encryption tools. !{investigate{"description":"","label":"Process events from the same parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: without `process.entity_id`, pivot by `host.id` + `process.pid` near the alert and treat lineage as weaker.
+  - Implication: escalate when WMIC is adjacent to additional recovery inhibition, backup tampering, service stops, or encryption preparation; keep scope narrower when process activity stays limited to one coherent maintenance or test sequence.
+
+- If local evidence is suspicious or unresolved, is the activity broader than one host workflow?
+  - Focus: same-`user.id` alerts for impact, execution, credential, or recovery-inhibition activity. !{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: review same-`host.id` alerts for alternate shadow-copy deletion utilities, backup tampering, or repeated destructive command lines. !{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: escalate scope when the user or host shows related impact or execution alerts beyond this command; keep host-local only when both pivots stay confined to the same narrow command sequence.
+
+- Escalate for unauthorized shadow-copy deletion, remote targeting, destructive preparation, or broader spread; close only when command scope, binary identity, parent/account context, same-host corroboration, and related alerts bind to one recognized workflow; preserve evidence and escalate when mixed or incomplete.
+
+
+*False positive analysis*
+
+
+- Treat WMIC shadow-copy deletion as a recovery-inhibition anti-pattern. Benign closure is narrow: telemetry must show one expected snapshot or volume, a parent command for that exact task, the expected account and host, and no contradictory same-host recovery-inhibition or encryption-prep activity. Use change records or test plans only as corroboration.
+- Do not close as benign when the command removes all shadows, uses "/node:" remote targeting, has unexplained lineage, or appears with service-stop, backup-tampering, or encryption-prep activity. Recurrence, WMIC identity, or a stated maintenance window is not enough when process evidence remains broad or contradictory.
+- Before creating an exception, require a confirmed benign case with the exact `process.command_line` scope, `process.parent.executable`, `process.parent.command_line`, `user.id`, and `host.id`. Build the exception from that minimum pattern, never on "wmic.exe", `process.name`, or "shadowcopy" alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and document the command scope, parent workflow, account, host, and corroborating maintenance or test evidence. Create an exception only when the same workflow recurs consistently for the same account and host scope.
+- If suspicious but unconfirmed, export the alert, process tree, full command line, parent command line, account, host identifiers, and related-alert results before containment. Apply reversible containment first, such as heightened monitoring or temporary administrative-access restrictions for the affected host or account; isolate the endpoint only if process evidence suggests active encryption, backup tampering, or broader destructive activity.
+- If confirmed malicious, preserve the process tree and command evidence before stopping processes or deleting artifacts. Isolate the endpoint to prevent further impact, suspend or reset involved accounts when the same `user.id` shows unauthorized activity, and remove only the scripts, scheduled tasks, services, or tools identified through the process investigation.
+- Restore recovery capability after containment: re-enable or repair affected VSS, backup, and recovery settings, validate that snapshots or backup jobs are functioning, and confirm no related recovery-inhibition commands remain active on the same host or scoped host set.
+- Post-incident hardening: restrict WMIC and VSS-management access on sensitive hosts, use application control where WMIC is not required, retain the process evidence that proved the case, and record any observed variants such as "vssadmin.exe", PowerShell Win32_ShadowCopy deletion, "wbadmin.exe", "bcdedit.exe", or "diskshadow.exe" in the case notes.
+
+
+==== 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 : "WMIC.exe" or ?process.pe.original_file_name == "wmic.exe") and
+  process.args : "delete" and process.args : "shadowcopy"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Inhibit System Recovery
+** ID: T1490
+** Reference URL: https://attack.mitre.org/techniques/T1490/
+* 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-web-shell-detection-script-process-child-of-common-web-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-web-shell-detection-script-process-child-of-common-web-processes.asciidoc
new file mode 100644
index 0000000000..af9076dac0
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-web-shell-detection-script-process-child-of-common-web-processes.asciidoc
@@ -0,0 +1,238 @@
+[[prebuilt-rule-8-19-24-web-shell-detection-script-process-child-of-common-web-processes]]
+=== Web Shell Detection: Script Process Child of Common Web Processes
+
+Identifies suspicious commands executed via a web server, which may suggest a vulnerability and remote shell access.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* endgame-*
+* logs-crowdstrike.fdr*
+* logs-endpoint.events.process-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-system.security*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.microsoft.com/security/blog/2020/02/04/ghost-in-the-shell-investigating-web-shell-attacks/
+* https://www.elastic.co/security-labs/elastic-response-to-the-the-spring4shell-vulnerability-cve-2022-22965
+* https://www.elastic.co/security-labs/hunting-for-persistence-using-elastic-security-part-1
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Resources: Investigation Guide
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: SentinelOne
+* Data Source: Windows Security Event Logs
+* Data Source: Microsoft Defender XDR
+* Data Source: Sysmon
+* Data Source: Crowdstrike
+
+*Version*: 424
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Possible investigation steps*
+
+
+- What execution path did the alert capture?
+  - Focus: child `process.executable` / `process.command_line`; web-parent `process.parent.name`, `process.parent.executable`, and `process.parent.command_line` for IIS/Apache/nginx/PHP CGI/Tomcat/ArcGIS.
+  - Implication: escalate when a web-facing parent launches a shell, script host, downloader, archive tool, or admin utility outside bounded tasks; lower only when parent context, child path, and command match one exact deployment, health-check, log rotation, or support task.
+- Is the child command administration or post-exploitation?
+  - Focus: `process.command_line`: WMIC, download cradles, archive creation, account/system discovery, service control, credential access, script-host flags, or web-root/temp/backup/app-content paths.
+  - Hint: for PowerShell, reconstruct script blocks by `host.id` and `process.pid` via `powershell.file.script_block_text`, `powershell.sequence`, and `powershell.total`; missing PowerShell telemetry is unresolved, not benign.
+  - Implication: escalate when the command stages payloads, runs discovery, creates accounts, changes services, or writes to web-accessible or temp paths; lower suspicion when bounded to one recognized deployment, health-check, log rotation, or support task.
+- Is user context human admin or service identity?
+  - Why: web-process children often inherit app-pool or service identity; `user.id`, `user.name`, and `user.domain` do not prove human initiation.
+  - Focus: `@timestamp`, `user.id`, `user.name`, `process.Ext.session_info.logon_type`, and `process.parent.command_line`.
+  - Implication: escalate when service or network logon context launches interactive troubleshooting, remote administration, or off-hours shell activity without a matching window; lower suspicion when identity, logon type, parent pool/service, and command scope fit one exact workflow.
+- Does child binary identity fit its command?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the child is renamed, unsigned/untrusted, user-writable, or mismatched to original file name; lower suspicion when identity and path match stable tooling, but continue because trusted binaries can carry web-shell commands.
+- Did file telemetry show web-shell placement, staging, or config changes?
+  - Focus: if file telemetry exists, review `host.id` file events for child `process.entity_id` or `process.pid`, checking `file.path`, `file.Ext.original.path`, and `file.Ext.windows.zone_identifier`. !{investigate{"description":"","label":"File events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: web-root script writes without later child starts are adjacent-variant evidence; if the child writes a script or executable, query starts where `process.executable` equals that path on same `host.id`.
+  - Implication: escalate when the child writes ASPX, ASP, PHP, JSP, JS, BAT, PS1, EXE, DLL, JAR, WAR, or archives to web-accessible/temp/user-writable paths, or a written artifact later executes; missing file telemetry is unresolved, not benign, and absence does not close.
+- Did the child launch second-stage processes?
+  - Focus: child starts on `host.id` where `process.parent.entity_id` equals child `process.entity_id`, checking `process.executable`, `process.command_line`, and `process.hash.sha256`. !{investigate{"description":"","label":"Child process events from the suspicious child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when descendants include shells, script hosts, downloaders, archive tools, credential utilities, service control, or persistence tooling; absence only narrows impact when command, file, network, and related alerts also fit a benign workflow.
+- Did DNS/network telemetry show retrieval or control?
+  - Focus: if DNS/network telemetry exists, review child `process.entity_id` events on `host.id`, separating `dns.question.name` / `dns.resolved_ip` from `destination.ip` / `destination.port`; compare role with command intent. !{investigate{"description":"","label":"Network events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: map DNS results to later connection IPs before linking query and connection; if a third-party alert lacks `process.entity_id`, recover the child by `host.id`, `process.pid`, and `@timestamp`. Missing network/DNS telemetry is unresolved, not benign.
+  - Implication: escalate when the child retrieves tools from public infrastructure, reaches rare/misaligned destinations, or connects outside web-server administration; decide from alert-local process evidence and corroboration when DNS/network telemetry is unavailable.
+- Do related alerts show broader compromise?
+  - Focus: same-web-parent starts and 48h `host.id` alerts for web-shell, credential-access, discovery, archive, lateral-movement, persistence, or anti-forensics.
+    - !{investigate{"description":"","label":"Process events from the same web parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","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: escalate scope when alerts cluster around the same server role, child command family, or staged artifacts; absence only narrows response scope when local parent-child, command, identity, file, and network evidence are explained.
+- What disposition fits?
+  - Implication: escalate on unexplained server-side execution, exploit-like command intent, suspicious child identity, payload staging, rare destinations, or broader compromise; do not wait for optional pivots when alert-local process evidence is unsafe. Close only when same-host alert-window telemetry proves one exact benign web-server workflow; use outside confirmation for legitimacy gaps. If evidence is mixed or visibility incomplete, preserve artifacts and escalate.
+
+
+*False positive analysis*
+
+
+- Web deployment, post-install validation, health checks, vendor extension install, ArcGIS publishing, or maintenance can spawn "cmd.exe", PowerShell, or "wscript.exe" from web components. Confirm only when parent, child, command, service identity, and artifact/destination evidence describe the same alert-window workflow with no unexpected web-content writes, rare callbacks, or contradictions.
+- If telemetry proves shape but not legitimacy, require matching change, deployment, runbook, vendor, or owner confirmation; use prior occurrences post-closure to test exception stability.
+- Build exceptions from minimum confirmed pattern: web parent command, child executable/hash/signature, command line, `user.id`, `host.id`, and bounded content path or destination when decisive. Avoid parent name, `process.name`, or `host.id` alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment, document exact parent, child, command, service identity, artifact/destination evidence, and confirmation, and create exceptions only from that pattern.
+- If suspicious but unconfirmed, preserve the alert/export, process tree, child/parent entity IDs, command lines, hash, staged-file copies, destinations, related alerts, and web/app logs around `@timestamp` before containment or cleanup.
+- Apply reversible containment tied to evidence: block confirmed malicious destinations, restrict affected site/app access, disable exposed extension or virtual directory, or increase `host.id` monitoring. Isolate only when evidence and server criticality permit.
+- If confirmed malicious, contain the host or terminate the child only after preservation; if direct response is unavailable, escalate with process/artifact/destination/server-log evidence to the team that can contain the server, disable the exposed path, or stop the service.
+- Before deletion/restoration, hunt for the same hash, child command, staged path, domain, IP, and port across hosts/accounts. Then remove web shells, scripts, archives, scheduled tasks, dropped utilities, and persistence; restore known-good content/config; rotate exposed service, app, or admin credentials if secrets may be exposed.
+- After containment, patch the implicated app, extension, framework, or server component; review the internet-exposed site/service that launched the child; retain endpoint, network, and web logs; document script-only variants or logging 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
+
+
+*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]
+----------------------------------
+host.os.type:windows and event.category:process and event.type:start and process.args : * and
+  process.parent.name:("w3wp.exe" or "httpd.exe" or "nginx.exe" or "php.exe" or "php-cgi.exe" or "tomcat.exe" or "ArcSOC.exe") and
+  (
+    process.name : ("cmd.exe" or "cscript.exe" or "powershell.exe" or "pwsh.exe" or "powershell_ise.exe" or "wmic.exe" or "wscript.exe") or
+    process.name.caseless : ("cmd.exe" or "cscript.exe" or "powershell.exe" or "pwsh.exe" or "powershell_ise.exe" or "wmic.exe" or "wscript.exe")
+  ) and
+  not
+  (
+    process.command_line : (
+      "cmd.exe /c mode CON" or
+      "cmd.exe /s /c \"mode CON\"" or
+      "cmd.exe /c \"mode\"" or
+      "cmd.exe /s /c \"tput colors 2>&1\"" or
+      "cmd.exe /s /c \"stty 2> NUL\"" or
+      "cmd.exe /s /c \"stty 2>&1\"" or
+      "cmd.exe /c \"stty 2>&1\"" or
+      "cmd.exe /s /c \"ipconfig /all 2>&1\"" or
+      "cmd.exe /s /c \"echo '%os%'\"" or
+      *.\\install\\awk.exe*
+    ) or
+    process.args : (\(git or (*artisan* and *queue\:work*) or *rmdir* or "mode CON" or ver or ls or mode or dir) or
+
+    (process.name:cmd.exe and process.parent.args : "c:\\\\xampp\\\\htdocs\\\\open-audit\\\\index.php") or
+
+    (process.name:cmd.exe and process.args:("/V:ON" and "--header-html")) or
+
+    (process.parent.args:"WebCession" and process.args:E\:\\Data\\CLM\\cession\\*.bat) or
+
+    (process.parent.executable :"D:\\AiDKlinik\\php\\php-cgi.exe" and process.args:D\:\\AiDKlinik\\web*) or
+
+    (process.parent.args :"E:/wamp64/bin/apache/apache2.4.62.1" and process.args:node*) or
+
+    (process.parent.name:"php.exe" and process.name:"cmd.exe" and process.args:("/V:ON" and "/E:ON"))
+  )
+
+----------------------------------
+
+*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: Windows Management Instrumentation
+** ID: T1047
+** Reference URL: https://attack.mitre.org/techniques/T1047/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
+* Sub-technique:
+** Name: Windows Command Shell
+** ID: T1059.003
+** Reference URL: https://attack.mitre.org/techniques/T1059/003/
+* Sub-technique:
+** Name: Visual Basic
+** ID: T1059.005
+** Reference URL: https://attack.mitre.org/techniques/T1059/005/
+* 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-24/prebuilt-rule-8-19-24-windows-server-update-service-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-windows-server-update-service-spawning-suspicious-processes.asciidoc
new file mode 100644
index 0000000000..cb43b41b51
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-windows-server-update-service-spawning-suspicious-processes.asciidoc
@@ -0,0 +1,192 @@
+[[prebuilt-rule-8-19-24-windows-server-update-service-spawning-suspicious-processes]]
+=== Windows Server Update Service Spawning Suspicious Processes
+
+Identifies suspicious processes being spawned by the Windows Server Update Service. This activity may indicate exploitation activity or access to an existing web shell backdoor.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process-*
+* winlogbeat-*
+* logs-windows.sysmon_operational-*
+* endgame-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-59287
+* https://hawktrace.com/blog/CVE-2025-59287
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Initial Access
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: Microsoft Defender XDR
+* Data Source: SentinelOne
+* Resources: Investigation Guide
+
+*Version*: 4
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Windows Server Update Service Spawning Suspicious Processes*
+
+
+
+*Possible investigation steps*
+
+
+- What does the alert-local WSUS parent-child path show?
+  - Focus: child `process.executable` and `process.command_line`, plus `process.parent.name`, `process.parent.executable`, and `process.parent.args`, especially "w3wp.exe" with "WsusPool" or "WsusService.exe".
+  - Implication: escalate when a WSUS web or service component launches a shell, PowerShell, "rundll32.exe", or "curl.exe" for interpreter, download, or proxy-execution behavior; lower suspicion only when the parent-child pair and arguments match a narrow recognized WSUS setup, cleanup, or repair pattern.
+- Does the child command and binary identity fit bounded WSUS maintenance?
+  - Why: WSUS children can inherit service context; visible user fields may not prove human initiation.
+  - Focus: `process.command_line`, `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`/`trusted`, and child processes. !{investigate{"description":"","label":"Child processes of the suspicious WSUS child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: for PowerShell with script-block telemetry, anchor on `host.id` + `process.entity_id` or `host.id` + `process.pid` in a tight alert window. Reconstruct `powershell.file.script_block_id`, `powershell.total`, `powershell.sequence`, and `powershell.file.script_block_text`; missing script-block telemetry is unresolved, not benign.
+  - Implication: escalate on encoded script content, external retrieval, discovery, archive, remote-admin, temp-path DLL activity, or a renamed/unsigned/mismatched child; lower suspicion only when command scope, path, PE identity, and signer all match the same narrow WSUS task. Identity alone does not clear the launch chain.
+- Did the child stage payloads or WSUS-content artifacts?
+  - Focus: process-scoped file `file.path`, `file.Ext.original.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier`; missing file telemetry is unresolved, not benign. !{investigate{"description":"","label":"File events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: scope by `host.id` + `process.entity_id`, or `host.id` + `process.pid` if absent; check later starts where `process.executable` equals the written path.
+  - Implication: escalate when the child writes scripts, DLLs, EXEs, archives, or renamed content under WSUS, IIS, temp, or user-writable paths, especially if later executed; lower suspicion only when writes stay inside the same narrow WSUS maintenance path.
+- Did the child retrieve tooling, call back, or reach destinations outside the WSUS role?
+  - Focus: process-scoped DNS `event.action`, `dns.question.name`, `dns.resolved_ip`, and connection `destination.ip`/`destination.port`; missing network telemetry is unresolved, not benign. !{investigate{"description":"","label":"Network events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: scope by `host.id` + `process.entity_id`, or `host.id` + `process.pid` if absent. Compare DNS "lookup_result" `dns.resolved_ip` with later `destination.ip` from the same process.
+  - Implication: escalate when the child retrieves tools from public infrastructure, connects to rare or unrelated systems, or uses destinations inconsistent with WSUS update distribution; lower suspicion when the same process reaches only recognized internal mirrors, proxies, or vendor services that fit command and parent context.
+- If local findings are suspicious or unresolved, does same-host scope show broader WSUS compromise?
+  - Focus: related alerts on the same `host.id`, especially repeated WSUS-spawned tools and complementary webshell, credential-access, discovery, archive, or lateral-movement activity. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Range: start with the alert window; expand to 48 hours only if parent-child, command, artifact, or destination evidence remains suspicious or incomplete.
+  - Implication: broaden containment when related alerts corroborate WSUS compromise or post-exploitation; keep scope local when surrounding activity is limited to one fully explained maintenance action.
+- Escalate for unexplained service-side execution, payload staging, suspicious destinations, or broader WSUS compromise; close only when parent-child path, command intent, service context, binary identity, artifacts, destinations, and same-host scope prove one exact recognized WSUS maintenance or validation workflow; preserve artifacts and escalate when evidence is mixed or optional telemetry is missing.
+
+
+*False positive analysis*
+
+
+- WSUS installation, post-install repair, cleanup, health-check, migration, or authorized CVE validation can launch bounded shell or PowerShell children from "WsusPool" or "WsusService.exe". Close only when parent `process.parent.name`/`process.parent.args`, child command, path, hash or signer, `user.id`, and `host.id` prove the same narrow task; artifact and destination telemetry should corroborate when available, and missing recovery that leaves staging or callback unresolved requires confirmation or escalation.
+- Before creating an exception, validate stability across prior alerts for the same WSUS server: parent context, child path/hash/signer, exact `process.command_line`, `user.id`, `host.id`, and any bounded artifact or destination pattern. Avoid exceptions on "WsusService.exe", "w3wp.exe", `process.name`, or `host.id` alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, reverse temporary containment and document the parent context, child `process.executable`, `process.command_line`, signer or hash, `user.id`, `host.id`, and bounded artifact or destination evidence that proved the WSUS workflow. Create an exception only from that full stable pattern.
+- If suspicious but unconfirmed, preserve the case export, process tree, child `process.entity_id`, `process.pid`, `process.command_line`, parent context, `user.id`, `host.id`, recovered staged paths, recovered DNS or destination indicators, and related-alert identifiers before containment. Apply reversible containment first: block confirmed malicious destinations, restrict inbound WSUS exposure on ports 8530/8531, limit external access to the affected service, or increase monitoring. Isolate the host only when artifact, destination, or related-alert evidence shows active compromise and the server role can tolerate disruption.
+- If confirmed malicious, isolate the WSUS host or terminate the malicious child only after preserving process identifiers, command lines, parent context, hashes, staged paths, destination indicators, and related-alert evidence. Then disable the exposed WSUS service path or block inbound 8530/8531 until patched, scope other servers and accounts for confirmed indicators, remove only artifacts identified during triage, restore WSUS/IIS content, rotate exposed credentials if configuration material was accessed, apply the relevant Microsoft WSUS update, and retain case logs.
+
+
+==== 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.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe", "rundll32.exe", "curl.exe") and
+  (
+   (process.parent.name : "w3wp.exe" and process.parent.args : "WsusPool") or
+   process.parent.name : "WsusService.exe"
+   )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Exploit Public-Facing Application
+** ID: T1190
+** Reference URL: https://attack.mitre.org/techniques/T1190/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
+* Sub-technique:
+** Name: Windows Command Shell
+** ID: T1059.003
+** Reference URL: https://attack.mitre.org/techniques/T1059/003/
+* 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/
+* 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-windows-service-installed-via-an-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-windows-service-installed-via-an-unusual-client.asciidoc
new file mode 100644
index 0000000000..51dad6fe6a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-windows-service-installed-via-an-unusual-client.asciidoc
@@ -0,0 +1,168 @@
+[[prebuilt-rule-8-19-24-windows-service-installed-via-an-unusual-client]]
+=== Windows Service Installed via an Unusual Client
+
+Identifies the creation of a Windows service by an unusual client process. Services may be created with administrator privileges but are executed under SYSTEM privileges, so an adversary may also use a service to escalate privileges from administrator to SYSTEM.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.x86matthew.com/view_post?id=create_svc_rpc
+* https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4697
+* https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0100_windows_audit_security_system_extension.md
+* 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: Privilege Escalation
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 218
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Windows Service Installed via an Unusual Client*
+
+
+*Possible investigation steps*
+
+
+- Which unusual service-control path did the alert preserve?
+  - Why: Custom Service Control Manager RPC clients can create services without normal attribution; PID 0 is the path this alert needs interpreted.
+  - Focus: `winlog.event_data.ClientProcessId`, `winlog.event_data.ParentProcessId`, `user.domain`, `winlog.computer_name`, and `winlog.event_data.ServiceAccount`.
+  - Implication: escalate when PID 0 attribution combines with a local-account domain and LocalSystem; lower suspicion only when exact host, account, service, and time match a recognized deployment or test explaining zeroed attribution.
+
+- What would the new service execute and how privileged is it?
+  - Why: Event 4697 captures the create-time image path only; later service changes can contradict a clean create-time string.
+  - Focus: `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceType`, `winlog.event_data.ServiceStartType`, and `winlog.event_data.ServiceAccount`.
+  - Implication: escalate when the image path is user-writable, temporary, ProgramData, or system-masqueraded; type is driver; start type is boot, system, or disabled; or LocalSystem lacks a matching product. Lower suspicion when all service fields align with one recognized installer, endpoint agent, backup, or deployment tool.
+
+- Which account and logon session requested the service creation?
+  - Focus: service-install `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, and `winlog.event_data.SubjectLogonId`; 4624 `source.ip` and `winlog.logon.type`; 4648 explicit-credential context.
+  - Implication: escalate when the subject is an unexpected local admin or machine account, origin is remote or rare for the host, explicit credentials appear, or source is absent where remote administration is expected; lower suspicion when subject, logon type, source, and service target fit one recognized management session. Missing 4624/4648 or source fields leaves origin unresolved, not benign.
+  - Hint: on `host.id`, search 4624 where `winlog.event_data.TargetLogonId` equals service-install `winlog.event_data.SubjectLogonId`; search 4648 where `winlog.event_data.SubjectLogonId` matches.
+    - !{investigate{"description":"","label":"Linked logon for the service-install session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Explicit-credential events for the service-install session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+
+- Do surrounding Windows Security records show a contained install or follow-on control activity?
+  - Focus: same-host `event.code`, `winlog.record_id`, `winlog.event_data.ServiceName`, and `winlog.event_data.SubjectLogonId` around `@timestamp`.
+  - Implication: escalate when the same logon session creates multiple services, pairs install with explicit credentials, or shows account changes or failures around service creation; lower suspicion when records stay limited to one expected installer session for the same service. Missing Security telemetry is unresolved, not benign.
+  - Hint: inspect same-session 4697 records for clustered service creation. !{investigate{"description":"","label":"Same-session service-install events","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":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+
+- Is the same service-install pattern recurring in a bounded cohort or spreading?
+  - Focus: historical Event ID 4697 records by `winlog.event_data.SubjectUserSid`, `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceAccount`, and `winlog.computer_name`.
+  - Implication: escalate when the same subject creates PID 0 LocalSystem services across unrelated hosts, or service names or paths rotate; lower suspicion when exact service fields recur in the same managed host cohort with a stable subject and no contradictory service metadata.
+  - Hint: query 4697 for the same subject or service fields, group by `winlog.computer_name`, `winlog.event_data.ServiceName`, and `winlog.event_data.ServiceFileName`, then compare PID 0 recurrence. !{investigate{"description":"","label":"Historical 4697 service-install recurrence","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","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":"4697","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ServiceFileName","queryType":"phrase","value":"{{winlog.event_data.ServiceFileName}}","valueType":"string"}]],"relativeFrom":"now-7d/d","relativeTo":"now"}}
+
+- Based on the Windows Security evidence, what disposition is supported?
+  - Implication: escalate when PID 0, LocalSystem image, actor/session evidence, or 4697 recurrence does not bind to one recognized workflow; close only when the same fields prove one exact service deployment or test on this host and no contradictory Security evidence remains; if mixed, preserve service-install and logon records, then escalate.
+
+
+*False positive analysis*
+
+
+- Software deployment, endpoint agent, backup, configuration tools, or authorized service-control/RPC testing can trigger when Service Control Manager behavior leaves PID 0 attribution. Examples include Veeam, PDQ, CrowdStrike installer, SCCM/SMS, nsnetpush, or pbpsdeploy-style patterns. Confirm service name, file, account, subject SID, host cohort, logon session, and test timing align with one product or test workflow, with no contradictory Security records.
+- Before creating an exception, require stable recurrence for the same `winlog.event_data.SubjectUserSid`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceName`, `winlog.event_data.ServiceAccount`, and host cohort. Avoid broad exceptions on `user.name`, `host.name`, or service name alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign:
+  - Reverse any temporary containment and record the exact evidence that confirmed the workflow: service fields, subject and logon IDs, affected host, and recurrence or change context.
+  - Build any exception only from the stable workflow anchors validated above, not from a broad user, host, or service-name match.
+- If suspicious but unconfirmed:
+  - Preserve the alert, original Event ID 4697 record, related 4624/4648 records, `winlog.record_id` values, service configuration, and the service binary named by `winlog.event_data.ServiceFileName` before containment.
+  - Apply reversible containment tied to the findings, such as isolating the host if lateral movement risk is present, restricting the subject account, or disabling the new service after preserving its configuration. Avoid deleting the service or binary until maliciousness and scope are clear.
+- If confirmed malicious:
+  - Preserve the original Event ID 4697 record, related 4624/4648 records, service configuration, service binary, and recurrence evidence before containment or eradication.
+  - Contain the host and affected account based on the service definition, actor/session evidence, and recurrence pattern; weigh host criticality before isolation.
+  - Disable or stop the malicious service after preserving configuration and binary evidence, then remove the service and service binary only after scope is established.
+  - Reset or rotate credentials for the subject account when logon evidence shows misuse, and review other hosts where the same subject or service pattern created LocalSystem services.
+- Post-incident hardening:
+  - Restrict service creation to controlled deployment accounts and administrative hosts.
+  - Retain Audit Security System Extension success logging and enough Windows Security history to correlate 4624, 4648, and 4697 records.
+  - Record the confirmed benign workflow or malicious service pattern so future alerts can compare exact service, subject, and host evidence.
+
+==== 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]
+----------------------------------
+configuration where host.os.type == "windows" and
+  event.action == "service-installed" and
+  (winlog.event_data.ClientProcessId == "0" or winlog.event_data.ParentProcessId == "0") and
+  startswith~(user.domain, winlog.computer_name) and winlog.event_data.ServiceAccount == "LocalSystem" and 
+  not winlog.event_data.ServiceFileName : (
+    "?:\\Windows\\VeeamVssSupport\\VeeamGuestHelper.exe*",
+    "?:\\Windows\\VeeamLogShipper\\VeeamLogShipper.exe",
+    "%SystemRoot%\\system32\\Drivers\\Crowdstrike\\*-CsInstallerService.exe",
+    "\"%windir%\\AdminArsenal\\PDQInventory-Scanner\\service-1\\PDQInventory-Scanner-1.exe\" ",
+    "\"%windir%\\AdminArsenal\\PDQDeployRunner\\service-1\\PDQDeployRunner-1.exe\" ",
+    "\"%windir%\\AdminArsenal\\PDQInventoryWakeCommand\\service-1\\PDQInventoryWakeCommand-1.exe\" ",
+    "\"%SystemRoot%\\nsnetpush.exe\"",
+    "\"C:\\WINDOWS\\ccmsetup\\ccmsetup.exe\" /runservice /ignoreskipupgrade /config:MobileClient.tcf",
+    "\"?:\\SMS\\bin\\x64\\srvboot.exe\"",
+    "%SystemRoot%\\pbpsdeploy.exe"
+  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Create or Modify System Process
+** ID: T1543
+** Reference URL: https://attack.mitre.org/techniques/T1543/
+* Sub-technique:
+** Name: Windows Service
+** ID: T1543.003
+** Reference URL: https://attack.mitre.org/techniques/T1543/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-wps-office-exploitation-via-dll-hijack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-wps-office-exploitation-via-dll-hijack.asciidoc
new file mode 100644
index 0000000000..4228298e06
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rule-8-19-24-wps-office-exploitation-via-dll-hijack.asciidoc
@@ -0,0 +1,182 @@
+[[prebuilt-rule-8-19-24-wps-office-exploitation-via-dll-hijack]]
+=== WPS Office Exploitation via DLL Hijack
+
+Identifies the load of a remote library by the WPS Office promecefpluginhost.exe executable. This may indicate the successful exploitation of CVE-2024-7262 or CVE-2024-7263 via DLL hijack abusing the ksoqing custom protocol handler.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.library-*
+* logs-windows.sysmon_operational-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.welivesecurity.com/en/eset-research/analysis-of-two-arbitrary-code-execution-vulnerabilities-affecting-wps-office/
+* https://mp.weixin.qq.com/s/F8hNyESBdKhwXkQPgtGpew
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Initial Access
+* Tactic: Execution
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Resources: Investigation Guide
+
+*Version*: 106
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating WPS Office Exploitation via DLL Hijack*
+
+
+
+*Possible investigation steps*
+
+
+- What WPS library-load path did the alert capture?
+  - Why: WPS loading from cache, device, or UNC paths defines the likely abuse route before identity checks.
+  - Focus: `process.name`, `process.executable`, `process.command_line`, `dll.path`, and `dll.name`.
+  - Implication: escalate when "promecefpluginhost.exe" loads from "Temp\wps\INetCache", "\Device\Mup\", or a UNC path outside the WPS install tree; lower suspicion only when normalized `dll.path` resolves to the same Kingsoft-controlled component path as the loader and no protocol-abuse arguments appear.
+
+- Is the WPS loader the expected Kingsoft component?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the loader is unsigned, renamed, outside the installed WPS Office directory, or signed by an unexpected publisher; lower suspicion when identity matches a stable Kingsoft WPS component, but continue because a trusted loader can still load an attacker DLL.
+
+- Does the command line and parentage show "ksoqing" protocol abuse?
+  - Focus: loader process events for `host.id` and `process.entity_id`, then `process.command_line`, `process.parent.executable`, and `process.parent.command_line`. !{investigate{"description":"","label":"Process events for the WPS loader","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when "wps.exe" or "et.exe" opens user content with arguments exposing "ksoqing", plugin-service paths, encoded paths, or remote paths; lower suspicion only when parentage and arguments match a recognized controlled-share launch without document-driven protocol handling.
+
+- Does the loaded DLL identity fit a legitimate WPS dependency?
+  - Focus: `dll.hash.sha256`, `dll.pe.original_file_name`, `dll.code_signature.subject_name`, `dll.code_signature.trusted`, and `dll.Ext.relative_file_creation_time`.
+  - Hint: if endpoint file telemetry is available, use `host.id` and `dll.path` to identify the writer or rename event. Missing file telemetry is unresolved, not benign. !{investigate{"description":"","label":"File events for the loaded DLL path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{dll.path}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the DLL is unsigned, non-Kingsoft, recently created, recently renamed in `dll.Ext.relative_file_name_modify_time`, or loaded as an unexpected WPS dependency from a remote share; if recency metadata is absent, rely on path, hash, signer, and parentage.
+
+- If local evidence is suspicious or incomplete, do related alerts show follow-on activity?
+  - Focus: child process events from the WPS loader and related alerts for `user.id`, especially WPS document execution, additional library loads, downloader behavior, or child-process alerts from the same workstation.
+    - !{investigate{"description":"","label":"Child process events from the WPS loader","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{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 user context is missing or ambiguous, review same-host alerts for `host.id` across the last 48 hours. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same user or host shows repeated WPS-triggered loads, the same `dll.hash.sha256`, the same suspicious path pattern, or follow-on execution; lower urgency when isolated, but do not close if local path or DLL identity remains unresolved.
+
+- Escalate when load path, loader identity, protocol or parentage, DLL signer/hash/recency, or related-alert evidence supports attacker-controlled DLL loading from INetCache, a device path, or UNC path; close only when the same evidence binds to one authorized validation, sandbox, or controlled-share workflow with no contradictory artifacts; preserve artifacts and escalate if evidence is mixed or incomplete.
+
+
+*False positive analysis*
+
+
+- Authorized vulnerability validation or sandbox detonation can reproduce this load pattern. Confirm scope with outside records when available, and require telemetry alignment on `host.id`, `user.id`, `process.executable`, `process.command_line`, `dll.path`, `dll.hash.sha256`, and `dll.code_signature.subject_name`. If not a known test, default to suspicious.
+- Controlled software distribution or application virtualization can serve WPS components from a managed share. Confirm `dll.path` stays on that exact share, `dll.hash.sha256` and `dll.code_signature.subject_name` match the expected Kingsoft component, and parentage lacks document-driven protocol or plugin-path arguments. Without inventories, use recurrence only to validate the same stable share, hash, signer, `process.executable`, `host.id`, and `user.id` workflow before exceptioning.
+- Build exceptions only from the minimum confirmed workflow: stable `process.executable`, `process.code_signature.subject_name`, `dll.path`, `dll.hash.sha256`, `dll.code_signature.subject_name`, and bounded `host.id` or `user.id` scope. Avoid exceptions on `process.name` alone for "promecefpluginhost.exe", "Temp\wps\INetCache", or UNC prefixes.
+
+
+*Response and remediation*
+
+
+- If confirmed benign, record the exact workflow evidence first: loader identity, `process.command_line`, DLL path/hash/signer, and bounded `host.id` or `user.id` scope. Then reverse temporary containment and create an exception only for that bounded workflow.
+- If suspicious but unconfirmed, preserve the alert, host/user scope, `process.entity_id`, parent lineage, `dll.path`, `dll.hash.sha256`, and DLL signer/recency evidence before containment. Use reversible actions first, such as restricting a non-business remote share named in `dll.path`, quarantining a recovered lure document, or temporarily restricting WPS on the affected host; isolate only when follow-on execution or repeated malicious loads justify the interruption.
+- If confirmed malicious, isolate the host through endpoint response after evidence preservation, then terminate the WPS loader chain if it is still active and block confirmed malicious `dll.hash.sha256` values and remote shares from `dll.path`. If endpoint response is unavailable, hand off the preserved process, DLL, host, and user identifiers to the team that can contain the system or share.
+- Eradicate only artifacts tied to the investigation: remove the malicious DLL, recovered lure document, and staged WPS abuse files after scope review for the same `dll.hash.sha256`, `dll.path`, WPS parentage, `host.id`, and `user.id`. Upgrade WPS Office to a vendor-supported release that remediates both CVE-2024-7262 and CVE-2024-7263.
+- Post-incident hardening: restrict WPS Office library loads from user-writable and UNC paths where feasible, retain process and library-load telemetry, and document any adjacent variant observed during triage, such as alternate WPS protocol arguments or related "promecefpluginhost.exe" load paths.
+
+
+==== 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-7-setup[Sysmon Event ID 7 - Image Loaded]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+any where host.os.type == "windows" and process.name : "promecefpluginhost.exe" and
+(
+ (event.category == "library" and
+  ?dll.path :
+     ("?:\\Users\\*\\AppData\\Local\\Temp\\wps\\INetCache\\*",
+      "\\Device\\Mup\\**", "\\\\*")) or
+
+  ((event.category == "process" and event.action : "Image loaded*") and
+  ?file.path :
+     ("?:\\Users\\*\\AppData\\Local\\Temp\\wps\\INetCache\\*",
+      "\\Device\\Mup\\**", "\\\\*"))
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Shared Modules
+** ID: T1129
+** Reference URL: https://attack.mitre.org/techniques/T1129/
+* Technique:
+** Name: Exploitation for Client Execution
+** ID: T1203
+** Reference URL: https://attack.mitre.org/techniques/T1203/
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Drive-by Compromise
+** ID: T1189
+** Reference URL: https://attack.mitre.org/techniques/T1189/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Hijack Execution Flow
+** ID: T1574
+** Reference URL: https://attack.mitre.org/techniques/T1574/
+* Sub-technique:
+** Name: DLL
+** ID: T1574.001
+** Reference URL: https://attack.mitre.org/techniques/T1574/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rules-8-19-24-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rules-8-19-24-appendix.asciidoc
new file mode 100644
index 0000000000..86b48290ef
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rules-8-19-24-appendix.asciidoc
@@ -0,0 +1,141 @@
+["appendix",role="exclude",id="prebuilt-rule-8-19-24-prebuilt-rules-8-19-24-appendix"]
+= Downloadable rule update v8.19.24
+
+This section lists all updates associated with version 8.19.24 of the Fleet integration *Prebuilt Security Detection Rules*.
+
+
+include::prebuilt-rule-8-19-24-aws-eks-control-plane-logging-disabled.asciidoc[]
+include::prebuilt-rule-8-19-24-aws-eks-access-entry-modified.asciidoc[]
+include::prebuilt-rule-8-19-24-aws-eks-access-entry-granted-cluster-admin-policy.asciidoc[]
+include::prebuilt-rule-8-19-24-microsoft-graph-multi-category-reconnaissance-burst.asciidoc[]
+include::prebuilt-rule-8-19-24-entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc[]
+include::prebuilt-rule-8-19-24-entra-id-oauth-device-code-phishing-via-aitm.asciidoc[]
+include::prebuilt-rule-8-19-24-entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa.asciidoc[]
+include::prebuilt-rule-8-19-24-entra-id-register-device-with-unusual-user-agent-azure-ad-join.asciidoc[]
+include::prebuilt-rule-8-19-24-google-workspace-device-registration-after-oauth-from-suspicious-asn.asciidoc[]
+include::prebuilt-rule-8-19-24-kubernetes-pod-exec-cloud-instance-metadata-access.asciidoc[]
+include::prebuilt-rule-8-19-24-kubernetes-pod-exec-sensitive-file-or-credential-path-access.asciidoc[]
+include::prebuilt-rule-8-19-24-kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc[]
+include::prebuilt-rule-8-19-24-kubernetes-pod-exec-with-curl-or-wget-to-https.asciidoc[]
+include::prebuilt-rule-8-19-24-kubernetes-pod-exec-potential-reverse-shell.asciidoc[]
+include::prebuilt-rule-8-19-24-kubernetes-coredns-or-kube-dns-configuration-modified.asciidoc[]
+include::prebuilt-rule-8-19-24-kubernetes-admission-webhook-created-or-modified.asciidoc[]
+include::prebuilt-rule-8-19-24-kubernetes-client-certificate-signing-request-created-or-approved.asciidoc[]
+include::prebuilt-rule-8-19-24-eks-authentication-configuration-modified.asciidoc[]
+include::prebuilt-rule-8-19-24-kubernetes-api-server-proxying-request-to-kubelet.asciidoc[]
+include::prebuilt-rule-8-19-24-kubernetes-api-request-impersonating-privileged-identity.asciidoc[]
+include::prebuilt-rule-8-19-24-kubernetes-ephemeral-container-added-to-pod.asciidoc[]
+include::prebuilt-rule-8-19-24-m365-potential-aitm-userloggedin-via-office-app-tycoon2fa.asciidoc[]
+include::prebuilt-rule-8-19-24-kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-kubeletctl-execution.asciidoc[]
+include::prebuilt-rule-8-19-24-container-runtime-cli-execution-with-suspicious-arguments.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-direct-kubelet-access-via-process-arguments.asciidoc[]
+include::prebuilt-rule-8-19-24-kubelet-api-connection-attempt-to-internal-ip.asciidoc[]
+include::prebuilt-rule-8-19-24-kubernetes-static-pod-manifest-file-access.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-privilege-escalation-in-container-via-runc-init.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-privilege-escalation-via-suid-sgid.asciidoc[]
+include::prebuilt-rule-8-19-24-suspicious-suid-binary-execution-auditd-sequence.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-privilege-escalation-via-unshare-followed-by-root-process.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc[]
+include::prebuilt-rule-8-19-24-aws-ssm-session-manager-child-process-execution.asciidoc[]
+include::prebuilt-rule-8-19-24-github-private-repository-turned-public.asciidoc[]
+include::prebuilt-rule-8-19-24-kubernetes-rapid-secret-get-activity-against-multiple-objects.asciidoc[]
+include::prebuilt-rule-8-19-24-kubernetes-secret-get-or-list-from-node-or-pod-service-account.asciidoc[]
+include::prebuilt-rule-8-19-24-kubernetes-secrets-list-across-cluster-or-sensitive-namespaces.asciidoc[]
+include::prebuilt-rule-8-19-24-kubernetes-multi-resource-discovery.asciidoc[]
+include::prebuilt-rule-8-19-24-m365-identity-login-from-atypical-region.asciidoc[]
+include::prebuilt-rule-8-19-24-m365-identity-login-from-impossible-travel-location.asciidoc[]
+include::prebuilt-rule-8-19-24-curl-or-wget-execution-from-container-context.asciidoc[]
+include::prebuilt-rule-8-19-24-sensitive-files-compression.asciidoc[]
+include::prebuilt-rule-8-19-24-file-creation-in-world-writable-directory-by-unusual-process.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-reverse-shell-via-java.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-privilege-escalation-via-unshare-and-uid-change.asciidoc[]
+include::prebuilt-rule-8-19-24-suspicious-suid-binary-execution.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-macos-ssh-brute-force-detected.asciidoc[]
+include::prebuilt-rule-8-19-24-dns-request-for-ip-lookup-service-via-unsigned-binary.asciidoc[]
+include::prebuilt-rule-8-19-24-suspicious-macos-ms-office-child-process.asciidoc[]
+include::prebuilt-rule-8-19-24-finder-sync-plugin-registered-and-enabled.asciidoc[]
+include::prebuilt-rule-8-19-24-user-added-to-the-admin-group.asciidoc[]
+include::prebuilt-rule-8-19-24-cobalt-strike-command-and-control-beacon.asciidoc[]
+include::prebuilt-rule-8-19-24-possible-fin7-dga-command-and-control-behavior.asciidoc[]
+include::prebuilt-rule-8-19-24-first-time-fortigate-administrator-login.asciidoc[]
+include::prebuilt-rule-8-19-24-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc[]
+include::prebuilt-rule-8-19-24-suspicious-module-loaded-by-lsass.asciidoc[]
+include::prebuilt-rule-8-19-24-lsass-memory-dump-handle-access.asciidoc[]
+include::prebuilt-rule-8-19-24-lsass-process-access-via-windows-api.asciidoc[]
+include::prebuilt-rule-8-19-24-mimikatz-memssp-log-file-detected.asciidoc[]
+include::prebuilt-rule-8-19-24-untrusted-driver-loaded.asciidoc[]
+include::prebuilt-rule-8-19-24-system-public-ip-discovery-via-dns-query.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-foxmail-exploitation.asciidoc[]
+include::prebuilt-rule-8-19-24-unusual-execution-via-microsoft-common-console-file.asciidoc[]
+include::prebuilt-rule-8-19-24-wps-office-exploitation-via-dll-hijack.asciidoc[]
+include::prebuilt-rule-8-19-24-execution-of-file-written-or-modified-by-microsoft-office.asciidoc[]
+include::prebuilt-rule-8-19-24-suspicious-execution-with-nodejs.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-notepad-markdown-rce-exploitation.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-powershell-hacktool-script-by-author.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-malicious-powershell-based-on-alert-correlation.asciidoc[]
+include::prebuilt-rule-8-19-24-powershell-psreflect-script.asciidoc[]
+include::prebuilt-rule-8-19-24-command-and-scripting-interpreter-via-windows-scripts.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-command-shell-via-netcat.asciidoc[]
+include::prebuilt-rule-8-19-24-suspicious-execution-from-a-webdav-share.asciidoc[]
+include::prebuilt-rule-8-19-24-suspicious-javascript-execution-via-deno.asciidoc[]
+include::prebuilt-rule-8-19-24-suspicious-cmd-execution-via-wmi.asciidoc[]
+include::prebuilt-rule-8-19-24-conhost-spawned-by-suspicious-parent-process.asciidoc[]
+include::prebuilt-rule-8-19-24-suspicious-windows-command-shell-arguments.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-fake-captcha-phishing-attack.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-execution-via-filefix-phishing-attack.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-system-tampering-via-file-modification.asciidoc[]
+include::prebuilt-rule-8-19-24-suspicious-file-renamed-via-smb.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-ransomware-note-file-dropped-via-smb.asciidoc[]
+include::prebuilt-rule-8-19-24-volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc[]
+include::prebuilt-rule-8-19-24-volume-shadow-copy-deletion-via-powershell.asciidoc[]
+include::prebuilt-rule-8-19-24-volume-shadow-copy-deletion-via-wmic.asciidoc[]
+include::prebuilt-rule-8-19-24-suspicious-execution-from-inet-cache.asciidoc[]
+include::prebuilt-rule-8-19-24-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc[]
+include::prebuilt-rule-8-19-24-microsoft-exchange-worker-spawning-suspicious-processes.asciidoc[]
+include::prebuilt-rule-8-19-24-windows-server-update-service-spawning-suspicious-processes.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-cve-2025-33053-exploitation.asciidoc[]
+include::prebuilt-rule-8-19-24-screenconnect-server-spawning-suspicious-processes.asciidoc[]
+include::prebuilt-rule-8-19-24-suspicious-kerberos-authentication-ticket-request.asciidoc[]
+include::prebuilt-rule-8-19-24-incoming-dcom-lateral-movement-via-mshta.asciidoc[]
+include::prebuilt-rule-8-19-24-incoming-dcom-lateral-movement-with-mmc.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-remote-desktop-shadowing-activity.asciidoc[]
+include::prebuilt-rule-8-19-24-execution-via-tsclient-mountpoint.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-sharprdp-behavior.asciidoc[]
+include::prebuilt-rule-8-19-24-unusual-child-process-of-dns-exe.asciidoc[]
+include::prebuilt-rule-8-19-24-lateral-movement-via-startup-folder.asciidoc[]
+include::prebuilt-rule-8-19-24-adminsdholder-backdoor.asciidoc[]
+include::prebuilt-rule-8-19-24-creation-of-a-hidden-local-user-account.asciidoc[]
+include::prebuilt-rule-8-19-24-suspicious-startup-shell-folder-modification.asciidoc[]
+include::prebuilt-rule-8-19-24-persistence-via-microsoft-office-addins.asciidoc[]
+include::prebuilt-rule-8-19-24-krbtgt-delegation-backdoor.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-modification-of-accessibility-binaries.asciidoc[]
+include::prebuilt-rule-8-19-24-adminsdholder-sdprop-exclusion-added.asciidoc[]
+include::prebuilt-rule-8-19-24-suspicious-imagepath-service-creation.asciidoc[]
+include::prebuilt-rule-8-19-24-persistence-via-hidden-run-key-detected.asciidoc[]
+include::prebuilt-rule-8-19-24-persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc[]
+include::prebuilt-rule-8-19-24-persistence-via-update-orchestrator-service-hijack.asciidoc[]
+include::prebuilt-rule-8-19-24-persistence-via-wmi-standard-registry-provider.asciidoc[]
+include::prebuilt-rule-8-19-24-web-shell-detection-script-process-child-of-common-web-processes.asciidoc[]
+include::prebuilt-rule-8-19-24-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc[]
+include::prebuilt-rule-8-19-24-dmsa-account-creation-by-an-unusual-user.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-privilege-escalation-via-cve-2022-38028.asciidoc[]
+include::prebuilt-rule-8-19-24-group-policy-abuse-for-privilege-addition.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-privilege-escalation-via-installerfiletakeover.asciidoc[]
+include::prebuilt-rule-8-19-24-service-creation-via-local-kerberos-authentication.asciidoc[]
+include::prebuilt-rule-8-19-24-interactive-logon-by-an-unusual-process.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-escalation-via-vulnerable-msi-repair.asciidoc[]
+include::prebuilt-rule-8-19-24-privilege-escalation-via-named-pipe-impersonation.asciidoc[]
+include::prebuilt-rule-8-19-24-suspicious-print-spooler-point-and-print-dll.asciidoc[]
+include::prebuilt-rule-8-19-24-privilege-escalation-via-windir-environment-variable.asciidoc[]
+include::prebuilt-rule-8-19-24-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc[]
+include::prebuilt-rule-8-19-24-remote-computer-account-dnshostname-update.asciidoc[]
+include::prebuilt-rule-8-19-24-suspicious-seincreasebasepriorityprivilege-use.asciidoc[]
+include::prebuilt-rule-8-19-24-uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc[]
+include::prebuilt-rule-8-19-24-uac-bypass-via-icmluautil-elevated-com-interface.asciidoc[]
+include::prebuilt-rule-8-19-24-bypass-uac-via-event-viewer.asciidoc[]
+include::prebuilt-rule-8-19-24-uac-bypass-attempt-via-windows-directory-masquerading.asciidoc[]
+include::prebuilt-rule-8-19-24-privileges-elevation-via-parent-process-pid-spoofing.asciidoc[]
+include::prebuilt-rule-8-19-24-privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc[]
+include::prebuilt-rule-8-19-24-process-created-with-an-elevated-token.asciidoc[]
+include::prebuilt-rule-8-19-24-windows-service-installed-via-an-unusual-client.asciidoc[]
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rules-8-19-24-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rules-8-19-24-summary.asciidoc
new file mode 100644
index 0000000000..a1eb5a48c1
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rules-8-19-24-summary.asciidoc
@@ -0,0 +1,282 @@
+[[prebuilt-rule-8-19-24-prebuilt-rules-8-19-24-summary]]
+[role="xpack"]
+== Update v8.19.24
+
+This section lists all updates associated with version 8.19.24 of the Fleet integration *Prebuilt Security Detection Rules*.
+
+
+[width="100%",options="header"]
+|==============================================
+|Rule |Description |Status |Version
+
+|<<prebuilt-rule-8-19-24-aws-eks-control-plane-logging-disabled, AWS EKS Control Plane Logging Disabled>> | Detects successful Amazon EKS UpdateClusterConfig requests that disable control plane logging. Disabling EKS API server and control plane logs can reduce visibility into cluster activity and may indicate defense evasion following compromised AWS credentials or unauthorized administrative access. EKS control plane logging changes are typically rare and should align with approved maintenance or cost optimization workflows. | new | 1 
+
+|<<prebuilt-rule-8-19-24-aws-eks-access-entry-modified, AWS EKS Access Entry Modified>> | Detects successful Amazon EKS Access Entries API operations that create, update, attach, detach, or delete authentication mappings between IAM principals and the cluster. Changes to access entries alter who can authenticate to Kubernetes and what Kubernetes-level permissions they receive, without requiring edits to in-cluster RBAC objects. Unexpected callers or timing may indicate persistence or privilege abuse. Common automation identities (service-linked roles, eksctl, Terraform, CloudFormation role patterns) are excluded to reduce noise; tune further for your deployment pipelines. | new | 1 
+
+|<<prebuilt-rule-8-19-24-aws-eks-access-entry-granted-cluster-admin-policy, AWS EKS Access Entry Granted Cluster Admin Policy>> | Detects when the AmazonEKSClusterAdminPolicy or AmazonEKSAdminPolicy is associated with a principal via the EKS Access Entries API. This grants full cluster-admin equivalent access to the specified IAM user or role. Unlike the legacy aws-auth ConfigMap which is only visible in Kubernetes audit logs, Access Entries modifications appear in CloudTrail, providing an additional detection surface. Attackers who have obtained IAM permissions to manage EKS access entries can use this API to backdoor cluster access for persistence, mapping attacker-controlled IAM identities to cluster-admin privileges without modifying any Kubernetes resources. | new | 1 
+
+|<<prebuilt-rule-8-19-24-microsoft-graph-multi-category-reconnaissance-burst, Microsoft Graph Multi-Category Reconnaissance Burst>> | Detects Microsoft Graph activity from delegated user tokens (public client, client_auth_method 0) where a single user session and source IP rapidly touches multiple high-value Graph paths indicative of reconnaissance. The query classifies requests into categories such as role discovery, cross-tenant relationship queries, mailbox paths, contact harvesting, and organization or licensing metadata. When three or more distinct categories appear within a short burst window, it suggests a broad enumeration playbook rather than normal application traffic. | new | 1 
+
+|<<prebuilt-rule-8-19-24-entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource, Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource>> | Detects successful Microsoft Entra ID sign-ins where the client application is the Microsoft Authentication Broker (MAB) and the requested resource identifier is outside a short list of commonly observed first-party targets. Attackers abuse the broker in phishing and token broker flows to obtain tokens for unexpected APIs or enterprise applications. The exclusion list covers legacy Azure Active Directory, Microsoft Graph, Device Registration Service, Microsoft Intune Enrollment, extend or tune exclusions for your tenant after baselining broker traffic. | new | 1 
+
+|<<prebuilt-rule-8-19-24-entra-id-oauth-device-code-phishing-via-aitm, Entra ID OAuth Device Code Phishing via AiTM>> | Detects successful Microsoft Entra ID sign-ins that use the OAuth device code authentication protocol with the Microsoft Authentication Broker client requesting first-party Office API resources (Exchange Online, Microsoft Graph, or SharePoint) while flagged as interactive. This pattern is associated with adversary-in-the-middle (AiTM) phishing kits such as Tycoon 2FA, where victims complete device code flows that ultimately broker tokens for mail and collaboration APIs. | new | 1 
+
+|<<prebuilt-rule-8-19-24-entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa, Entra ID Potential AiTM Sign-In via OfficeHome (Tycoon2FA)>> | Detects Microsoft Entra ID sign-ins consistent with Tycoon2FA phishing-as-a-service (PhaaS) adversary-in-the-middle (AiTM) activity: the Microsoft Authentication Broker requesting tokens for Microsoft Graph or Exchange Online, or the Office web client application authenticating to itself, combined with Node.js-style user agents (node, axios, undici). Tycoon 2FA bypasses MFA by relaying authentication and capturing session material, often targeting Microsoft 365 and Gmail. Baseline legitimate automation and developer tooling before tuning. | new | 1 
+
+|<<prebuilt-rule-8-19-24-entra-id-register-device-with-unusual-user-agent-azure-ad-join, Entra ID Register Device with Unusual User Agent (Azure AD Join)>> | Detects successful Microsoft Entra ID audit events for Register device where additional details indicate an Azure AD join and the recorded user agent is not one of the common native registration clients (Dsreg, DeviceRegistrationClient, or Dalvik-based Android enrollment). Legitimate Windows and standard mobile enrollment flows often present predictable user-agent strings; unexpected clients may reflect scripted registration, third-party tooling, or adversary-driven device registration used for persistence or token abuse. Baseline approved provisioning tools and MDM integrations before tuning. | new | 1 
+
+|<<prebuilt-rule-8-19-24-google-workspace-device-registration-after-oauth-from-suspicious-asn, Google Workspace Device Registration After OAuth from Suspicious ASN>> | Detects when a Google Workspace account completes OAuth authorization for a specific Google OAuth client from a high-risk autonomous system number (ASN), followed within 30 seconds by a device registration event with account state REGISTERED. This sequence can indicate device enrollment or join flows initiated from attacker-controlled or residential-proxy infrastructure after a user authorizes a sensitive client. | new | 1 
+
+|<<prebuilt-rule-8-19-24-kubernetes-pod-exec-cloud-instance-metadata-access, Kubernetes Pod Exec Cloud Instance Metadata Access>> | Detects Kubernetes pod exec sessions whose decoded command line references cloud instance metadata endpoints or equivalent hostnames and paths. Workloads that reach the link-local metadata IP, AWS IMDS paths, GCP computeMetadata, Azure IMDS token routes, or encoded variants are often attempting to harvest role credentials, tokens, or instance attributes from the underlying node or hypervisor boundary. That behavior is high risk in multi-tenant and regulated environments because it can expose short-lived cloud credentials to code running inside a container. The rule classifies a coarse cloud target label and whether the string looks like credential retrieval versus lighter reconnaissance. | new | 1 
+
+|<<prebuilt-rule-8-19-24-kubernetes-pod-exec-sensitive-file-or-credential-path-access, Kubernetes Pod Exec Sensitive File or Credential Path Access>> | Detects Kubernetes pod exec sessions whose decoded command line references high-value host or in-cluster paths and material types: mounted service account or platform tokens, kubelet and control-plane configuration areas, host identity stores, root dot-directories for cloud and kubeconfig material, common private-key and keystore extensions, process environment dumps, and configuration filenames suggestive of embedded secrets. The intent is to catch interactive or scripted access that often precedes lateral movement, privilege escalation, or credential theft from the node or workload boundary. A narrow exclusion ignores benign reads of resolv.conf. The query also labels an access_type bucket to speed triage without altering the detection predicates you validated. | new | 1 
+
+|<<prebuilt-rule-8-19-24-kubernetes-service-account-token-created-via-tokenrequest-api, Kubernetes Service Account Token Created via TokenRequest API>> | Detects the creation of a Kubernetes service account token through the TokenRequest API by a non-system identity. The TokenRequest API allows users and workloads to programmatically generate short-lived tokens for any service account they have create permissions on, without accessing the filesystem or the mounted projected token. Attackers who have gained initial access to a cluster can abuse this API to mint tokens for more privileged service accounts, pivot to cloud provider resources via IRSA/workload identity, or generate long-lived tokens that persist beyond pod termination. Unlike mounted service account tokens which are detectable through file access monitoring, tokens created via the TokenRequest API leave no filesystem footprint, they are only visible in Kubernetes audit logs as a create verb on the serviceaccounts/token subresource. This rule excludes legitimate system components such as the kubelet, kube-controller-manager, and cloud provider managed identities (EKS, AKS, GKE) that routinely create tokens for pod lifecycle management. | new | 1 
+
+|<<prebuilt-rule-8-19-24-kubernetes-pod-exec-with-curl-or-wget-to-https, Kubernetes Pod Exec with Curl or Wget to HTTPS>> | Detects pod or attach exec API calls where the decoded request query implies **curl** or wget fetching an **https** URL. Attackers with permission to exec into workloads often run one-liners to stage tooling, pull scripts or binaries, or exfiltrate data over HTTPS—activity that should be rare compared to shells, debuggers, or expected health checks. The rule decodes the audit requestURI, reconstructs a readable command string from repeated command parameters, and applies **noise filters** for common cluster health and OIDC/JWKS endpoints so benign automation is less likely to alert. | new | 1 
+
+|<<prebuilt-rule-8-19-24-kubernetes-pod-exec-potential-reverse-shell, Kubernetes Pod Exec Potential Reverse Shell>> | Flags exec into a pod when the URL-decoded command payload resembles reverse-shell or bind-shell one-liners invocation patterns. Legitimate debug sessions sometimes use similar building blocks, but together these patterns align with post-exploitation interactive access and command-and-control. | new | 1 
+
+|<<prebuilt-rule-8-19-24-kubernetes-coredns-or-kube-dns-configuration-modified, Kubernetes CoreDNS or Kube-DNS Configuration Modified>> | Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace. These ConfigMaps control cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service DNS names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server, database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every pod in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS configuration changes are rare in normal operations and any unexpected modification should be investigated immediately. | new | 1 
+
+|<<prebuilt-rule-8-19-24-kubernetes-admission-webhook-created-or-modified, Kubernetes Admission Webhook Created or Modified>> | Detects creation, modification, or deletion of Kubernetes MutatingWebhookConfigurations or ValidatingWebhookConfigurations by non-system identities. Admission webhooks intercept every API request matching their rules before persistence, giving an attacker powerful capabilities: injecting malicious sidecars into every new pod via a mutating webhook, blocking security tooling deployments via a validating webhook, or silently exfiltrating pod specifications to an external server. Webhook manipulation is a stealthy persistence and defense evasion technique because the webhook configuration itself looks benign in kubectl output while actively modifying or intercepting all matching Kubernetes API traffic. | new | 1 
+
+|<<prebuilt-rule-8-19-24-kubernetes-client-certificate-signing-request-created-or-approved, Kubernetes Client Certificate Signing Request Created or Approved>> | Detects creation or approval of a Kubernetes CertificateSigningRequest (CSR) by a non-system identity. Attackers who have gained cluster access can submit a CSR with a privileged Common Name such as system:kube-controller-manager or system:masters, then approve it themselves to obtain a long-lived client certificate. Unlike service account tokens which expire in hours, client certificates persist until they expire or the cluster CA is rotated, providing durable access that survives pod termination, token revocation, and RBAC changes. On non-EKS clusters, the signed certificate allows the attacker to authenticate as the privileged identity from anywhere without needing cluster network access, making it one of the most persistent backdoor mechanisms available in Kubernetes. | new | 1 
+
+|<<prebuilt-rule-8-19-24-eks-authentication-configuration-modified, EKS Authentication Configuration Modified>> | Detects modifications to the aws-auth ConfigMap in Amazon EKS clusters. The aws-auth ConfigMap maps AWS IAM roles and users to Kubernetes RBAC groups, an attacker who modifies it can grant any IAM role cluster-admin access by adding a mapping to the system:masters group. This is a well-documented persistence technique that survives pod restarts, node replacements, and RBAC changes because the authentication mapping exists outside of normal Kubernetes Role objects. Modifications to aws-auth are rare in normal operations, the ConfigMap is typically set during cluster provisioning and updated only during node group or access configuration changes. | new | 1 
+
+|<<prebuilt-rule-8-19-24-kubernetes-api-server-proxying-request-to-kubelet, Kubernetes API Server Proxying Request to Kubelet>> | Detects non-system identities using the Kubernetes nodes/proxy API to proxy requests through the API server directly to a node's Kubelet. The nodes/proxy subresource allows any principal with this RBAC permission to reach the Kubelet API on any worker node without needing direct network access or Kubelet TLS certificates. Through this proxy path, an attacker can list all pod specifications including environment variable secrets, read Kubelet configuration and PKI material, retrieve container logs, and access running pod metadata across all workloads on the target node. Monitoring and health check endpoints such as /metrics, /healthz, and /stats are excluded to reduce noise from legitimate observability tooling. | new | 1 
+
+|<<prebuilt-rule-8-19-24-kubernetes-api-request-impersonating-privileged-identity, Kubernetes API Request Impersonating Privileged Identity>> | Detects Kubernetes API requests where a user is impersonating a privileged cluster identity such as system:kube-controller-manager, system:admin, system:anonymous, or a member of the system:masters group. These identities have broad cluster-wide permissions including unrestricted access to all secrets, the ability to create tokens for any service account, schedule pods on any node, and modify RBAC policies. An attacker impersonating system:masters gains full cluster-admin equivalent access, while impersonating system:kube-controller-manager grants access to every secret in every namespace and the ability to mint service account tokens for lateral movement. | new | 1 
+
+|<<prebuilt-rule-8-19-24-kubernetes-ephemeral-container-added-to-pod, Kubernetes Ephemeral Container Added to Pod>> | Detects allowed updates to the pods/ephemeralcontainers subresource by a non-system identity. Ephemeral containers are commonly used for debugging (kubectl debug) but can also be abused to inject tooling into a running pod, access mounted secrets, and execute commands in the target pod context. Attackers with sufficient RBAC may use ephemeral containers to escalate privileges, move laterally, or establish persistence without deploying a new workload. | new | 1 
+
+|<<prebuilt-rule-8-19-24-m365-potential-aitm-userloggedin-via-office-app-tycoon2fa, M365 Potential AiTM UserLoggedIn via Office App (Tycoon2FA)>> | Detects Microsoft 365 audit "UserLoggedIn" events consistent with Tycoon 2FA phishing-as-a-service (PhaaS) adversary-in-the-middle (AiTM) activity: the Microsoft Authentication Broker requesting access where the object identifier matches Microsoft Graph or Exchange Online, or the Office web client application authenticating to itself, combined with Node.js-style user agents (node, axios, undici). Tycoon 2FA bypasses MFA by relaying authentication and capturing session material, often targeting Microsoft 365 and Gmail. Baseline legitimate automation and developer tooling before tuning. | new | 1 
+
+|<<prebuilt-rule-8-19-24-kubernetes-and-cloud-credential-path-access-via-process-arguments, Kubernetes and Cloud Credential Path Access via Process Arguments>> | Flags Linux process executions whose arguments reference high-value Kubernetes service-account material, kubeconfig or node PKI paths, or common cloud and SSH credential files, when invoked via typical file-reading utilities or from ephemeral directories. Useful for spotting in-cluster and hybrid credential theft early. | new | 1 
+
+|<<prebuilt-rule-8-19-24-potential-kubeletctl-execution, Potential Kubeletctl Execution>> | Detects the execution of kubeletctl on Linux hosts. Kubeletctl is a command-line tool that can be used to interact with the Kubelet API directly, simplifying access to Kubelet endpoints that can be used for discovery and, in some cases, lateral movement within Kubernetes environments. | new | 1 
+
+|<<prebuilt-rule-8-19-24-container-runtime-cli-execution-with-suspicious-arguments, Container Runtime CLI Execution with Suspicious Arguments>> | Detects execution of container runtime CLI tools (ctr, crictl, nerdctl) with arguments indicating container creation, command execution inside existing containers, image manipulation, or host filesystem mounting. These tools interact directly with the container runtime socket, bypassing the Kubernetes API server, RBAC authorization, admission webhooks, pod security standards, and Kubernetes audit logging entirely. Attackers with host-level access may use these tools to create privileged ghost containers, exec into other pods to steal service account tokens and secrets, pull attacker-controlled images, and destroy evidence, all while remaining invisible to Kubernetes-level monitoring. | new | 1 
+
+|<<prebuilt-rule-8-19-24-potential-direct-kubelet-access-via-process-arguments, Potential Direct Kubelet Access via Process Arguments>> | Detects potential direct Kubelet API access attempts on Linux by identifying process executions whose arguments contain URLs targeting Kubelet ports (10250/10255). Adversaries may probe or access Kubelet endpoints to enumerate pods, fetch logs, or attempt remote execution, which can enable discovery and lateral movement in Kubernetes environments. | new | 1 
+
+|<<prebuilt-rule-8-19-24-kubelet-api-connection-attempt-to-internal-ip, Kubelet API Connection Attempt to Internal IP>> | Detects network connection attempts to the Kubernetes Kubelet API port (10250/10255) on internal IP ranges from Linux hosts. This rule focuses on common request and scripting utilities (curl, wget, python, node, etc.) and executions from world-writable or ephemeral paths (/tmp, /var/tmp, /dev/shm, /var/run), which are frequently abused during container and cluster lateral movement. | new | 1 
+
+|<<prebuilt-rule-8-19-24-kubernetes-static-pod-manifest-file-access, Kubernetes Static Pod Manifest File Access>> | Detects Linux process executions where shells, editors, interpreters, or file/stream utilities reference /etc/kubernetes/manifests in process arguments. That directory holds static pod manifests read by the kubelet; interaction via editors, downloaders, kubectl, redirection helpers (tee, dd), or scripting runtimes may indicate staging or tampering with manifests for persistence or privileged workload placement. Pairs with file-telemetry rules that flag direct manifest creation on container workloads. | new | 1 
+
+|<<prebuilt-rule-8-19-24-potential-privilege-escalation-in-container-via-runc-init, Potential Privilege Escalation in Container via Runc Init>> | Identifies audit events for runc init child processes where the effective user is root and the login user ID is not root. This pattern can indicate privilege escalation or credential separation abuse inside container runtimes, where a process executes with elevated effective privileges while retaining a non-root audit identity. | new | 1 
+
+|<<prebuilt-rule-8-19-24-potential-privilege-escalation-via-suid-sgid, Potential Privilege Escalation via SUID/SGID>> | Detects potential privilege escalation under the root effective user when the real user and parent user are not root, indicative of the execution of binaries with SUID or SGID bits set. | new | 1 
+
+|<<prebuilt-rule-8-19-24-suspicious-suid-binary-execution-auditd-sequence, Suspicious SUID Binary Execution (Auditd Sequence)>> | Detects suspicious sequences where a non-root user launches a high-risk parent process (interpreter, shell one-liner, or execution from user-writable paths) and then quickly executes a common privilege elevation helper (su, sudo, pkexec, passwd, chsh, newgrp) that gains an effective UID of 0 while the real UID remains non-root. This can indicate misuse of SUID/SGID helpers, polkit/sudo abuse, or interactive privilege escalation attempts captured via Auditd Manager telemetry. | new | 1 
+
+|<<prebuilt-rule-8-19-24-potential-privilege-escalation-via-unshare-followed-by-root-process, Potential Privilege Escalation via unshare Followed by Root Process>> | Detects a short sequence where a non-root user performs unshare-related namespace activity (often associated with user namespace privilege escalation primitives) and then a root process is executed shortly after. This can indicate a successful local privilege escalation attempt or suspicious namespace manipulation captured in Auditd Manager telemetry. | new | 1 
+
+|<<prebuilt-rule-8-19-24-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940, Potential cPanel WHM CRLF Authentication Bypass (CVE-2026-41940)>> | Identifies the network signature of CVE-2026-41940, a pre-auth root-level authentication bypass in cPanel and WebHost Manager (WHM) caused by a CRLF injection in the session writer. The exploit-inherent shape on the wire is a `GET /` request to a cPanel/WHM admin port (typically TCP/2087, 2086, 2083, 2082, 2095, 2096) carrying an `Authorization: Basic` header whose base64-decoded value contains CRLF-injected session fields, which causes cpsrvd to respond with a 3xx redirect whose `Location` header leaks a `/cpsessNNNNNNNNNN` token granting the attacker a privileged session. This is the network-layer equivalent of the cPanel `access_log` artifact identified by Unfold and watchTowr as the first bulletproof detection for this CVE: a `GET /` recorded with `auth_method=b` (HTTP Basic). Legitimate access to `GET /` on a WHM admin port returns 200 with the login screen and never includes HTTP Basic credentials, so this combination is not produced by normal use. | new | 1 
+
+|<<prebuilt-rule-8-19-24-aws-ssm-session-manager-child-process-execution, AWS SSM Session Manager Child Process Execution>> | Identifies process start events where the parent process is the AWS Systems Manager (SSM) Session Manager worker. Session Manager provides interactive shell access to EC2 instances and hybrid nodes without bastion hosts or open inbound ports. Adversaries abuse it for remote execution and lateral movement using legitimate AWS credentials and IAM permissions. This rule surfaces endpoint execution occurring under that worker for visibility and hunting. Expect noise from authorized administrative sessions. | update | 2 
+
+|<<prebuilt-rule-8-19-24-github-private-repository-turned-public, GitHub Private Repository Turned Public>> | Detects when a private GitHub repository is changed to public visibility. Adversaries may change repository visibility to public in order to exfiltrate sensitive code or data, potentially indicating a compromise or unauthorized access. | update | 3 
+
+|<<prebuilt-rule-8-19-24-kubernetes-rapid-secret-get-activity-against-multiple-objects, Kubernetes Rapid Secret GET Activity Against Multiple Objects>> | This rule detects an unusual volume of Kubernetes API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within a defined lookback window. This can indicate credential access or in-cluster reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. Failed get requests are also included, as they may reveal RBAC boundaries, confirm the existence of targeted secrets, or reflect automated probing activity. | update | 2 
+
+|<<prebuilt-rule-8-19-24-kubernetes-secret-get-or-list-from-node-or-pod-service-account, Kubernetes Secret get or list from Node or Pod Service Account>> | Kubernetes audit identities for kubelet (`system:node:*`) and workloads (`system:serviceaccount:*`) are meant to operate with tight, predictable API usage. Direct `get` or `list` on the Secrets API from those principals is often a sign of credential access. Attackers who stole a pod service-account token or node credentials sweep Secret objects for tokens, registry credentials, TLS keys, or application configuration. Even denied attempts still reveal intent to reach sensitive material. Legitimate controllers do read secrets they mount or manage, so this signal is most valuable when paired with triage (namespace scope, user agent, RBAC, and whether the identity should touch those secret names at all). | update | 2 
+
+|<<prebuilt-rule-8-19-24-kubernetes-secrets-list-across-cluster-or-sensitive-namespaces, Kubernetes Secrets List Across Cluster or Sensitive Namespaces>> | Detects list operations on Kubernetes Secrets from a non-loopback client when the request URI targets cluster-wide secrets or list operations under kube-system or default. Useful for spotting broad secret enumeration from remote clients. | update | 2 
+
+|<<prebuilt-rule-8-19-24-kubernetes-multi-resource-discovery, Kubernetes Multi-Resource Discovery>> | Adversaries who land credentials in a 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 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. It is less typical for steady-state controllers, which usually touch a narrow set of resources repeatedly. This rule highlights that cross-resource burst from a single client fingerprint within a one-minute bucket so analysts can separate routine automation from potential discovery and permission reconnaissance ahead of follow-on actions. | update | 2 
+
+|<<prebuilt-rule-8-19-24-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. | update | 11 
+
+|<<prebuilt-rule-8-19-24-m365-identity-login-from-impossible-travel-location, M365 Identity Login from Impossible Travel Location>> | Detects successful Microsoft 365 portal logins from impossible travel locations. Impossible travel locations are defined as two different countries within a short time frame. This behavior may indicate an adversary attempting to access a Microsoft 365 account from a compromised account or a malicious actor attempting to access a Microsoft 365 account from a different location. | update | 10 
+
+|<<prebuilt-rule-8-19-24-curl-or-wget-execution-from-container-context, Curl or Wget Execution from Container Context>> | Detects execution of curl or wget from processes whose title aligns with **`runc init`**, a common fingerprint for workloads running inside **OCI/runc-backed containers** on Linux hosts instrumented with Auditd Manager. After breaking out of an application container or abusing a privileged workload, attackers often pull ingress tooling (stagers, scripts, implants) or stage exfiltration with minimal HTTP clients. Those utilities are also used benignly in images, so context matters; the `runc init` anchor narrows the signal to the container runtime boundary where unexpected download clients are more worthy of review than the same binaries on a bare-metal admin shell. | update | 2 
+
+|<<prebuilt-rule-8-19-24-sensitive-files-compression, Sensitive Files Compression>> | Identifies the use of a compression utility to collect known files containing sensitive information, such as credentials and system configurations. | update | 215 
+
+|<<prebuilt-rule-8-19-24-file-creation-in-world-writable-directory-by-unusual-process, File Creation in World-Writable Directory by Unusual Process>> | This rule detects the creation of files in world-writable directories by an unusual process. Attackers may attempt to hide their activities by creating files in world-writable directories, which are commonly used for temporary file storage. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network. | update | 2 
+
+|<<prebuilt-rule-8-19-24-potential-reverse-shell-via-java, Potential Reverse Shell via Java>> | This detection rule identifies the execution of a Linux shell process from a Java JAR application post an incoming network connection. This behavior may indicate reverse shell activity via a Java application. | update | 14 
+
+|<<prebuilt-rule-8-19-24-potential-privilege-escalation-via-unshare-and-uid-change, Potential Privilege Escalation via unshare and UID Change>> | Identifies potentially suspicious use of unshare to create a user namespace context followed by a UID change event indicating a transition to root. Adversaries may use unshare-based primitives as part of local privilege escalation chains. This rule is intentionally generic and can surface multiple local privesc patterns beyond a single CVE. | update | 11 
+
+|<<prebuilt-rule-8-19-24-suspicious-suid-binary-execution, Suspicious SUID Binary Execution>> | Detects execution of SUID binaries that may be used for privilege escalation under the root effective user when the real user and parent user are not root, combined with minimal argument counts and suspicious parent context (interpreters, short shell -c invocations, or parents running from user-writable paths) to indicate potential misuse of SUID binaries for privilege escalation. | update | 2 
+
+|<<prebuilt-rule-8-19-24-potential-macos-ssh-brute-force-detected, Potential macOS SSH Brute Force Detected>> | Identifies a high number of inbound SSH login attempts on a macOS host within a short time window. On macOS, each inbound SSH authentication attempt spawns the sshd-keygen-wrapper process once, whether the login succeeds or fails. Adversaries may perform password brute force or password spraying against exposed SSH services to obtain unauthorized access. | update | 113 
+
+|<<prebuilt-rule-8-19-24-dns-request-for-ip-lookup-service-via-unsigned-binary, DNS Request for IP Lookup Service via Unsigned Binary>> | Detects when a DNS request is made for an IP lookup service to determine the external IP address of the system via an unsigned or untrusted binary. This is commonly used by malware for reconnaissance before establishing C2 connections. | update | 2 
+
+|<<prebuilt-rule-8-19-24-suspicious-macos-ms-office-child-process, Suspicious macOS MS Office Child Process>> | Identifies suspicious child processes of frequently targeted Microsoft Office applications (Word, PowerPoint, and Excel). These child processes are often launched during exploitation of Office applications or by documents with malicious macros. | update | 213 
+
+|<<prebuilt-rule-8-19-24-finder-sync-plugin-registered-and-enabled, Finder Sync Plugin Registered and Enabled>> | Finder Sync plugins enable users to extend Finder’s functionality by modifying the user interface. Adversaries may abuse this feature by adding a rogue Finder Plugin to repeatedly execute malicious payloads for persistence. | update | 212 
+
+|<<prebuilt-rule-8-19-24-user-added-to-the-admin-group, User Added to the Admin Group>> | Identifies users being added to the admin group. This could be an indication of privilege escalation activity. | update | 6 
+
+|<<prebuilt-rule-8-19-24-cobalt-strike-command-and-control-beacon, Cobalt Strike Command and Control Beacon>> | Cobalt Strike is a threat emulation platform commonly modified and used by adversaries to conduct network attack and exploitation campaigns. This rule detects a network activity algorithm leveraged by Cobalt Strike implant beacons for command and control. | update | 109 
+
+|<<prebuilt-rule-8-19-24-possible-fin7-dga-command-and-control-behavior, Possible FIN7 DGA Command and Control Behavior>> | This rule detects a known command and control pattern in network events. The FIN7 threat group is known to use this command and control technique, while maintaining persistence in their target's network. | update | 110 
+
+|<<prebuilt-rule-8-19-24-first-time-fortigate-administrator-login, First-Time FortiGate Administrator Login>> | This rule detects the first observed successful login of a user with the Administrator role to the FortiGate management interface within the last 5 days. First-time administrator logins can indicate newly provisioned accounts, misconfigurations, or unauthorized access using valid credentials and should be reviewed promptly. | update | 5 
+
+|<<prebuilt-rule-8-19-24-inbound-connection-to-an-unsecure-elasticsearch-node, Inbound Connection to an Unsecure Elasticsearch Node>> | Identifies Elasticsearch nodes that do not have Transport Layer Security (TLS), and/or lack authentication, and are accepting inbound network connections over the default Elasticsearch port. | update | 108 
+
+|<<prebuilt-rule-8-19-24-suspicious-module-loaded-by-lsass, Suspicious Module Loaded by LSASS>> | Identifies LSASS loading an unsigned or untrusted DLL. Windows Security Support Provider (SSP) DLLs are loaded into LSSAS process at system start. Once loaded into the LSA, SSP DLLs have access to encrypted and plaintext passwords that are stored in Windows, such as any logged-on user's Domain password or smart card PINs. | update | 15 
+
+|<<prebuilt-rule-8-19-24-lsass-memory-dump-handle-access, LSASS Memory Dump Handle Access>> | Identifies handle requests for the Local Security Authority Subsystem Service (LSASS) object access with specific access masks that many tools with a capability to dump memory to disk use (0x1fffff, 0x1010, 0x120089). This rule is tool agnostic as it has been validated against a host of various LSASS dump tools such as SharpDump, Procdump, Mimikatz, Comsvcs etc. It detects this behavior at a low level and does not depend on a specific tool or dump file name. | update | 218 
+
+|<<prebuilt-rule-8-19-24-lsass-process-access-via-windows-api, LSASS Process Access via Windows API>> | Identifies access attempts to the LSASS handle, which may indicate an attempt to dump credentials from LSASS memory. | update | 19 
+
+|<<prebuilt-rule-8-19-24-mimikatz-memssp-log-file-detected, Mimikatz Memssp Log File Detected>> | Identifies the default Mimikatz MemSSP credential log file, mimilsa.log. This file is created after the misc::memssp module injects a malicious Security Support Provider into LSASS and can contain credentials from subsequent logons to the host. | update | 419 
+
+|<<prebuilt-rule-8-19-24-untrusted-driver-loaded, Untrusted Driver Loaded>> | Identifies an untrusted driver loaded by the Windows kernel. Adversaries may modify code signing policies to enable execution of unsigned or self-signed kernel code. | update | 14 
+
+|<<prebuilt-rule-8-19-24-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. | update | 4 
+
+|<<prebuilt-rule-8-19-24-potential-foxmail-exploitation, Potential Foxmail Exploitation>> | Identifies the Foxmail client spawning a child process with arguments pointing to user-profile AppData paths or remote shares. This may indicate exploitation of a Foxmail vulnerability for initial access and execution via a malicious email. | update | 209 
+
+|<<prebuilt-rule-8-19-24-unusual-execution-via-microsoft-common-console-file, Unusual Execution via Microsoft Common Console File>> | Identifies the execution of a child process from a Microsoft Common Console file. Adversaries may embed a malicious command in an MSC file in order to trick victims into executing malicious commands. | update | 208 
+
+|<<prebuilt-rule-8-19-24-wps-office-exploitation-via-dll-hijack, WPS Office Exploitation via DLL Hijack>> | Identifies the load of a remote library by the WPS Office promecefpluginhost.exe executable. This may indicate the successful exploitation of CVE-2024-7262 or CVE-2024-7263 via DLL hijack abusing the ksoqing custom protocol handler. | update | 106 
+
+|<<prebuilt-rule-8-19-24-execution-of-file-written-or-modified-by-microsoft-office, Execution of File Written or Modified by Microsoft Office>> | Identifies an executable created by a Microsoft Office application and subsequently executed. These processes are often launched via scripts inside documents or during exploitation of Microsoft Office applications. | update | 115 
+
+|<<prebuilt-rule-8-19-24-suspicious-execution-with-nodejs, Suspicious Execution with NodeJS>> | Identifies suspicious Node.js execution patterns, including user-writable runtimes, preload arguments, and inline eval, decode, or child-process usage. | update | 4 
+
+|<<prebuilt-rule-8-19-24-potential-notepad-markdown-rce-exploitation, Potential Notepad Markdown RCE Exploitation>> | Identifies a process started by Notepad after opening a Markdown file. This may indicate successful exploitation of a Notepad markdown parsing vulnerability (CVE-2026-20841) that can lead to arbitrary code execution. | update | 5 
+
+|<<prebuilt-rule-8-19-24-potential-powershell-hacktool-script-by-author, Potential PowerShell HackTool Script by Author>> | Identifies PowerShell script block content containing known offensive-tool author handles or attribution strings (for example, public tool author names). Attackers often run public PowerShell tooling with minimal changes, leaving author artifacts in comments or headers. | update | 110 
+
+|<<prebuilt-rule-8-19-24-potential-malicious-powershell-based-on-alert-correlation, Potential Malicious PowerShell Based on Alert Correlation>> | Identifies PowerShell script blocks linked to multiple distinct PowerShell detections via the same ScriptBlock ID, indicating compound suspicious behavior. Attackers often chain obfuscation, decoding, and execution within a single script block. | update | 7 
+
+|<<prebuilt-rule-8-19-24-powershell-psreflect-script, PowerShell PSReflect Script>> | Detects PowerShell script block content containing PSReflect-style helper indicators, such as Add-Win32Type, New-InMemoryModule, or DllImport patterns, that may support dynamic Win32 API invocation from PowerShell. | update | 318 
+
+|<<prebuilt-rule-8-19-24-command-and-scripting-interpreter-via-windows-scripts, Command and Scripting Interpreter via Windows Scripts>> | Identifies PowerShell, PowerShell ISE, or Cmd execution spawned from Windows Script Host or MSHTA. | update | 211 
+
+|<<prebuilt-rule-8-19-24-potential-command-shell-via-netcat, Potential Command Shell via NetCat>> | Identifies potential attempt to execute via a reverse shell using the netcat utility to execute Windows commands using the default interpreters like Cmd.exe and Powershell. | update | 3 
+
+|<<prebuilt-rule-8-19-24-suspicious-execution-from-a-webdav-share, Suspicious Execution from a WebDav Share>> | Identifies attempts to execute or invoke content from remote WebDAV shares. Adversaries may abuse WebDAV paths, public tunnels, or host@port UNC paths to run tools or scripts while reducing local staging on the victim file system. | update | 4 
+
+|<<prebuilt-rule-8-19-24-suspicious-javascript-execution-via-deno, Suspicious JavaScript Execution via Deno>> | Detects execution of JavaScript via Deno with suspicious command-line patterns (base64, eval, http, or import in a javascript context). Adversaries may abuse Deno to run malicious JavaScript for execution or staging. | update | 4 
+
+|<<prebuilt-rule-8-19-24-suspicious-cmd-execution-via-wmi, Suspicious Cmd Execution via WMI>> | Identifies suspicious command execution (cmd) via Windows Management Instrumentation (WMI) on a remote host. This could be indicative of adversary lateral movement. | update | 322 
+
+|<<prebuilt-rule-8-19-24-conhost-spawned-by-suspicious-parent-process, Conhost Spawned By Suspicious Parent Process>> | Detects when the Console Window Host (conhost.exe) process is spawned by a suspicious parent process, which could be indicative of code injection. | update | 314 
+
+|<<prebuilt-rule-8-19-24-suspicious-windows-command-shell-arguments, Suspicious Windows Command Shell Arguments>> | Identifies the execution of the Windows Command Shell process (cmd.exe) with suspicious argument values. This behavior is often observed during malware installation. | update | 209 
+
+|<<prebuilt-rule-8-19-24-potential-fake-captcha-phishing-attack, Potential Fake CAPTCHA Phishing Attack>> | Identifies potential fake CAPTCHA phishing attacks based on PowerShell, Cmd, or Mshta command-line values. Adversaries employ this technique via compromised websites with browser injects, posing either as fake CAPTCHAs to access the site or as a page loading error requiring a fix to display the page. The victim is instructed to copy and paste a malicious command to the Windows Run dialog box. | update | 4 
+
+|<<prebuilt-rule-8-19-24-potential-execution-via-filefix-phishing-attack, Potential Execution via FileFix Phishing Attack>> | Identifies the execution of Windows commands or downloaded files via the browser's dialog box. Adversaries may use phishing to instruct the victim to copy and paste malicious commands for execution via crafted phishing web pages. | update | 4 
+
+|<<prebuilt-rule-8-19-24-potential-system-tampering-via-file-modification, Potential System Tampering via File Modification>> | Identifies attempts to delete or modify critical files used during the boot process to prevent the system from booting. This may indicate a destructive attack behavior. | update | 5 
+
+|<<prebuilt-rule-8-19-24-suspicious-file-renamed-via-smb, Suspicious File Renamed via SMB>> | Identifies an incoming SMB connection followed by a suspicious file rename operation. This may indicate a remote ransomware attack via the SMB protocol. | update | 8 
+
+|<<prebuilt-rule-8-19-24-potential-ransomware-note-file-dropped-via-smb, Potential Ransomware Note File Dropped via SMB>> | Identifies an incoming SMB connection followed by the creation of a file with a name similar to ransomware note files. This may indicate a remote ransomware attack via the SMB protocol. | update | 8 
+
+|<<prebuilt-rule-8-19-24-volume-shadow-copy-deleted-or-resized-via-vssadmin, Volume Shadow Copy Deleted or Resized via VssAdmin>> | Identifies use of vssadmin.exe for shadow copy deletion or resizing on endpoints. This commonly occurs in tandem with ransomware or other destructive attacks. | update | 318 
+
+|<<prebuilt-rule-8-19-24-volume-shadow-copy-deletion-via-powershell, Volume Shadow Copy Deletion via PowerShell>> | Identifies the use of the Win32_ShadowCopy class and related cmdlets to achieve shadow copy deletion. This commonly occurs in tandem with ransomware or other destructive attacks. | update | 319 
+
+|<<prebuilt-rule-8-19-24-volume-shadow-copy-deletion-via-wmic, Volume Shadow Copy Deletion via WMIC>> | Identifies use of wmic.exe for shadow copy deletion on endpoints. This commonly occurs in tandem with ransomware or other destructive attacks. | update | 318 
+
+|<<prebuilt-rule-8-19-24-suspicious-execution-from-inet-cache, Suspicious Execution from INET Cache>> | Identifies the execution of a process with arguments pointing to the INetCache Folder. Adversaries may deliver malicious content via WININET during initial access. | update | 213 
+
+|<<prebuilt-rule-8-19-24-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process, Suspicious SolarWinds Web Help Desk Java Module Load or Child Process>> | Identifies the SolarWinds Web Help Desk Java process loading an untrusted or remote native module (DLL) or spawning a suspicious child process such as cmd, PowerShell, or rundll32. This behavior is uncommon for the Web Help Desk server and may indicate successful exploitation of deserialization vulnerabilities (CVE-2025-40536, CVE-2025-40551), which allow attackers to load malicious SQLite extensions and achieve remote code execution. | update | 3 
+
+|<<prebuilt-rule-8-19-24-microsoft-exchange-worker-spawning-suspicious-processes, Microsoft Exchange Worker Spawning Suspicious Processes>> | Identifies suspicious processes being spawned by the Microsoft Exchange Server worker process (w3wp). This activity may indicate exploitation activity or access to an existing web shell backdoor. | update | 316 
+
+|<<prebuilt-rule-8-19-24-windows-server-update-service-spawning-suspicious-processes, Windows Server Update Service Spawning Suspicious Processes>> | Identifies suspicious processes being spawned by the Windows Server Update Service. This activity may indicate exploitation activity or access to an existing web shell backdoor. | update | 4 
+
+|<<prebuilt-rule-8-19-24-potential-cve-2025-33053-exploitation, Potential CVE-2025-33053 Exploitation>> | Identifies Internet Explorer Diagnostics launching a helper name from a non-System32 path, which may indicate CVE-2025-33053 exploitation. | update | 4 
+
+|<<prebuilt-rule-8-19-24-screenconnect-server-spawning-suspicious-processes, ScreenConnect Server Spawning Suspicious Processes>> | Identifies suspicious processes being spawned by the ScreenConnect server process (ScreenConnect.Service.exe). This activity may indicate exploitation activity or access to an existing web shell backdoor. | update | 211 
+
+|<<prebuilt-rule-8-19-24-suspicious-kerberos-authentication-ticket-request, Suspicious Kerberos Authentication Ticket Request>> | Correlates network connections to the standard Kerberos port by an unusual process from the source machine with a Kerberos authentication ticket request from the target domain controller. | update | 5 
+
+|<<prebuilt-rule-8-19-24-incoming-dcom-lateral-movement-via-mshta, Incoming DCOM Lateral Movement via MSHTA>> | Identifies the use of Distributed Component Object Model (DCOM) to execute commands from a remote host, which are launched via the HTA Application COM Object. This behavior may indicate an attacker abusing a DCOM application to move laterally while attempting to evade detection. | update | 212 
+
+|<<prebuilt-rule-8-19-24-incoming-dcom-lateral-movement-with-mmc, Incoming DCOM Lateral Movement with MMC>> | Identifies the use of Distributed Component Object Model (DCOM) to run commands from a remote host, which are launched via the MMC20 Application COM Object. This behavior may indicate an attacker abusing a DCOM application to move laterally. | update | 213 
+
+|<<prebuilt-rule-8-19-24-potential-remote-desktop-shadowing-activity, Potential Remote Desktop Shadowing Activity>> | Identifies the modification of the Remote Desktop Protocol (RDP) Shadow registry or the execution of processes indicative of an active RDP shadowing session. An adversary may abuse the RDP Shadowing feature to spy on or control other users active RDP sessions. | update | 316 
+
+|<<prebuilt-rule-8-19-24-execution-via-tsclient-mountpoint, Execution via TSClient Mountpoint>> | Identifies execution from the Remote Desktop Protocol (RDP) shared mountpoint tsclient on the target host. This may indicate a lateral movement attempt. | update | 320 
+
+|<<prebuilt-rule-8-19-24-potential-sharprdp-behavior, Potential SharpRDP Behavior>> | Identifies potential behavior of SharpRDP, which is a tool that can be used to perform authenticated command execution against a remote target via Remote Desktop Protocol (RDP) for the purposes of lateral movement. | update | 113 
+
+|<<prebuilt-rule-8-19-24-unusual-child-process-of-dns-exe, Unusual Child Process of dns.exe>> | Identifies an unexpected process spawning from dns.exe, the process responsible for Windows DNS server services, which may indicate activity related to remote code execution or other forms of exploitation. | update | 320 
+
+|<<prebuilt-rule-8-19-24-lateral-movement-via-startup-folder, Lateral Movement via Startup Folder>> | Identifies suspicious file creations in the startup folder of a remote system. An adversary could abuse this to move laterally by dropping a malicious script or executable that will be executed after a reboot or user logon. | update | 315 
+
+|<<prebuilt-rule-8-19-24-adminsdholder-backdoor, AdminSDHolder Backdoor>> | Detects modifications in the AdminSDHolder object. Attackers can abuse the SDProp process to implement a persistent backdoor in Active Directory. SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, regaining their Administrative Privileges. | update | 216 
+
+|<<prebuilt-rule-8-19-24-creation-of-a-hidden-local-user-account, Creation of a Hidden Local User Account>> | Identifies the creation of a hidden local user account by appending the dollar sign to the account name. This is sometimes done by attackers to increase access to a system and avoid appearing in the results of accounts listing using the net users command. | update | 317 
+
+|<<prebuilt-rule-8-19-24-suspicious-startup-shell-folder-modification, Suspicious Startup Shell Folder Modification>> | Identifies suspicious startup shell folder modifications to change the default Startup directory in order to bypass detections monitoring file creation in the Windows Startup folder. | update | 320 
+
+|<<prebuilt-rule-8-19-24-persistence-via-microsoft-office-addins, Persistence via Microsoft Office AddIns>> | Detects attempts to establish persistence on an endpoint by abusing Microsoft Office add-ins. | update | 314 
+
+|<<prebuilt-rule-8-19-24-krbtgt-delegation-backdoor, KRBTGT Delegation Backdoor>> | Identifies the modification of the msDS-AllowedToDelegateTo attribute to KRBTGT. Attackers can use this technique to maintain persistence to the domain by having the ability to request tickets for the KRBTGT service. | update | 214 
+
+|<<prebuilt-rule-8-19-24-potential-modification-of-accessibility-binaries, Potential Modification of Accessibility Binaries>> | Windows contains accessibility features that may be launched with a key combination before a user has logged in. An adversary can modify the way these programs are launched to get a command prompt or backdoor without logging in to the system. | update | 218 
+
+|<<prebuilt-rule-8-19-24-adminsdholder-sdprop-exclusion-added, AdminSDHolder SDProp Exclusion Added>> | Identifies a modification on the dsHeuristics attribute on the bit that holds the configuration of groups excluded from the SDProp process. The SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, meaning that groups excluded will remain unchanged. Attackers can abuse this misconfiguration to maintain long-term access to privileged accounts in these groups. | update | 219 
+
+|<<prebuilt-rule-8-19-24-suspicious-imagepath-service-creation, Suspicious ImagePath Service Creation>> | Identifies the creation of a suspicious ImagePath value. This could be an indication of an adversary attempting to stealthily persist or escalate privileges through abnormal service creation. | update | 315 
+
+|<<prebuilt-rule-8-19-24-persistence-via-hidden-run-key-detected, Persistence via Hidden Run Key Detected>> | Identifies a persistence mechanism that utilizes the NtSetValueKey native API to create a hidden (null terminated) registry key. An adversary may use this method to hide from system utilities such as the Registry Editor (regedit). | update | 216 
+
+|<<prebuilt-rule-8-19-24-persistence-via-telemetrycontroller-scheduled-task-hijack, Persistence via TelemetryController Scheduled Task Hijack>> | Detects the successful hijack of Microsoft Compatibility Appraiser scheduled task to establish persistence with an integrity level of system. | update | 318 
+
+|<<prebuilt-rule-8-19-24-persistence-via-update-orchestrator-service-hijack, Persistence via Update Orchestrator Service Hijack>> | Identifies potential hijacking of the Microsoft Update Orchestrator Service to establish persistence with an integrity level of SYSTEM. | update | 319 
+
+|<<prebuilt-rule-8-19-24-persistence-via-wmi-standard-registry-provider, Persistence via WMI Standard Registry Provider>> | Identifies use of the Windows Management Instrumentation StdRegProv (registry provider) to modify commonly abused registry locations for persistence. | update | 114 
+
+|<<prebuilt-rule-8-19-24-web-shell-detection-script-process-child-of-common-web-processes, Web Shell Detection: Script Process Child of Common Web Processes>> | Identifies suspicious commands executed via a web server, which may suggest a vulnerability and remote shell access. | update | 424 
+
+|<<prebuilt-rule-8-19-24-delegated-managed-service-account-modification-by-an-unusual-user, Delegated Managed Service Account Modification by an Unusual User>> | Detects modifications to the msDS-ManagedAccountPrecededByLink attribute of a delegated managed service account by an unusual subject account. Attackers can abuse this attribute to inherit a target account's permissions and further elevate privileges. | update | 4 
+
+|<<prebuilt-rule-8-19-24-dmsa-account-creation-by-an-unusual-user, dMSA Account Creation by an Unusual User>> | Detects creation of a delegated Managed Service Account by an unusual subject account. Attackers can abuse weak child-object or msDS-DelegatedManagedServiceAccount rights during account migration to elevate privileges. | update | 5 
+
+|<<prebuilt-rule-8-19-24-potential-privilege-escalation-via-cve-2022-38028, Potential privilege escalation via CVE-2022-38028>> | Identifies a potential privilege escalation attempt via CVE-2022-38028 through modification of the protected Print to PDF MPDW constraints script. | update | 211 
+
+|<<prebuilt-rule-8-19-24-group-policy-abuse-for-privilege-addition, Group Policy Abuse for Privilege Addition>> | Detects the first occurrence of a modification to Group Policy Object Attributes to add privileges to user accounts or use them to add users as local admins. | update | 215 
+
+|<<prebuilt-rule-8-19-24-potential-privilege-escalation-via-installerfiletakeover, Potential Privilege Escalation via InstallerFileTakeOver>> | Identifies a potential exploitation of InstallerTakeOver (CVE-2021-41379) default PoC execution. Successful exploitation allows an unprivileged user to escalate privileges to SYSTEM. | update | 116 
+
+|<<prebuilt-rule-8-19-24-service-creation-via-local-kerberos-authentication, Service Creation via Local Kerberos Authentication>> | Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to localhost, followed by service creation from the same LogonId. This may indicate an attempt to leverage a Kerberos relay attack variant that can elevate privileges locally from a domain-joined user to LocalSystem privileges. | update | 214 
+
+|<<prebuilt-rule-8-19-24-interactive-logon-by-an-unusual-process, Interactive Logon by an Unusual Process>> | Identifies interactive logon attempt with alternate credentials and by an unusual process. Adversaries may create a new token to escalate privileges and bypass access controls. | update | 109 
+
+|<<prebuilt-rule-8-19-24-potential-escalation-via-vulnerable-msi-repair, Potential Escalation via Vulnerable MSI Repair>> | Identifies when a browser process navigates to the Microsoft Help page followed by spawning an elevated process. This may indicate a successful exploitation for privilege escalation abusing a vulnerable Windows Installer repair setup. | update | 207 
+
+|<<prebuilt-rule-8-19-24-privilege-escalation-via-named-pipe-impersonation, Privilege Escalation via Named Pipe Impersonation>> | Identifies a privilege escalation attempt via named pipe impersonation. An adversary may abuse this technique by utilizing a framework such as Metasploit's meterpreter getsystem command. | update | 319 
+
+|<<prebuilt-rule-8-19-24-suspicious-print-spooler-point-and-print-dll, Suspicious Print Spooler Point and Print DLL>> | Detects attempts to exploit a privilege escalation vulnerability (CVE-2020-1030) related to the print spooler service. Exploitation involves chaining multiple primitives to load an arbitrary DLL into the print spooler process running as SYSTEM. | update | 215 
+
+|<<prebuilt-rule-8-19-24-privilege-escalation-via-windir-environment-variable, Privilege Escalation via Windir Environment Variable>> | Identifies a privilege escalation attempt via a rogue Windows directory (Windir) environment variable. This is a known primitive that is often combined with other vulnerabilities to elevate privileges. | update | 316 
+
+|<<prebuilt-rule-8-19-24-potential-privileged-escalation-via-samaccountname-spoofing, Potential Privileged Escalation via SamAccountName Spoofing>> | Identifies a suspicious computer account name rename event, which may indicate an attempt to exploit CVE-2021-42278 to elevate privileges from a standard domain user to a user with domain admin privileges. CVE-2021-42278 is a security vulnerability that allows potential attackers to impersonate a domain controller via samAccountName attribute spoofing. | update | 216 
+
+|<<prebuilt-rule-8-19-24-remote-computer-account-dnshostname-update, Remote Computer Account DnsHostName Update>> | Identifies the remote update to a computer account's DnsHostName attribute. If the new value set is a valid domain controller DNS hostname and the subject computer name is not a domain controller, then it's highly likely a preparation step to exploit CVE-2022-26923 in an attempt to elevate privileges from a standard domain user to domain admin privileges. | update | 215 
+
+|<<prebuilt-rule-8-19-24-suspicious-seincreasebasepriorityprivilege-use, Suspicious SeIncreaseBasePriorityPrivilege Use>> | Identifies attempts to use the SeIncreaseBasePriorityPrivilege privilege by an unusual process. This could be related to hijack execution flow of a process via threats priority manipulation. | update | 3 
+
+|<<prebuilt-rule-8-19-24-uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface, UAC Bypass Attempt with IEditionUpgradeManager Elevated COM Interface>> | Identifies attempts to bypass User Account Control (UAC) by abusing an elevated COM Interface to launch a rogue Windows ClipUp program. Attackers may attempt to bypass UAC to stealthily execute code with elevated permissions. | update | 314 
+
+|<<prebuilt-rule-8-19-24-uac-bypass-via-icmluautil-elevated-com-interface, UAC Bypass via ICMLuaUtil Elevated COM Interface>> | Identifies User Account Control (UAC) bypass attempts via the ICMLuaUtil Elevated COM interface. Attackers may attempt to bypass UAC to stealthily execute code with elevated permissions. | update | 215 
+
+|<<prebuilt-rule-8-19-24-bypass-uac-via-event-viewer, Bypass UAC via Event Viewer>> | Identifies User Account Control (UAC) bypass via eventvwr.exe. Attackers bypass UAC to stealthily execute code with elevated permissions. | update | 323 
+
+|<<prebuilt-rule-8-19-24-uac-bypass-attempt-via-windows-directory-masquerading, UAC Bypass Attempt via Windows Directory Masquerading>> | Identifies an attempt to bypass User Account Control (UAC) by masquerading as a Microsoft trusted Windows directory. Attackers may bypass UAC to stealthily execute code with elevated permissions. | update | 323 
+
+|<<prebuilt-rule-8-19-24-privileges-elevation-via-parent-process-pid-spoofing, Privileges Elevation via Parent Process PID Spoofing>> | Identifies parent process spoofing used to create an elevated child process. Adversaries may spoof the parent process identifier (PPID) of a new process to evade process-monitoring defenses or to elevate privileges. | update | 12 
+
+|<<prebuilt-rule-8-19-24-privilege-escalation-via-rogue-named-pipe-impersonation, Privilege Escalation via Rogue Named Pipe Impersonation>> | Identifies a privilege escalation attempt via rogue named pipe impersonation. An adversary may abuse this technique by masquerading as a known named pipe and manipulating a privileged process to connect to it. | update | 212 
+
+|<<prebuilt-rule-8-19-24-process-created-with-an-elevated-token, Process Created with an Elevated Token>> | Identifies the creation of a process running as SYSTEM while impersonating the token context of a Windows core binary. Adversaries may create a new process with a different token to escalate privileges and bypass access controls. | update | 12 
+
+|<<prebuilt-rule-8-19-24-windows-service-installed-via-an-unusual-client, Windows Service Installed via an Unusual Client>> | Identifies the creation of a Windows service by an unusual client process. Services may be created with administrator privileges but are executed under SYSTEM privileges, so an adversary may also use a service to escalate privileges from administrator to SYSTEM. | update | 218 
+
+|==============================================
diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc
index ac3317049c..3261717478 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
 
 
+|<<prebuilt-rule-8-19-24-prebuilt-rules-8-19-24-summary, 8.19.24>> | 19 May 2026 | 33 | 102 | 
+This release includes new rules for Linux, AWS, Kubernetes, Microsoft 365, Google Workspace, and Network Packet Capture. New rules for Linux include detection for privilege escalation, lateral movement, execution, credential access, persistence, and discovery. New rules for AWS include detection for defense evasion, persistence, and privilege escalation. New rules for Kubernetes include detection for persistence, privilege escalation, credential access, execution, and impact. New rules for Microsoft 365 include detection for initial access, persistence, and discovery. New rules for Google Workspace include detection for persistence. New rules for Network Packet Capture include detection for initial access. Additionally, significant tuning for Linux, Windows, Kubernetes, macOS, and Microsoft 365 rules improves efficacy and performance.
+
+
 |<<prebuilt-rule-8-19-23-prebuilt-rules-8-19-23-summary, 8.19.23>> | 05 May 2026 | 27 | 377 | 
 This release includes new rules for Linux, AWS, Windows and Kubernetes. New rules for Linux include detection for privilege escalation, execution and credential access. New rules for Windows include detection for execution and credential access. New rules for AWS include detection for privilege execution, discovery, persistence, lateral movement and execution. New rules for Kubernetes include detection for discovery, privilege escalation, execution and credential access. Additionally, significant tuning for Linux, Windows, Kubernetes, AWS and MacOS rules improves efficacy and performance.
 
@@ -128,3 +132,4 @@ include::downloadable-packages/8-19-20/prebuilt-rules-8-19-20-summary.asciidoc[l
 include::downloadable-packages/8-19-21/prebuilt-rules-8-19-21-summary.asciidoc[leveloffset=+1]
 include::downloadable-packages/8-19-22/prebuilt-rules-8-19-22-summary.asciidoc[leveloffset=+1]
 include::downloadable-packages/8-19-23/prebuilt-rules-8-19-23-summary.asciidoc[leveloffset=+1]
+include::downloadable-packages/8-19-24/prebuilt-rules-8-19-24-summary.asciidoc[leveloffset=+1]
diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc
index 1f7dc92ecf..50aaef2b20 100644
--- a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc
+++ b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc
@@ -120,6 +120,12 @@ and their rule type is `machine_learning`.
 
 |<<aws-efs-file-system-deleted, AWS EFS File System Deleted>> |Identifies the deletion of an Amazon EFS file system using the "DeleteFileSystem" API operation. Deleting an EFS file system permanently removes all stored data and cannot be reversed. This action is rare in most environments and typically limited to controlled teardown workflows. Adversaries with sufficient permissions may delete a file system to destroy evidence, disrupt workloads, or impede recovery efforts. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EFS], [Tactic: Impact], [Resources: Investigation Guide] |None |212
 
+|<<aws-eks-access-entry-granted-cluster-admin-policy, AWS EKS Access Entry Granted Cluster Admin Policy>> |Detects when the AmazonEKSClusterAdminPolicy or AmazonEKSAdminPolicy is associated with a principal via the EKS Access Entries API. This grants full cluster-admin equivalent access to the specified IAM user or role. Unlike the legacy aws-auth ConfigMap which is only visible in Kubernetes audit logs, Access Entries modifications appear in CloudTrail, providing an additional detection surface. Attackers who have obtained IAM permissions to manage EKS access entries can use this API to backdoor cluster access for persistence, mapping attacker-controlled IAM identities to cluster-admin privileges without modifying any Kubernetes resources. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |1
+
+|<<aws-eks-access-entry-modified, AWS EKS Access Entry Modified>> |Detects successful Amazon EKS Access Entries API operations that create, update, attach, detach, or delete authentication mappings between IAM principals and the cluster. Changes to access entries alter who can authenticate to Kubernetes and what Kubernetes-level permissions they receive, without requiring edits to in-cluster RBAC objects. Unexpected callers or timing may indicate persistence or privilege abuse. Common automation identities (service-linked roles, eksctl, Terraform, CloudFormation role patterns) are excluded to reduce noise; tune further for your deployment pipelines. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1
+
+|<<aws-eks-control-plane-logging-disabled, AWS EKS Control Plane Logging Disabled>> |Detects successful Amazon EKS UpdateClusterConfig requests that disable control plane logging. Disabling EKS API server and control plane logs can reduce visibility into cluster activity and may indicate defense evasion following compromised AWS credentials or unauthorized administrative access. EKS control plane logging changes are typically rare and should align with approved maintenance or cost optimization workflows. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1
+
 |<<aws-eventbridge-rule-disabled-or-deleted, AWS EventBridge Rule Disabled or Deleted>> |Identifies when an Amazon EventBridge rule is disabled or deleted. EventBridge rules are commonly used to automate operational workflows and security-relevant routing (for example, forwarding events to Lambda, SNS/SQS, or security tooling). Disabling or deleting a rule can break critical integrations, suppress detections, and reduce visibility. Adversaries may intentionally impair EventBridge rules to disrupt monitoring, delay response, or hide follow-on actions. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EventBridge], [Tactic: Impact], [Resources: Investigation Guide] |None |213
 
 |<<aws-first-occurrence-of-sts-getfederationtoken-request-by-user, AWS First Occurrence of STS GetFederationToken Request by User>> |Identifies the first occurrence of an AWS Security Token Service (STS) GetFederationToken request made by a user. The GetFederationToken API call allows users to request temporary security credentials to access AWS resources. The maximum expiration period for these tokens is 36 hours and they can be used to create a console signin token even for identities that don't already have one. Adversaries may use this API to obtain temporary credentials for persistence and to bypass IAM API call limitations by gaining console access. |[Domain: Cloud], [Data Source: Amazon Web Services], [Data Source: AWS], [Data Source: AWS STS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Resources: Investigation Guide] |None |7
@@ -256,7 +262,7 @@ and their rule type is `machine_learning`.
 
 |<<aws-ssm-inventory-reconnaissance-by-rare-user, AWS SSM Inventory Reconnaissance by Rare User>> |Detects the rare occurrence of a user or role accessing AWS Systems Manager (SSM) inventory APIs or running the AWS-GatherSoftwareInventory job. These APIs reveal detailed information about managed EC2 instances including installed software, patch compliance status, and command execution history. Adversaries may use these calls to collect software inventory while blending in with legitimate AWS operations. This is a New Terms rule that detects when a user accesses these reconnaissance APIs for the first time. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SSM], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |3
 
-|<<aws-ssm-session-manager-child-process-execution, AWS SSM Session Manager Child Process Execution>> |Identifies process start events where the parent process is the AWS Systems Manager (SSM) Session Manager worker. Session Manager provides interactive shell access to EC2 instances and hybrid nodes without bastion hosts or open inbound ports. Adversaries abuse it for remote execution and lateral movement using legitimate AWS credentials and IAM permissions. This rule surfaces endpoint execution occurring under that worker for visibility and hunting. Expect noise from authorized administrative sessions. |[Domain: Endpoint], [Domain: Cloud], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |1
+|<<aws-ssm-session-manager-child-process-execution, AWS SSM Session Manager Child Process Execution>> |Identifies process start events where the parent process is the AWS Systems Manager (SSM) Session Manager worker. Session Manager provides interactive shell access to EC2 instances and hybrid nodes without bastion hosts or open inbound ports. Adversaries abuse it for remote execution and lateral movement using legitimate AWS credentials and IAM permissions. This rule surfaces endpoint execution occurring under that worker for visibility and hunting. Expect noise from authorized administrative sessions. |[Domain: Endpoint], [Domain: Cloud], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |2
 
 |<<aws-ssm-session-started-to-ec2-instance, AWS SSM Session Started to EC2 Instance>> |Identifies the first occurrence of an AWS user or role establishing a session via SSM to an EC2 instance. Adversaries may use AWS Session Manager to establish a session to an EC2 instance to execute commands on the instance. This can be used to gain access to the instance and perform actions such as privilege escalation. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SSM], [Data Source: AWS EC2], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |6
 
@@ -332,9 +338,9 @@ and their rule type is `machine_learning`.
 
 |<<adding-hidden-file-attribute-via-attrib, Adding Hidden File Attribute via Attrib>> |Adversaries can add the 'hidden' attribute to files to hide them from the user in an attempt to evade detection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |321
 
-|<<adminsdholder-backdoor, AdminSDHolder Backdoor>> |Detects modifications in the AdminSDHolder object. Attackers can abuse the SDProp process to implement a persistent backdoor in Active Directory. SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, regaining their Administrative Privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |215
+|<<adminsdholder-backdoor, AdminSDHolder Backdoor>> |Detects modifications in the AdminSDHolder object. Attackers can abuse the SDProp process to implement a persistent backdoor in Active Directory. SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, regaining their Administrative Privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |216
 
-|<<adminsdholder-sdprop-exclusion-added, AdminSDHolder SDProp Exclusion Added>> |Identifies a modification on the dsHeuristics attribute on the bit that holds the configuration of groups excluded from the SDProp process. The SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, meaning that groups excluded will remain unchanged. Attackers can abuse this misconfiguration to maintain long-term access to privileged accounts in these groups. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Active Directory], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs] |None |218
+|<<adminsdholder-sdprop-exclusion-added, AdminSDHolder SDProp Exclusion Added>> |Identifies a modification on the dsHeuristics attribute on the bit that holds the configuration of groups excluded from the SDProp process. The SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, meaning that groups excluded will remain unchanged. Attackers can abuse this misconfiguration to maintain long-term access to privileged accounts in these groups. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Active Directory], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs] |None |219
 
 |<<administrator-privileges-assigned-to-an-okta-group, Administrator Privileges Assigned to an Okta Group>> |Detects when an administrator role is assigned to an Okta group. An adversary may attempt to assign administrator privileges to an Okta group in order to assign additional permissions to compromised user accounts and maintain access to their target organization. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Persistence], [Resources: Investigation Guide] |None |414
 
@@ -550,7 +556,7 @@ and their rule type is `machine_learning`.
 
 |<<browser-process-spawned-from-an-unusual-parent, Browser Process Spawned from an Unusual Parent>> |Identifies instances where a browser is launched with remote debugging, headless automation, or minimal arguments from an unusual parent process. This may indicate an attempt to broker or tamper with a browser session for credential theft. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |4
 
-|<<bypass-uac-via-event-viewer, Bypass UAC via Event Viewer>> |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], [Tactic: Defense Evasion], [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 |322
+|<<bypass-uac-via-event-viewer, Bypass UAC via Event Viewer>> |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
 
 |<<chkconfig-service-add, Chkconfig Service Add>> |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
 
@@ -560,7 +566,7 @@ and their rule type is `machine_learning`.
 
 |<<clearing-windows-event-logs, Clearing Windows Event Logs>> |Identifies attempts to clear or disable Windows event log stores using Windows wevetutil command. This is often done by attackers in an attempt to evade detection or destroy forensic evidence on a system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |322
 
-|<<cobalt-strike-command-and-control-beacon, Cobalt Strike Command and Control Beacon>> |Cobalt Strike is a threat emulation platform commonly modified and used by adversaries to conduct network attack and exploitation campaigns. This rule detects a network activity algorithm leveraged by Cobalt Strike implant beacons for command and control. |[Use Case: Threat Detection], [Tactic: Command and Control], [Domain: Endpoint], [Resources: Investigation Guide] |None |108
+|<<cobalt-strike-command-and-control-beacon, Cobalt Strike Command and Control Beacon>> |Cobalt Strike is a threat emulation platform commonly modified and used by adversaries to conduct network attack and exploitation campaigns. This rule detects a network activity algorithm leveraged by Cobalt Strike implant beacons for command and control. |[Use Case: Threat Detection], [Tactic: Command and Control], [Domain: Endpoint], [Resources: Investigation Guide] |None |109
 
 |<<code-signing-policy-modification-through-built-in-tools, Code Signing Policy Modification Through Built-in tools>> |Identifies attempts to disable/modify the code signing policy through system native utilities. Code signing provides authenticity on a program, and grants the user with the ability to check whether the program has been tampered with. By allowing the execution of unsigned or self-signed code, threat actors can craft and execute malicious code. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |216
 
@@ -576,13 +582,13 @@ and their rule type is `machine_learning`.
 
 |<<command-shell-activity-started-via-rundll32, Command Shell Activity Started via RunDLL32>> |Identifies command shell activity started via RunDLL32, which is commonly abused by attackers to host malicious code. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Credential Access], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |315
 
-|<<command-and-scripting-interpreter-via-windows-scripts, Command and Scripting Interpreter via Windows Scripts>> |Identifies PowerShell.exe or Cmd.exe execution spawning from Windows Script Host processes Wscript.exe. |[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 |210
+|<<command-and-scripting-interpreter-via-windows-scripts, Command and Scripting Interpreter via Windows Scripts>> |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
 
 |<<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. |[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
 
 |<<compression-dll-loaded-by-unusual-process, Compression DLL Loaded by Unusual Process>> |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
 
-|<<conhost-spawned-by-suspicious-parent-process, Conhost Spawned By Suspicious Parent Process>> |Detects when the Console Window Host (conhost.exe) process is spawned by a suspicious parent process, which could be indicative of code injection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Defense Evasion], [Tactic: Privilege Escalation], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne] |None |313
+|<<conhost-spawned-by-suspicious-parent-process, Conhost Spawned By Suspicious Parent Process>> |Detects when the Console Window Host (conhost.exe) process is spawned by a suspicious parent process, which could be indicative of code injection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne] |None |314
 
 |<<connection-to-common-large-language-model-endpoints, Connection to Common Large Language Model Endpoints>> |Identifies DNS queries to known Large Language Model domains by unsigned binaries or common Windows scripting utilities. Malwares may leverage the capabilities of LLM to perform actions in the affected system in a dynamic way. |[Domain: Endpoint], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Sysmon] |None |6
 
@@ -596,6 +602,8 @@ and their rule type is `machine_learning`.
 
 |<<container-management-utility-run-inside-a-container, Container Management Utility Run Inside A Container>> |This rule detects when a container management binary is run from inside a container. These binaries are critical components of many containerized environments, and their presence and execution in unauthorized containers could indicate compromise or a misconfiguration. |[Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |5
 
+|<<container-runtime-cli-execution-with-suspicious-arguments, Container Runtime CLI Execution with Suspicious Arguments>> |Detects execution of container runtime CLI tools (ctr, crictl, nerdctl) with arguments indicating container creation, command execution inside existing containers, image manipulation, or host filesystem mounting. These tools interact directly with the container runtime socket, bypassing the Kubernetes API server, RBAC authorization, admission webhooks, pod security standards, and Kubernetes audit logging entirely. Attackers with host-level access may use these tools to create privileged ghost containers, exec into other pods to steal service account tokens and secrets, pull attacker-controlled images, and destroy evidence, all while remaining invisible to Kubernetes-level monitoring. |[Data Source: Auditd Manager], [Data Source: Elastic Defend], [Domain: Container], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |1
+
 |<<control-panel-process-with-unusual-arguments, Control Panel Process with Unusual Arguments>> |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
 
 |<<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. |[Domain: Identity], [Domain: LLM], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Rule Type: Higher-Order Rule] |None |3
@@ -612,7 +620,7 @@ and their rule type is `machine_learning`.
 
 |<<creation-of-a-dns-named-record, Creation of a DNS-Named Record>> |Active Directory Integrated DNS (ADIDNS) is one of the core components of AD DS, leveraging AD's access control and replication to maintain domain consistency. It stores DNS zones as AD objects, a feature that, while robust, introduces some security issues because of the default permission (Any authenticated users) to create DNS-named records. Attackers can perform Dynamic Spoofing attacks, where they monitor LLMNR/NBT-NS requests and create DNS-named records to target systems that are requested from multiple systems. They can also create specific records to target specific services, such as wpad, for spoofing attacks. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |109
 
-|<<creation-of-a-hidden-local-user-account, Creation of a Hidden Local User Account>> |Identifies the creation of a hidden local user account by appending the dollar sign to the account name. This is sometimes done by attackers to increase access to a system and avoid appearing in the results of accounts listing using the net users command. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |316
+|<<creation-of-a-hidden-local-user-account, Creation of a Hidden Local User Account>> |Identifies the creation of a hidden local user account by appending the dollar sign to the account name. This is sometimes done by attackers to increase access to a system and avoid appearing in the results of accounts listing using the net users command. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |317
 
 |<<creation-or-modification-of-domain-backup-dpapi-private-key, Creation or Modification of Domain Backup DPAPI private key>> |Identifies the creation or modification of Domain Backup private keys. Adversaries may extract the Data Protection API (DPAPI) domain backup key from a Domain Controller (DC) to be able to decrypt any domain user master key file. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |418
 
@@ -644,7 +652,7 @@ and their rule type is `machine_learning`.
 
 |<<curl-or-wget-egress-network-connection-via-lolbin, Curl or Wget Egress Network Connection via LoLBin>> |This rule detects the execution of curl or wget binaries through a GTFOBin (living-off-the-land) technique in Linux environments. Attackers may exploit these utilities to download and execute malicious files from the internet while attempting to evade detection. The rule specifically targets binaries that are capable of executing shell commands directly from the proxied binary, rather than just spawning a shell. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Tactic: Command and Control], [Tactic: Exfiltration], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2
 
-|<<curl-or-wget-execution-from-container-context, Curl or Wget Execution from Container Context>> |Detects execution of curl or wget from processes whose title aligns with **`runc init`**, a common fingerprint for workloads running inside **OCI/runc-backed containers** on Linux hosts instrumented with Auditd Manager. After breaking out of an application container or abusing a privileged workload, attackers often pull ingress tooling (stagers, scripts, implants) or stage exfiltration with minimal HTTP clients. Those utilities are also used benignly in images, so context matters; the `runc init` anchor narrows the signal to the container runtime boundary where unexpected download clients are more worthy of review than the same binaries on a bare-metal admin shell. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Execution], [Domain: Containers], [Data Source: Auditd Manager], [Resources: Investigation Guide] |None |1
+|<<curl-or-wget-execution-from-container-context, Curl or Wget Execution from Container Context>> |Detects execution of curl or wget from processes whose title aligns with **`runc init`**, a common fingerprint for workloads running inside **OCI/runc-backed containers** on Linux hosts instrumented with Auditd Manager. After breaking out of an application container or abusing a privileged workload, attackers often pull ingress tooling (stagers, scripts, implants) or stage exfiltration with minimal HTTP clients. Those utilities are also used benignly in images, so context matters; the `runc init` anchor narrows the signal to the container runtime boundary where unexpected download clients are more worthy of review than the same binaries on a bare-metal admin shell. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Execution], [Domain: Containers], [Data Source: Auditd Manager], [Resources: Investigation Guide] |None |2
 
 |<<curl-or-wget-spawned-via-node-js, Curl or Wget Spawned via Node.js>> |This rule detects when Node.js, directly or via a shell, spawns the curl or wget command. This may indicate command and control behavior. Adversaries may use Node.js to download additional tools or payloads onto the system. |[Domain: Endpoint], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Windows Security Event Logs], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Data Source: Auditd Manager] |None |6
 
@@ -658,7 +666,7 @@ and their rule type is `machine_learning`.
 
 |<<dns-global-query-block-list-modified-or-disabled, DNS Global Query Block List Modified or Disabled>> |Identifies changes to the DNS Global Query Block List (GQBL), a security feature that prevents the resolution of certain DNS names often exploited in attacks like WPAD spoofing. Attackers with certain privileges, such as DNSAdmins, can modify or disable the GQBL, allowing exploitation of hosts running WPAD with default settings for privilege escalation and lateral movement. |[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], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |211
 
-|<<dns-request-for-ip-lookup-service-via-unsigned-binary, DNS Request for IP Lookup Service via Unsigned Binary>> |Detects when a DNS request is made for an IP lookup service to determine the external IP address of the system via an unsigned or untrusted binary. This is commonly used by malware for reconnaissance before establishing C2 connections. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1
+|<<dns-request-for-ip-lookup-service-via-unsigned-binary, DNS Request for IP Lookup Service via Unsigned Binary>> |Detects when a DNS request is made for an IP lookup service to determine the external IP address of the system via an unsigned or untrusted binary. This is commonly used by malware for reconnaissance before establishing C2 connections. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2
 
 |<<dns-tunneling, DNS Tunneling>> |A machine learning job detected unusually large numbers of DNS queries for a single top-level DNS domain, which is often used for DNS tunneling. DNS tunneling can be used for command-and-control, persistence, or data exfiltration activity. For example, dnscat tends to generate many DNS questions for a top-level domain as it uses the DNS protocol to tunnel data. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Command and Control], [Resources: Investigation Guide] |None |108
 
@@ -674,7 +682,7 @@ and their rule type is `machine_learning`.
 
 |<<delayed-execution-via-ping, Delayed Execution via Ping>> |Identifies the execution of commonly abused Windows utilities via a delayed Ping execution. This behavior is often observed during malware installation and is consistent with an attacker attempting to evade detection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |9
 
-|<<delegated-managed-service-account-modification-by-an-unusual-user, Delegated Managed Service Account Modification by an Unusual User>> |Detects modifications in the msDS-ManagedAccountPrecededByLink attribute of a delegated managed service account by an unusual subject account. Attackers can abuse this attribute to take over the permission of a target account and inherit it's permissions allowing them to further elevate privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |3
+|<<delegated-managed-service-account-modification-by-an-unusual-user, Delegated Managed Service Account Modification by an Unusual User>> |Detects modifications to the msDS-ManagedAccountPrecededByLink attribute of a delegated managed service account by an unusual subject account. Attackers can abuse this attribute to inherit a target account's permissions and further elevate privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |4
 
 |<<delete-volume-usn-journal-with-fsutil, Delete Volume USN Journal with Fsutil>> |Identifies use of the fsutil.exe to delete the volume USNJRNL. This technique is used by attackers to eliminate evidence of files created during post-exploitation activities. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |316
 
@@ -760,6 +768,8 @@ and their rule type is `machine_learning`.
 
 |<<dynamic-linker-creation, Dynamic Linker Creation>> |Detects the creation of files related to the configuration of the dynamic linker on Linux systems. The dynamic linker is a shared library that is used by the Linux kernel to load and execute programs. Attackers may attempt to hijack the execution flow of a program by modifying the dynamic linker configuration files. This technique is often observed by userland rootkits that leverage shared objects to maintain persistence on a compromised host. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |9
 
+|<<eks-authentication-configuration-modified, EKS Authentication Configuration Modified>> |Detects modifications to the aws-auth ConfigMap in Amazon EKS clusters. The aws-auth ConfigMap maps AWS IAM roles and users to Kubernetes RBAC groups, an attacker who modifies it can grant any IAM role cluster-admin access by adding a mapping to the system:masters group. This is a well-documented persistence technique that survives pod restarts, node replacements, and RBAC changes because the authentication mapping exists outside of normal Kubernetes Role objects. Modifications to aws-auth are rare in normal operations, the ConfigMap is typically set during cluster provisioning and updated only during node group or access configuration changes. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1
+
 |<<esxi-discovery-via-find, ESXI Discovery via Find>> |Identifies instances where the 'find' command is started on a Linux system with arguments targeting specific VM-related paths, such as "/etc/vmware/", "/usr/lib/vmware/", or "/vmfs/*". These paths are associated with VMware virtualization software, and their presence in the find command arguments may indicate that a threat actor is attempting to search for, analyze, or manipulate VM-related files and configurations on the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |113
 
 |<<esxi-discovery-via-grep, ESXI Discovery via Grep>> |Identifies instances where a process named 'grep', 'egrep', or 'pgrep' is started on a Linux system with arguments related to virtual machine (VM) files, such as "vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", or "vmem". These file extensions are associated with VM-related file formats, and their presence in grep command arguments may indicate that a threat actor is attempting to search for, analyze, or manipulate VM files on the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |113
@@ -822,6 +832,8 @@ and their rule type is `machine_learning`.
 
 |<<entra-id-mfa-totp-brute-force-attempted, Entra ID MFA TOTP Brute Force Attempted>> |Identifies brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. This rule detects high frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attemopt to brute-force TOTP codes by generating several sessions and attempt to guess the correct code. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |9
 
+|<<entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource, Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource>> |Detects successful Microsoft Entra ID sign-ins where the client application is the Microsoft Authentication Broker (MAB) and the requested resource identifier is outside a short list of commonly observed first-party targets. Attackers abuse the broker in phishing and token broker flows to obtain tokens for unexpected APIs or enterprise applications. The exclusion list covers legacy Azure Active Directory, Microsoft Graph, Device Registration Service, Microsoft Intune Enrollment, extend or tune exclusions for your tenant after baselining broker traffic. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |1
+
 |<<entra-id-oauth-authorization-code-grant-for-unusual-user-app-and-resource, Entra ID OAuth Authorization Code Grant for Unusual User, App, and Resource>> |Identifies the first occurrence of an OAuth 2.0 authorization code grant flow for a specific combination of client application, target resource, and user principal in Microsoft Entra ID. Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing Microsoft Graph or legacy Azure AD are flagged for infrequent or first time usage by a user. Additionally, any FOCI (Family of Client IDs) application accessing the deprecated Windows Azure Active Directory for the first time is flagged since this resource is rarely accessed legitimately. This pattern is indicative of OAuth phishing attacks like ConsentFix, where attackers steal authorization codes and exchange them for tokens from attacker controlled infrastructure. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |4
 
 |<<entra-id-oauth-device-code-flow-with-concurrent-sign-ins, Entra ID OAuth Device Code Flow with Concurrent Sign-ins>> |Identifies Entra ID device code authentication flows where multiple user agents are observed within the same session. This pattern is indicative of device code phishing, where an attacker's polling client (e.g., Python script) and the victim's browser both appear in the same authentication session. In legitimate device code flows, the user authenticates via browser while the requesting application polls for tokens - when these have distinctly different user agents (e.g., Python Requests vs Chrome), it may indicate the code was phished and redeemed by an attacker. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |6
@@ -830,6 +842,8 @@ and their rule type is `machine_learning`.
 
 |<<entra-id-oauth-device-code-grant-by-unusual-user, Entra ID OAuth Device Code Grant by Unusual User>> |Identifies when a user is observed for the first time authenticating using the device code authentication workflow. This authentication workflow can be abused by attackers to phish users and steal access tokens to impersonate the victim. By its very nature, device code should only be used when logging in to devices without keyboards, where it is difficult to enter emails and passwords. This rule only applies to Entra ID user types and detects new users leveraging this flow. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |10
 
+|<<entra-id-oauth-device-code-phishing-via-aitm, Entra ID OAuth Device Code Phishing via AiTM>> |Detects successful Microsoft Entra ID sign-ins that use the OAuth device code authentication protocol with the Microsoft Authentication Broker client requesting first-party Office API resources (Exchange Online, Microsoft Graph, or SharePoint) while flagged as interactive. This pattern is associated with adversary-in-the-middle (AiTM) phishing kits such as Tycoon 2FA, where victims complete device code flows that ultimately broker tokens for mail and collaboration APIs. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Threat Detection], [Threat: Tycoon2FA], [Tactic: Initial Access], [Resources: Investigation Guide] |None |1
+
 |<<entra-id-oauth-flow-by-microsoft-authentication-broker-to-device-registration-service-drs, Entra ID OAuth Flow by Microsoft Authentication Broker to Device Registration Service (DRS)>> |Identifies separate OAuth authorization flows in Microsoft Entra ID where the same user principal and session ID are observed across multiple IP addresses within a 5-minute window. These flows involve the Microsoft Authentication Broker (MAB) as the client application and the Device Registration Service (DRS) as the target resource. This pattern is highly indicative of OAuth phishing activity, where an adversary crafts a legitimate Microsoft login URL to trick a user into completing authentication and sharing the resulting authorization code, which is then exchanged for an access and refresh token by the attacker. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Initial Access] |None |9
 
 |<<entra-id-oauth-prt-issuance-to-non-managed-device-detected, Entra ID OAuth PRT Issuance to Non-Managed Device Detected>> |Identifies when a user signs in with a refresh token using the Microsoft Authentication Broker (MAB) client, followed by a Primary Refresh Token (PRT) sign-in from the same device within 1 hour from an unmanaged device. This pattern may indicate that an attacker has successfully registered a device using ROADtx and transitioned from short-term token access to long-term persistent access via PRTs. Excluding access to the Device Registration Service (DRS) ensures the PRT is being used beyond registration, often to access Microsoft 365 resources like Outlook or SharePoint. |[Domain: Cloud], [Domain: Identity], [Use Case: Threat Detection], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Tactic: Persistence], [Tactic: Initial Access], [Resources: Investigation Guide] |None |5
@@ -842,6 +856,8 @@ and their rule type is `machine_learning`.
 
 |<<entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client, Entra ID OAuth user_impersonation Scope for Unusual User and Client>> |Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing user_impersonation for a token issued by Entra ID. Adversaries may use this scope to gain unauthorized access to user accounts, particularly when the sign-in session status is unbound, indicating that the session is not associated with a specific device or session. This behavior is indicative of potential account compromise or unauthorized access attempts. This rule flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity. |[Domain: Cloud], [Domain: Identity], [Use Case: Threat Detection], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Tactic: Initial Access], [Resources: Investigation Guide] |None |5
 
+|<<entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa, Entra ID Potential AiTM Sign-In via OfficeHome (Tycoon2FA)>> |Detects Microsoft Entra ID sign-ins consistent with Tycoon2FA phishing-as-a-service (PhaaS) adversary-in-the-middle (AiTM) activity: the Microsoft Authentication Broker requesting tokens for Microsoft Graph or Exchange Online, or the Office web client application authenticating to itself, combined with Node.js-style user agents (node, axios, undici). Tycoon 2FA bypasses MFA by relaying authentication and capturing session material, often targeting Microsoft 365 and Gmail. Baseline legitimate automation and developer tooling before tuning. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Threat Detection], [Threat: Tycoon2FA], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1
+
 |<<entra-id-powershell-sign-in, Entra ID PowerShell Sign-in>> |Identifies a sign-in using the Azure Active Directory PowerShell module. PowerShell for Azure Active Directory allows for managing settings from the command line, which is intended for users who are members of an admin role. |[Domain: Cloud], [Data Source: Azure], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access] |None |110
 
 |<<entra-id-privileged-identity-management-pim-role-modified, Entra ID Privileged Identity Management (PIM) Role Modified>> |Azure Active Directory (AD) Privileged Identity Management (PIM) is a service that enables you to manage, control, and monitor access to important resources in an organization. PIM can be used to manage the built-in Azure resource roles such as Global Administrator and Application Administrator. An adversary may add a user to a PIM role in order to maintain persistence in their target's environment or modify a PIM role to weaken their target's security controls. |[Domain: Cloud], [Data Source: Azure], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence] |None |111
@@ -858,6 +874,8 @@ and their rule type is `machine_learning`.
 
 |<<entra-id-protection-user-alert-and-device-registration, Entra ID Protection User Alert and Device Registration>> |Identifies sequence of events where a Microsoft Entra ID protection alert is followed by an attempt to register a new device by the same user principal. This behavior may indicate an adversary using a compromised account to register a device, potentially leading to unauthorized access to resources or persistence in the environment. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Protection Logs], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence] |None |4
 
+|<<entra-id-register-device-with-unusual-user-agent-azure-ad-join, Entra ID Register Device with Unusual User Agent (Azure AD Join)>> |Detects successful Microsoft Entra ID audit events for Register device where additional details indicate an Azure AD join and the recorded user agent is not one of the common native registration clients (Dsreg, DeviceRegistrationClient, or Dalvik-based Android enrollment). Legitimate Windows and standard mobile enrollment flows often present predictable user-agent strings; unexpected clients may reflect scripted registration, third-party tooling, or adversary-driven device registration used for persistence or token abuse. Baseline approved provisioning tools and MDM integrations before tuning. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |1
+
 |<<entra-id-service-principal-created, Entra ID Service Principal Created>> |Identifies when a new service principal is added in Microsoft Entra ID. An application, hosted service, or automated tool that accesses or modifies resources needs an identity created. This identity is known as a service principal. For security reasons, it's always recommended to use service principals with automated tools rather than allowing them to log in with a user identity. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence] |None |110
 
 |<<entra-id-service-principal-credentials-created-by-unusual-user, Entra ID Service Principal Credentials Created by Unusual User>> |Identifies when new Service Principal credentials have been added in Microsoft Entra ID. In most organizations, credentials will be added to service principals infrequently. Hijacking an application (by adding a rogue secret or certificate) with granted permissions will allow the attacker to access data that is normally protected by MFA requirements. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |110
@@ -924,7 +942,7 @@ and their rule type is `machine_learning`.
 
 |<<execution-of-com-object-via-xwizard, Execution of COM object via Xwizard>> |Windows Component Object Model (COM) is an inter-process communication (IPC) component of the native Windows application programming interface (API) that enables interaction between software objects or executable code. Xwizard can be used to run a COM object created in registry to evade defensive counter measures. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |320
 
-|<<execution-of-file-written-or-modified-by-microsoft-office, Execution of File Written or Modified by Microsoft Office>> |Identifies an executable created by a Microsoft Office application and subsequently executed. These processes are often launched via scripts inside documents or during exploitation of Microsoft Office applications. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend] |None |114
+|<<execution-of-file-written-or-modified-by-microsoft-office, Execution of File Written or Modified by Microsoft Office>> |Identifies an executable created by a Microsoft Office application and subsequently executed. These processes are often launched via scripts inside documents or during exploitation of Microsoft Office applications. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend] |None |115
 
 |<<execution-of-persistent-suspicious-program, Execution of Persistent Suspicious Program>> |Identifies execution of suspicious persistent programs (scripts, rundll32, etc.) by looking at process lineage and command line usage. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |212
 
@@ -944,7 +962,7 @@ and their rule type is `machine_learning`.
 
 |<<execution-via-openclaw-agent, Execution via OpenClaw Agent>> |Detects suspicious child process execution from the OpenClaw, Moltbot, or Clawdbot AI coding agents running via Node.js. These tools can execute arbitrary shell commands through skills or prompt injection attacks. Malicious skills from public registries like ClawHub have been observed executing obfuscated download-and-execute commands targeting cryptocurrency wallets and credentials. This rule identifies shells, scripting interpreters, and common LOLBins spawned by these AI agents. |[Domain: Endpoint], [Domain: LLM], [OS: Linux], [OS: macOS], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |4
 
-|<<execution-via-tsclient-mountpoint, Execution via TSClient Mountpoint>> |Identifies execution from the Remote Desktop Protocol (RDP) shared mountpoint tsclient on the target host. This may indicate a lateral movement attempt. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [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
+|<<execution-via-tsclient-mountpoint, Execution via TSClient Mountpoint>> |Identifies execution from the Remote Desktop Protocol (RDP) shared mountpoint tsclient on the target host. This may indicate a lateral movement attempt. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [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 |320
 
 |<<execution-via-windows-command-debugging-utility, Execution via Windows Command Debugging Utility>> |An adversary can use the Windows command line debugging utility cdb.exe to execute commands or shellcode. This rule looks for those instances and where the cdb.exe binary is outside of the normal WindowsKit installation paths. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |111
 
@@ -976,7 +994,7 @@ and their rule type is `machine_learning`.
 
 |<<file-creation-in-var-log-via-suspicious-process, File Creation in /var/log via Suspicious Process>> |This rule detects the creation of files in the /var/log/ directory via process executables located in world-writeable locations or via hidden processes. Attackers may attempt to hide their activities by creating files in the /var/log/ directory, which is commonly used for logging system events. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Tactic: Persistence], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |5
 
-|<<file-creation-in-world-writable-directory-by-unusual-process, File Creation in World-Writable Directory by Unusual Process>> |This rule detects the creation of files in world-writable directories by an unusual process. Attackers may attempt to hide their activities by creating files in world-writable directories, which are commonly used for temporary file storage. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |1
+|<<file-creation-in-world-writable-directory-by-unusual-process, File Creation in World-Writable Directory by Unusual Process>> |This rule detects the creation of files in world-writable directories by an unusual process. Attackers may attempt to hide their activities by creating files in world-writable directories, which are commonly used for temporary file storage. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |2
 
 |<<file-creation-execution-and-self-deletion-in-suspicious-directory, File Creation, Execution and Self-Deletion in Suspicious Directory>> |This rule monitors for the creation of a file, followed by its execution and self-deletion in a short timespan within a directory often used for malicious purposes by threat actors. This behavior is often used by malware to execute malicious code and delete itself to hide its tracks. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |11
 
@@ -1002,7 +1020,7 @@ and their rule type is `machine_learning`.
 
 |<<file-with-suspicious-extension-downloaded, File with Suspicious Extension Downloaded>> |Identifies unusual files downloaded from outside the local network that have the potential to be abused for code execution. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Rule Type: BBR] |None |6
 
-|<<finder-sync-plugin-registered-and-enabled, Finder Sync Plugin Registered and Enabled>> |Finder Sync plugins enable users to extend Finder’s functionality by modifying the user interface. Adversaries may abuse this feature by adding a rogue Finder Plugin to repeatedly execute malicious payloads for persistence. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |211
+|<<finder-sync-plugin-registered-and-enabled, Finder Sync Plugin Registered and Enabled>> |Finder Sync plugins enable users to extend Finder’s functionality by modifying the user interface. Adversaries may abuse this feature by adding a rogue Finder Plugin to repeatedly execute malicious payloads for persistence. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |212
 
 |<<first-occurrence-github-event-for-a-personal-access-token-pat, First Occurrence GitHub Event for a Personal Access Token (PAT)>> |Detects a first occurrence event for a personal access token (PAT) not seen in the last 14 days. |[Domain: Cloud], [Use Case: Threat Detection], [Use Case: UEBA], [Tactic: Execution], [Rule Type: BBR], [Data Source: Github] |None |208
 
@@ -1048,7 +1066,7 @@ and their rule type is `machine_learning`.
 
 |<<first-time-seen-removable-device, First Time Seen Removable Device>> |Identifies newly seen removable devices by device friendly name using registry modification events. While this activity is not inherently malicious, analysts can use those events to aid monitoring for data exfiltration over those devices. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Exfiltration], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |214
 
-|<<first-time-fortigate-administrator-login, First-Time FortiGate Administrator Login>> |This rule detects the first observed successful login of a user with the Administrator role to the FortiGate management interface within the last 5 days. First-time administrator logins can indicate newly provisioned accounts, misconfigurations, or unauthorized access using valid credentials and should be reviewed promptly. |[Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide], [Domain: Network], [Domain: Identity], [Data Source: Fortinet], [Data Source: Fortinet FortiGate] |None |3
+|<<first-time-fortigate-administrator-login, First-Time FortiGate Administrator Login>> |This rule detects the first observed successful login of a user with the Administrator role to the FortiGate management interface within the last 5 days. First-time administrator logins can indicate newly provisioned accounts, misconfigurations, or unauthorized access using valid credentials and should be reviewed promptly. |[Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide], [Domain: Network], [Domain: Identity], [Data Source: Fortinet], [Data Source: Fortinet FortiGate] |None |5
 
 |<<fortigate-administrator-account-creation-from-unusual-source, FortiGate Administrator Account Creation from Unusual Source>> |This rule detects FortiGate administrator account creation from a source IP address not previously seen performing admin operations on the device. Threat actors exploiting CVE-2026-24858 (FG-IR-26-060) authenticate via FortiCloud SSO bypass and immediately create local administrator accounts for persistence, typically from infrastructure not associated with normal administrative activity. |[Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Domain: Network], [Domain: Identity], [Data Source: Fortinet], [Data Source: Fortinet FortiGate] |None |2
 
@@ -1162,7 +1180,7 @@ and their rule type is `machine_learning`.
 
 |<<github-pat-access-revoked, GitHub PAT Access Revoked>> |Access to private GitHub organization resources was revoked for a PAT. |[Domain: Cloud], [Use Case: Threat Detection], [Use Case: UEBA], [Tactic: Impact], [Rule Type: BBR], [Data Source: Github] |None |206
 
-|<<github-private-repository-turned-public, GitHub Private Repository Turned Public>> |Detects when a private GitHub repository is changed to public visibility. Adversaries may change repository visibility to public in order to exfiltrate sensitive code or data, potentially indicating a compromise or unauthorized access. |[Domain: Cloud], [Use Case: Threat Detection], [Tactic: Exfiltration], [Tactic: Impact], [Data Source: Github], [Resources: Investigation Guide] |None |2
+|<<github-private-repository-turned-public, GitHub Private Repository Turned Public>> |Detects when a private GitHub repository is changed to public visibility. Adversaries may change repository visibility to public in order to exfiltrate sensitive code or data, potentially indicating a compromise or unauthorized access. |[Domain: Cloud], [Use Case: Threat Detection], [Tactic: Exfiltration], [Tactic: Impact], [Data Source: Github], [Resources: Investigation Guide] |None |3
 
 |<<github-protected-branch-settings-changed, GitHub Protected Branch Settings Changed>> |This rule detects setting modifications for protected branches of a GitHub repository. Branch protection rules can be used to enforce certain workflows or requirements before a contributor can push changes to a branch in your repository. Changes to these protected branch settings should be investigated and verified as legitimate activity. Unauthorized changes could be used to lower your organization's security posture and leave you exposed for future attacks. |[Domain: Cloud], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Github], [Resources: Investigation Guide] |None |210
 
@@ -1198,6 +1216,8 @@ and their rule type is `machine_learning`.
 
 |<<google-workspace-custom-gmail-route-created-or-modified, Google Workspace Custom Gmail Route Created or Modified>> |Detects when a custom Gmail route is added or modified in Google Workspace. Adversaries can add a custom e-mail route for outbound mail to route these e-mails to their own inbox of choice for data gathering. This allows adversaries to capture sensitive information from e-mail and potential attachments, such as invoices or payment documents. By default, all email from current Google Workspace users with accounts are routed through a domain's mail server for inbound and outbound mail. |[Domain: Cloud], [Data Source: Google Workspace], [Tactic: Collection], [Resources: Investigation Guide] |None |110
 
+|<<google-workspace-device-registration-after-oauth-from-suspicious-asn, Google Workspace Device Registration After OAuth from Suspicious ASN>> |Detects when a Google Workspace account completes OAuth authorization for a specific Google OAuth client from a high-risk autonomous system number (ASN), followed within 30 seconds by a device registration event with account state REGISTERED. This sequence can indicate device enrollment or join flows initiated from attacker-controlled or residential-proxy infrastructure after a user authorizes a sensitive client. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Initial Access], [Threat: Tycoon2FA], [Resources: Investigation Guide] |None |1
+
 |<<google-workspace-drive-encryption-key-s-accessed-from-anonymous-user, Google Workspace Drive Encryption Key(s) Accessed from Anonymous User>> |Detects when an external (anonymous) user has viewed, copied or downloaded an encryption key file from a Google Workspace drive. Adversaries may gain access to encryption keys stored in private drives from rogue access links that do not have an expiration. Access to encryption keys may allow adversaries to access sensitive data or authenticate on behalf of users. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |9
 
 |<<google-workspace-mfa-enforcement-disabled, Google Workspace MFA Enforcement Disabled>> |Detects when multi-factor authentication (MFA) enforcement is disabled for Google Workspace users. An adversary may disable MFA enforcement in order to weaken an organization’s security controls. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Impact], [Resources: Investigation Guide] |None |212
@@ -1214,7 +1234,7 @@ and their rule type is `machine_learning`.
 
 |<<google-workspace-user-organizational-unit-changed, Google Workspace User Organizational Unit Changed>> |Users in Google Workspace are typically assigned a specific organizational unit that grants them permissions to certain services and roles that are inherited from this organizational unit. Adversaries may compromise a valid account and change which organizational account the user belongs to which then could allow them to inherit permissions to applications and resources inaccessible prior to. |[Domain: Cloud], [Data Source: Google Workspace], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |111
 
-|<<group-policy-abuse-for-privilege-addition, Group Policy Abuse for Privilege Addition>> |Detects the first occurrence of a modification to Group Policy Object Attributes to add privileges to user accounts or use them to add users as local admins. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Active Directory], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs] |None |214
+|<<group-policy-abuse-for-privilege-addition, Group Policy Abuse for Privilege Addition>> |Detects the first occurrence of a modification to Group Policy Object Attributes to add privileges to user accounts or use them to add users as local admins. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Active Directory], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs] |None |215
 
 |<<group-policy-discovery-via-microsoft-gpresult-utility, Group Policy Discovery via Microsoft GPResult Utility>> |Detects the usage of gpresult.exe to query group policy objects. Attackers may query group policy objects during the reconnaissance phase after compromising a system to gain a better understanding of the active directory environment and possible methods to escalate privileges or move laterally. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [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 |216
 
@@ -1268,11 +1288,11 @@ and their rule type is `machine_learning`.
 
 |<<imageload-via-windows-update-auto-update-client, ImageLoad via Windows Update Auto Update Client>> |Identifies abuse of the Windows Update Auto Update Client (wuauclt.exe) to load an arbitrary DLL. This behavior is used as a defense evasion technique to blend-in malicious activity with legitimate Windows software. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |321
 
-|<<inbound-connection-to-an-unsecure-elasticsearch-node, Inbound Connection to an Unsecure Elasticsearch Node>> |Identifies Elasticsearch nodes that do not have Transport Layer Security (TLS), and/or lack authentication, and are accepting inbound network connections over the default Elasticsearch port. |[Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Reconnaissance], [Domain: Endpoint], [Resources: Investigation Guide] |None |107
+|<<inbound-connection-to-an-unsecure-elasticsearch-node, Inbound Connection to an Unsecure Elasticsearch Node>> |Identifies Elasticsearch nodes that do not have Transport Layer Security (TLS), and/or lack authentication, and are accepting inbound network connections over the default Elasticsearch port. |[Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Reconnaissance], [Domain: Endpoint], [Resources: Investigation Guide] |None |108
 
-|<<incoming-dcom-lateral-movement-via-mshta, Incoming DCOM Lateral Movement via MSHTA>> |Identifies the use of Distributed Component Object Model (DCOM) to execute commands from a remote host, which are launched via the HTA Application COM Object. This behavior may indicate an attacker abusing a DCOM application to move laterally while attempting to evade detection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |211
+|<<incoming-dcom-lateral-movement-via-mshta, Incoming DCOM Lateral Movement via MSHTA>> |Identifies the use of Distributed Component Object Model (DCOM) to execute commands from a remote host, which are launched via the HTA Application COM Object. This behavior may indicate an attacker abusing a DCOM application to move laterally while attempting to evade detection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |212
 
-|<<incoming-dcom-lateral-movement-with-mmc, Incoming DCOM Lateral Movement with MMC>> |Identifies the use of Distributed Component Object Model (DCOM) to run commands from a remote host, which are launched via the MMC20 Application COM Object. This behavior may indicate an attacker abusing a DCOM application to move laterally. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |212
+|<<incoming-dcom-lateral-movement-with-mmc, Incoming DCOM Lateral Movement with MMC>> |Identifies the use of Distributed Component Object Model (DCOM) to run commands from a remote host, which are launched via the MMC20 Application COM Object. This behavior may indicate an attacker abusing a DCOM application to move laterally. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |213
 
 |<<incoming-dcom-lateral-movement-with-shellbrowserwindow-or-shellwindows, Incoming DCOM Lateral Movement with ShellBrowserWindow or ShellWindows>> |Identifies use of Distributed Component Object Model (DCOM) to run commands from a remote host, which are launched via the ShellBrowserWindow or ShellWindows Application COM Object. This behavior may indicate an attacker abusing a DCOM application to stealthily move laterally. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |212
 
@@ -1300,7 +1320,7 @@ and their rule type is `machine_learning`.
 
 |<<installation-of-security-support-provider, Installation of Security Support Provider>> |Identifies registry modifications related to the Windows Security Support Provider (SSP) configuration. Adversaries may abuse this to establish persistence in an environment. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |315
 
-|<<interactive-logon-by-an-unusual-process, Interactive Logon by an Unusual Process>> |Identifies interactive logon attempt with alternate credentials and by an unusual process. Adversaries may create a new token to escalate privileges and bypass access controls. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |108
+|<<interactive-logon-by-an-unusual-process, Interactive Logon by an Unusual Process>> |Identifies interactive logon attempt with alternate credentials and by an unusual process. Adversaries may create a new token to escalate privileges and bypass access controls. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |109
 
 |<<interactive-shell-launched-via-unusual-parent-process-in-a-container, Interactive Shell Launched via Unusual Parent Process in a Container>> |This rule detects when an interactive shell process is launched via an unusual parent processes inside a container. Interactive processes are typically run in the foreground and require user input, which is unusual behavior for a containerized environment. This activity could indicate an attacker attempting to gain access to the container environment or perform malicious actions. |[Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |3
 
@@ -1310,7 +1330,7 @@ and their rule type is `machine_learning`.
 
 |<<kde-autostart-script-or-desktop-file-creation, KDE AutoStart Script or Desktop File Creation>> |Identifies the creation or modification of a K Desktop Environment (KDE) AutoStart script or desktop file that will execute upon each user logon. Adversaries may abuse this method for persistence. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |220
 
-|<<krbtgt-delegation-backdoor, KRBTGT Delegation Backdoor>> |Identifies the modification of the msDS-AllowedToDelegateTo attribute to KRBTGT. Attackers can use this technique to maintain persistence to the domain by having the ability to request tickets for the KRBTGT service. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |213
+|<<krbtgt-delegation-backdoor, KRBTGT Delegation Backdoor>> |Identifies the modification of the msDS-AllowedToDelegateTo attribute to KRBTGT. Attackers can use this technique to maintain persistence to the domain by having the ability to request tickets for the KRBTGT service. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |214
 
 |<<kerberos-cached-credentials-dumping, Kerberos Cached Credentials Dumping>> |Identifies the use of the Kerberos credential cache (kcc) utility to dump locally cached Kerberos tickets. Adversaries may attempt to dump credential material in the form of tickets that can be leveraged for lateral movement. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |111
 
@@ -1362,14 +1382,24 @@ and their rule type is `machine_learning`.
 
 |<<kubelet-api-connection-attempt-to-internal-ip, Kubelet API Connection Attempt to Internal IP>> |Detects network connection attempts to the Kubernetes Kubelet API port (10250/10255) on internal IP ranges from Linux hosts. This rule focuses on common request and scripting utilities (curl, wget, python, node, etc.) and executions from world-writable or ephemeral paths (/tmp, /var/tmp, /dev/shm, /var/run), which are frequently abused during container and cluster lateral movement. |[Domain: Endpoint], [Domain: Container], [Domain: Kubernetes], [OS: Linux], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Discovery], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Resources: Investigation Guide] |None |1
 
+|<<kubernetes-api-request-impersonating-privileged-identity, Kubernetes API Request Impersonating Privileged Identity>> |Detects Kubernetes API requests where a user is impersonating a privileged cluster identity such as system:kube-controller-manager, system:admin, system:anonymous, or a member of the system:masters group. These identities have broad cluster-wide permissions including unrestricted access to all secrets, the ability to create tokens for any service account, schedule pods on any node, and modify RBAC policies. An attacker impersonating system:masters gains full cluster-admin equivalent access, while impersonating system:kube-controller-manager grants access to every secret in every namespace and the ability to mint service account tokens for lateral movement. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1
+
+|<<kubernetes-api-server-proxying-request-to-kubelet, Kubernetes API Server Proxying Request to Kubelet>> |Detects non-system identities using the Kubernetes nodes/proxy API to proxy requests through the API server directly to a node's Kubelet. The nodes/proxy subresource allows any principal with this RBAC permission to reach the Kubelet API on any worker node without needing direct network access or Kubelet TLS certificates. Through this proxy path, an attacker can list all pod specifications including environment variable secrets, read Kubelet configuration and PKI material, retrieve container logs, and access running pod metadata across all workloads on the target node. Monitoring and health check endpoints such as /metrics, /healthz, and /stats are excluded to reduce noise from legitimate observability tooling. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Lateral Movement], [Tactic: Discovery], [Resources: Investigation Guide] |None |1
+
+|<<kubernetes-admission-webhook-created-or-modified, Kubernetes Admission Webhook Created or Modified>> |Detects creation, modification, or deletion of Kubernetes MutatingWebhookConfigurations or ValidatingWebhookConfigurations by non-system identities. Admission webhooks intercept every API request matching their rules before persistence, giving an attacker powerful capabilities: injecting malicious sidecars into every new pod via a mutating webhook, blocking security tooling deployments via a validating webhook, or silently exfiltrating pod specifications to an external server. Webhook manipulation is a stealthy persistence and defense evasion technique because the webhook configuration itself looks benign in kubectl output while actively modifying or intercepting all matching Kubernetes API traffic. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1
+
 |<<kubernetes-anonymous-request-authorized-by-unusual-user-agent, Kubernetes Anonymous Request Authorized by Unusual User Agent>> |This rule detects when an unauthenticated user request is authorized within the cluster via an unusual user agent. Attackers may attempt to use anonymous accounts to gain initial access to the cluster or to avoid attribution of their activities within the cluster. This rule excludes the /healthz, /livez, /version and /.well-known/oauth-authorization-server endpoints which are commonly accessed anonymously. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |13
 
 |<<kubernetes-anonymous-user-create-update-patch-pods-request, Kubernetes Anonymous User Create/Update/Patch Pods Request>> |This rule detects attempts to create, update, or patch pods by an anonymous user. An anonymous user is a user that is not authenticated or authorized to access the Kubernetes API server. Creating, updating, or patching pods is a common activity for attackers to gain access to the cluster and execute commands. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |3
 
+|<<kubernetes-client-certificate-signing-request-created-or-approved, Kubernetes Client Certificate Signing Request Created or Approved>> |Detects creation or approval of a Kubernetes CertificateSigningRequest (CSR) by a non-system identity. Attackers who have gained cluster access can submit a CSR with a privileged Common Name such as system:kube-controller-manager or system:masters, then approve it themselves to obtain a long-lived client certificate. Unlike service account tokens which expire in hours, client certificates persist until they expire or the cluster CA is rotated, providing durable access that survives pod termination, token revocation, and RBAC changes. On non-EKS clusters, the signed certificate allows the attacker to authenticate as the privileged identity from anywhere without needing cluster network access, making it one of the most persistent backdoor mechanisms available in Kubernetes. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1
+
 |<<kubernetes-cluster-admin-role-binding-created, Kubernetes Cluster-Admin Role Binding Created>> |This rule detects the creation of a RoleBinding or ClusterRoleBinding that grants the cluster-admin ClusterRole, which provides unrestricted access to all Kubernetes resources and represents a high-risk privilege escalation or misconfiguration. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |2
 
 |<<kubernetes-container-created-with-excessive-linux-capabilities, Kubernetes Container Created with Excessive Linux Capabilities>> |This rule detects a container deployed with one or more dangerously permissive Linux capabilities. An attacker with the ability to deploy a container with added capabilities could use this for further execution, lateral movement, or privilege escalation within a cluster. The capabilities detected in this rule have been used in container escapes to the host machine. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |12
 
+|<<kubernetes-coredns-or-kube-dns-configuration-modified, Kubernetes CoreDNS or Kube-DNS Configuration Modified>> |Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace. These ConfigMaps control cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service DNS names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server, database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every pod in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS configuration changes are rare in normal operations and any unexpected modification should be investigated immediately. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1
+
 |<<kubernetes-creation-of-a-rolebinding-referencing-a-serviceaccount, Kubernetes Creation of a RoleBinding Referencing a ServiceAccount>> |This rule detects the creation of RoleBindings or ClusterRoleBindings that reference a ServiceAccount, which may indicate privilege delegation or potential RBAC misconfiguration leading to elevated access. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |2
 
 |<<kubernetes-creation-or-modification-of-sensitive-role, Kubernetes Creation or Modification of Sensitive Role>> |Detects the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs (e.g., bind, escalate, impersonate), which may enable privilege escalation or unauthorized access within the cluster. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |4
@@ -1378,6 +1408,8 @@ and their rule type is `machine_learning`.
 
 |<<kubernetes-direct-api-request-via-curl-or-wget, Kubernetes Direct API Request via Curl or Wget>> |This rule monitors for the execution of curl or wget commands that directly access Kubernetes API endpoints, which may indicate an attempt to interact with Kubernetes resources in a potentially unauthorized manner. This technique is often used by adversaries to gather information about the Kubernetes environment, such as secrets, config maps, and other sensitive data, without using the official Kubernetes client tools such as "kubectl". |[Domain: Endpoint], [Domain: Container], [Domain: Kubernetes], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Discovery], [Data Source: Auditd Manager], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |2
 
+|<<kubernetes-ephemeral-container-added-to-pod, Kubernetes Ephemeral Container Added to Pod>> |Detects allowed updates to the pods/ephemeralcontainers subresource by a non-system identity. Ephemeral containers are commonly used for debugging (kubectl debug) but can also be abused to inject tooling into a running pod, access mounted secrets, and execute commands in the target pod context. Attackers with sufficient RBAC may use ephemeral containers to escalate privileges, move laterally, or establish persistence without deploying a new workload. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Resources: Investigation Guide] |None |1
+
 |<<kubernetes-events-deleted, Kubernetes Events Deleted>> |This rule detects the deletion of Kubernetes events, which can indicate an attempt to cover up malicious activity or misconfigurations. Adversaries may delete events to remove traces of their actions, making it harder for defenders to investigate and respond to incidents. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |3
 
 |<<kubernetes-exposed-service-created-with-type-nodeport, Kubernetes Exposed Service Created With Type NodePort>> |This rule detects an attempt to create or modify a service as type NodePort. The NodePort service allows a user to externally expose a set of labeled pods to the internet. This creates an open port on every worker node in the cluster that has a pod for that service. When external traffic is received on that open port, it directs it to the specific pod through the service representing it. A malicious user can configure a service as type Nodeport in order to intercept traffic from other pods or nodes, bypassing firewalls and other network security measures configured for load balancers within a cluster. This creates a direct method of communication between the cluster and the outside world, which could be used for more malicious behavior and certainly widens the attack surface of your cluster. |[Data Source: Kubernetes], [Tactic: Execution], [Tactic: Persistence], [Resources: Investigation Guide] |None |209
@@ -1386,7 +1418,7 @@ and their rule type is `machine_learning`.
 
 |<<kubernetes-forbidden-request-from-unusual-user-agent, Kubernetes Forbidden Request from Unusual User Agent>> |This rule detects when a forbidden request is made from an unusual user agent in a Kubernetes environment. Adversary tooling may use non-standard or unexpected user agents to interact with the Kubernetes API, which can indicate an attempt to evade detection or blend in with legitimate traffic. In combination with a forbidden request, this behavior can suggest an adversary is attempting to exploit vulnerabilities or misconfigurations in the Kubernetes cluster. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |6
 
-|<<kubernetes-multi-resource-discovery, Kubernetes Multi-Resource Discovery>> |Adversaries who land credentials in a 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 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. It is less typical for steady-state controllers, which usually touch a narrow set of resources repeatedly. This rule highlights that cross-resource burst from a single client fingerprint within a one-minute bucket so analysts can separate routine automation from potential discovery and permission reconnaissance ahead of follow-on actions. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |1
+|<<kubernetes-multi-resource-discovery, Kubernetes Multi-Resource Discovery>> |Adversaries who land credentials in a 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 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. It is less typical for steady-state controllers, which usually touch a narrow set of resources repeatedly. This rule highlights that cross-resource burst from a single client fingerprint within a one-minute bucket so analysts can separate routine automation from potential discovery and permission reconnaissance ahead of follow-on actions. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |2
 
 |<<kubernetes-pod-created-with-hostipc, Kubernetes Pod Created With HostIPC>> |This rule detects an attempt to create or modify a pod using the host IPC namespace. This gives access to data used by any pod that also use the hosts IPC namespace. If any process on the host or any processes in a pod uses the hosts inter-process communication mechanisms (shared memory, semaphore arrays, message queues, etc.), an attacker can read/write to those same mechanisms. They may look for files in /dev/shm or use ipcs to check for any IPC facilities being used. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |210
 
@@ -1414,17 +1446,17 @@ and their rule type is `machine_learning`.
 
 |<<kubernetes-rbac-wildcard-elevation-on-existing-role, Kubernetes RBAC Wildcard Elevation on Existing Role>> |Flags an existing Role or ClusterRole being changed (patch or update) so the effective rules become cluster-admin-like: wildcard on every API resource and wildcard on every verb. That is usually a deliberate privilege expansion, not a typo. RequestResponse audit and the response body are required so the detection reads the merged role after apply; loopback source IPs are ignored. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |2
 
-|<<kubernetes-rapid-secret-get-activity-against-multiple-objects, Kubernetes Rapid Secret GET Activity Against Multiple Objects>> |This rule detects an unusual volume of Kubernetes API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within a defined lookback window. This can indicate credential access or in-cluster reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. Failed get requests are also included, as they may reveal RBAC boundaries, confirm the existence of targeted secrets, or reflect automated probing activity. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1
+|<<kubernetes-rapid-secret-get-activity-against-multiple-objects, Kubernetes Rapid Secret GET Activity Against Multiple Objects>> |This rule detects an unusual volume of Kubernetes API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within a defined lookback window. This can indicate credential access or in-cluster reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. Failed get requests are also included, as they may reveal RBAC boundaries, confirm the existence of targeted secrets, or reflect automated probing activity. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |2
 
 |<<kubernetes-secret-access-via-unusual-user-agent, Kubernetes Secret Access via Unusual User Agent>> |This rule detects when secrets are accessed via an unusual user agent, user name and source IP. Attackers may attempt to access secrets in a Kubernetes cluster to gain access to sensitive information after gaining access to the cluster. |[Data Source: Kubernetes], [Domain: Kubernetes], [Domain: Cloud], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |3
 
-|<<kubernetes-secret-get-or-list-from-node-or-pod-service-account, Kubernetes Secret get or list from Node or Pod Service Account>> |Kubernetes audit identities for kubelet (`system:node:*`) and workloads (`system:serviceaccount:*`) are meant to operate with tight, predictable API usage. Direct `get` or `list` on the Secrets API from those principals is often a sign of credential access. Attackers who stole a pod service-account token or node credentials sweep Secret objects for tokens, registry credentials, TLS keys, or application configuration. Even denied attempts still reveal intent to reach sensitive material. Legitimate controllers do read secrets they mount or manage, so this signal is most valuable when paired with triage (namespace scope, user agent, RBAC, and whether the identity should touch those secret names at all). |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1
+|<<kubernetes-secret-get-or-list-from-node-or-pod-service-account, Kubernetes Secret get or list from Node or Pod Service Account>> |Kubernetes audit identities for kubelet (`system:node:*`) and workloads (`system:serviceaccount:*`) are meant to operate with tight, predictable API usage. Direct `get` or `list` on the Secrets API from those principals is often a sign of credential access. Attackers who stole a pod service-account token or node credentials sweep Secret objects for tokens, registry credentials, TLS keys, or application configuration. Even denied attempts still reveal intent to reach sensitive material. Legitimate controllers do read secrets they mount or manage, so this signal is most valuable when paired with triage (namespace scope, user agent, RBAC, and whether the identity should touch those secret names at all). |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |2
 
 |<<kubernetes-secret-get-or-list-with-suspicious-user-agent, Kubernetes Secret get or list with Suspicious User Agent>> |Detects read access to Kubernetes Secrets (`get`/`list`) with a user agent matching a curated set of non-standard or attacker-leaning clients, for example minimal HTTP tooling, common scripting stacks, default library fingerprints, or distribution-tagged strings associated with offensive-security Linux images. Legitimate in-cluster automation usually presents stable, purpose-specific user agents (for example controller or client-go variants used by known components). |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1
 
 |<<kubernetes-secret-or-configmap-access-via-azure-arc-proxy, Kubernetes Secret or ConfigMap Access via Azure Arc Proxy>> |Detects when secrets or configmaps are accessed, created, modified, or deleted in a Kubernetes cluster by the Azure Arc AAD proxy service account. When operations are routed through the Azure Arc Cluster Connect proxy, the Kubernetes audit log records the acting user as `system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa` with the actual caller identity in the `impersonatedUser` field. This pattern indicates that someone is accessing the cluster through the Azure ARM API rather than directly via kubectl against the API server. While legitimate for Arc-managed workflows, adversaries with stolen service principal credentials can abuse Arc Cluster Connect to read, exfiltrate, or modify secrets and configmaps while appearing as the Arc proxy service account in K8s audit logs. |[Data Source: Kubernetes], [Domain: Kubernetes], [Domain: Cloud], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Collection], [Resources: Investigation Guide] |None |2
 
-|<<kubernetes-secrets-list-across-cluster-or-sensitive-namespaces, Kubernetes Secrets List Across Cluster or Sensitive Namespaces>> |Detects list operations on Kubernetes Secrets from a non-loopback client when the request URI targets cluster-wide secrets or list operations under kube-system or default. Useful for spotting broad secret enumeration from remote clients. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Discovery], [Resources: Investigation Guide] |None |1
+|<<kubernetes-secrets-list-across-cluster-or-sensitive-namespaces, Kubernetes Secrets List Across Cluster or Sensitive Namespaces>> |Detects list operations on Kubernetes Secrets from a non-loopback client when the request URI targets cluster-wide secrets or list operations under kube-system or default. Useful for spotting broad secret enumeration from remote clients. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Discovery], [Resources: Investigation Guide] |None |2
 
 |<<kubernetes-sensitive-configuration-file-activity, Kubernetes Sensitive Configuration File Activity>> |This rule detects the creation or modification of sensitive Kubernetes configuration files on Linux systems. These files include Kubernetes manifests, PKI files, and configuration files that are critical for the operation of Kubernetes clusters. Monitoring these files helps identify potential unauthorized changes or misconfigurations that could lead to security vulnerabilities in Kubernetes environments. Attackers may attempt to modify these files to gain persistence or to deploy malicious containers within the Kubernetes cluster. |[Domain: Endpoint], [Domain: Kubernetes], [Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2
 
@@ -1434,6 +1466,10 @@ and their rule type is `machine_learning`.
 
 |<<kubernetes-service-account-secret-access, Kubernetes Service Account Secret Access>> |This rule detects when a process accesses Kubernetes service account secrets. Kubernetes service account secrets are files that contain sensitive information used by applications running in Kubernetes clusters to authenticate and authorize access to the cluster. These secrets are typically mounted into pods at runtime, allowing applications to access them securely. Unauthorized access to these secrets can lead to privilege escalation, lateral movement and unauthorized actions within the cluster. |[Domain: Endpoint], [Domain: Container], [Domain: Kubernetes], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |4
 
+|<<kubernetes-service-account-token-created-via-tokenrequest-api, Kubernetes Service Account Token Created via TokenRequest API>> |Detects the creation of a Kubernetes service account token through the TokenRequest API by a non-system identity. The TokenRequest API allows users and workloads to programmatically generate short-lived tokens for any service account they have create permissions on, without accessing the filesystem or the mounted projected token. Attackers who have gained initial access to a cluster can abuse this API to mint tokens for more privileged service accounts, pivot to cloud provider resources via IRSA/workload identity, or generate long-lived tokens that persist beyond pod termination. Unlike mounted service account tokens which are detectable through file access monitoring, tokens created via the TokenRequest API leave no filesystem footprint, they are only visible in Kubernetes audit logs as a create verb on the serviceaccounts/token subresource. This rule excludes legitimate system components such as the kubelet, kube-controller-manager, and cloud provider managed identities (EKS, AKS, GKE) that routinely create tokens for pod lifecycle management. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1
+
+|<<kubernetes-static-pod-manifest-file-access, Kubernetes Static Pod Manifest File Access>> |Detects Linux process executions where shells, editors, interpreters, or file/stream utilities reference /etc/kubernetes/manifests in process arguments. That directory holds static pod manifests read by the kubelet; interaction via editors, downloaders, kubectl, redirection helpers (tee, dd), or scripting runtimes may indicate staging or tampering with manifests for persistence or privileged workload placement. Pairs with file-telemetry rules that flag direct manifest creation on container workloads. |[Data Source: Auditd Manager], [Data Source: Elastic Defend], [Domain: Endpoint], [Domain: Kubernetes], [Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1
+
 |<<kubernetes-suspicious-assignment-of-controller-service-account, Kubernetes Suspicious Assignment of Controller Service Account>> |This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate privileges and gain complete cluster control. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |12
 
 |<<kubernetes-suspicious-self-subject-review-via-unusual-user-agent, Kubernetes Suspicious Self-Subject Review via Unusual User Agent>> |This rule detects when a service account or node attempts to enumerate their own permissions via the selfsubjectaccessreview or selfsubjectrulesreview APIs via an unusual user agent. This is highly unusual behavior for non-human identities like service accounts and nodes. An adversary may have gained access to credentials/tokens and this could be an attempt to determine what privileges they have to facilitate further movement or execution within the cluster. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |211
@@ -1442,17 +1478,19 @@ and their rule type is `machine_learning`.
 
 |<<kubernetes-user-exec-into-pod, Kubernetes User Exec into Pod>> |This rule detects a user attempt to establish a shell session into a pod using the 'exec' command. Using the 'exec' command in a pod allows a user to establish a temporary shell session and execute any process/commands in the pod. An adversary may call bash to gain a persistent interactive shell which will allow access to any data the pod has permissions to, including secrets. |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |211
 
+|<<kubernetes-and-cloud-credential-path-access-via-process-arguments, Kubernetes and Cloud Credential Path Access via Process Arguments>> |Flags Linux process executions whose arguments reference high-value Kubernetes service-account material, kubeconfig or node PKI paths, or common cloud and SSH credential files, when invoked via typical file-reading utilities or from ephemeral directories. Useful for spotting in-cluster and hybrid credential theft early. |[Data Source: Auditd Manager], [Data Source: Elastic Defend], [Domain: Endpoint], [Domain: Kubernetes], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1
+
 |<<lsass-memory-dump-creation, LSASS Memory Dump Creation>> |Identifies creation of LSASS memory dump artifacts with filenames matching LSASS dumps or common dumping-tool outputs, including dumpert.dmp, Andrew.dmp, SQLDmpr*.mdmp, and Coredump.dmp. This can indicate credential access through trusted utilities such as Task Manager or SQLDumper, or known tooling such as Dumpert and AndrewSpecial. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne] |None |316
 
-|<<lsass-memory-dump-handle-access, LSASS Memory Dump Handle Access>> |Identifies handle requests for the Local Security Authority Subsystem Service (LSASS) object access with specific access masks that many tools with a capability to dump memory to disk use (0x1fffff, 0x1010, 0x120089). This rule is tool agnostic as it has been validated against a host of various LSASS dump tools such as SharpDump, Procdump, Mimikatz, Comsvcs etc. It detects this behavior at a low level and does not depend on a specific tool or dump file name. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs] |None |217
+|<<lsass-memory-dump-handle-access, LSASS Memory Dump Handle Access>> |Identifies handle requests for the Local Security Authority Subsystem Service (LSASS) object access with specific access masks that many tools with a capability to dump memory to disk use (0x1fffff, 0x1010, 0x120089). This rule is tool agnostic as it has been validated against a host of various LSASS dump tools such as SharpDump, Procdump, Mimikatz, Comsvcs etc. It detects this behavior at a low level and does not depend on a specific tool or dump file name. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs] |None |218
 
-|<<lsass-process-access-via-windows-api, LSASS Process Access via Windows API>> |Identifies access attempts to the LSASS handle, which may indicate an attempt to dump credentials from LSASS memory. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR], [Resources: Investigation Guide] |None |18
+|<<lsass-process-access-via-windows-api, LSASS Process Access via Windows API>> |Identifies access attempts to the LSASS handle, which may indicate an attempt to dump credentials from LSASS memory. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR], [Resources: Investigation Guide] |None |19
 
 |<<lateral-movement-alerts-from-a-newly-observed-source-address, Lateral Movement Alerts from a Newly Observed Source Address>> |This rule detects source IPs that triggered their first lateral movement alert within the last 10 minutes (i.e., newly observed), while also triggering at least 2 distinct lateral movement detection rules. This surfaces new potentially malicious IPs exhibiting immediate lateral movement behavior. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |3
 
 |<<lateral-movement-alerts-from-a-newly-observed-user, Lateral Movement Alerts from a Newly Observed User>> |This rule detects multiple lateral movement alerts from a user that was observed for the first time in the previous 5 days of alerts history. Analysts can use this high-order detection to prioritize triage and response. |[OS: Windows], [Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |3
 
-|<<lateral-movement-via-startup-folder, Lateral Movement via Startup Folder>> |Identifies suspicious file creations in the startup folder of a remote system. An adversary could abuse this to move laterally by dropping a malicious script or executable that will be executed after a reboot or user logon. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |314
+|<<lateral-movement-via-startup-folder, Lateral Movement via Startup Folder>> |Identifies suspicious file creations in the startup folder of a remote system. An adversary could abuse this to move laterally by dropping a malicious script or executable that will be executed after a reboot or user logon. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |315
 
 |<<launch-service-creation-and-immediate-loading, Launch Service Creation and Immediate Loading>> |An adversary can establish persistence by installing a new launch agent that executes at login by using launchd or launchctl to load a plist into the appropriate directories. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |112
 
@@ -1540,9 +1578,9 @@ and their rule type is `machine_learning`.
 
 |<<m365-identity-global-administrator-role-assigned, M365 Identity Global Administrator Role Assigned>> |Identifies when the Microsoft 365 Global Administrator or Company Administrator role is assigned to a user or service principal. The Global Administrator role has extensive privileges across Entra ID and Microsoft 365 services, making it a high-value target for adversaries seeking persistent access. Successful assignments of this role may indicate potential privilege escalation or unauthorized access attempts, especially if performed by accounts that do not typically manage high-privilege roles. |[Domain: Cloud], [Domain: SaaS], [Domain: Identity], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |215
 
-|<<m365-identity-login-from-atypical-travel-location, M365 Identity Login from Atypical Travel Location>> |Detects successful Microsoft 365 portal logins from rare locations. Rare locations are defined as locations that are not commonly associated with the user's account. This behavior may indicate an adversary attempting to access a Microsoft 365 account from an unusual location or behind a VPN. |[Domain: Cloud], [Domain: Identity], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |10
+|<<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. |[Domain: Cloud], [Domain: Identity], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |11
 
-|<<m365-identity-login-from-impossible-travel-location, M365 Identity Login from Impossible Travel Location>> |Detects successful Microsoft 365 portal logins from impossible travel locations. Impossible travel locations are defined as two different countries within a short time frame. This behavior may indicate an adversary attempting to access a Microsoft 365 account from a compromised account or a malicious actor attempting to access a Microsoft 365 account from a different location. |[Domain: Cloud], [Domain: Identity], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |9
+|<<m365-identity-login-from-impossible-travel-location, M365 Identity Login from Impossible Travel Location>> |Detects successful Microsoft 365 portal logins from impossible travel locations. Impossible travel locations are defined as two different countries within a short time frame. This behavior may indicate an adversary attempting to access a Microsoft 365 account from a compromised account or a malicious actor attempting to access a Microsoft 365 account from a different location. |[Domain: Cloud], [Domain: Identity], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |10
 
 |<<m365-identity-oauth-flow-by-first-party-microsoft-app-from-multiple-ips, M365 Identity OAuth Flow by First-Party Microsoft App from Multiple IPs>> |Identifies sign-ins on behalf of a principal user to the Microsoft Graph or legacy Azure AD API from multiple IPs using first-party Microsoft applications from the FOCI (Family of Client IDs) group. Developer tools like Azure CLI, VSCode, and Azure PowerShell accessing these resources from multiple IPs are flagged, along with any FOCI application accessing the deprecated Windows Azure Active Directory from multiple IPs. This behavior may indicate an adversary using a phished OAuth authorization code or refresh token, as seen in attacks like ConsentFix where attackers steal localhost OAuth codes and replay them from attacker infrastructure. |[Domain: Cloud], [Domain: Email], [Domain: Identity], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Defense Evasion] |None |9
 
@@ -1562,6 +1600,8 @@ and their rule type is `machine_learning`.
 
 |<<m365-onedrive-sharepoint-excessive-file-downloads, M365 OneDrive/SharePoint Excessive File Downloads>> |Identifies when an excessive number of files are downloaded from OneDrive or SharePoint by an authorized user or application in a short period of time. This may indicate a potential data exfiltration event, especially if the downloads are performed using OAuth authentication which could suggest an OAuth phishing attack such as Device Code Authentication phishing. |[Domain: Cloud], [Domain: SaaS], [Domain: Storage], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Data Source: SharePoint], [Data Source: OneDrive], [Use Case: Threat Detection], [Tactic: Collection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |9
 
+|<<m365-potential-aitm-userloggedin-via-office-app-tycoon2fa, M365 Potential AiTM UserLoggedIn via Office App (Tycoon2FA)>> |Detects Microsoft 365 audit "UserLoggedIn" events consistent with Tycoon 2FA phishing-as-a-service (PhaaS) adversary-in-the-middle (AiTM) activity: the Microsoft Authentication Broker requesting access where the object identifier matches Microsoft Graph or Exchange Online, or the Office web client application authenticating to itself, combined with Node.js-style user agents (node, axios, undici). Tycoon 2FA bypasses MFA by relaying authentication and capturing session material, often targeting Microsoft 365 and Gmail. Baseline legitimate automation and developer tooling before tuning. |[Domain: Cloud], [Domain: Identity], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Threat: Tycoon2FA], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1
+
 |<<m365-purview-dlp-signal, M365 Purview DLP Signal>> |Identifies Microsoft 365 Data Loss Prevention (DLP) and Data Lifecycle Management (DLM) signals from Microsoft Purview across Exchange, SharePoint, OneDrive, and endpoint devices. These events indicate potential data exfiltration attempts, policy violations involving sensitive data, or unauthorized sharing of classified information. This building block rule generates security events for correlation, threat hunting, and telemetry collection to support detection of collection and exfiltration activities. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Data Source: Microsoft Purview], [Data Source: Microsoft Purview DLP], [Use Case: Threat Detection], [Use Case: Data Protection], [Tactic: Collection], [Tactic: Exfiltration], [Rule Type: BBR] |None |2
 
 |<<m365-purview-insider-risk-signal, M365 Purview Insider Risk Signal>> |Identifies Microsoft Purview Insider Risk Management signals including alerts, cases, scoped user insights, HR signals, and physical badging signals. These events indicate potential insider threats, compromised user accounts, or anomalous user behavior patterns detected by Microsoft's behavioral analytics. This building block rule generates security events for correlation, threat hunting, and telemetry collection to support detection of insider threats and account compromise. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Data Source: Microsoft Purview], [Data Source: Microsoft Purview Insider Risk], [Use Case: Threat Detection], [Use Case: Insider Threat Detection], [Tactic: Collection], [Tactic: Exfiltration], [Tactic: Impact], [Rule Type: BBR] |None |1
@@ -1650,7 +1690,9 @@ and their rule type is `machine_learning`.
 
 |<<microsoft-exchange-server-um-writing-suspicious-files, Microsoft Exchange Server UM Writing Suspicious Files>> |Identifies suspicious files being written by the Microsoft Exchange Server Unified Messaging (UM) service. This activity has been observed exploiting CVE-2021-26858. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Lateral Movement], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |314
 
-|<<microsoft-exchange-worker-spawning-suspicious-processes, Microsoft Exchange Worker Spawning Suspicious Processes>> |Identifies suspicious processes being spawned by the Microsoft Exchange Server worker process (w3wp). This activity may indicate exploitation activity or access to an existing web shell backdoor. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |315
+|<<microsoft-exchange-worker-spawning-suspicious-processes, Microsoft Exchange Worker Spawning Suspicious Processes>> |Identifies suspicious processes being spawned by the Microsoft Exchange Server worker process (w3wp). This activity may indicate exploitation activity or access to an existing web shell backdoor. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |316
+
+|<<microsoft-graph-multi-category-reconnaissance-burst, Microsoft Graph Multi-Category Reconnaissance Burst>> |Detects Microsoft Graph activity from delegated user tokens (public client, client_auth_method 0) where a single user session and source IP rapidly touches multiple high-value Graph paths indicative of reconnaissance. The query classifies requests into categories such as role discovery, cross-tenant relationship queries, mailbox paths, contact harvesting, and organization or licensing metadata. When three or more distinct categories appear within a short burst window, it suggests a broad enumeration playbook rather than normal application traffic. |[Domain: Cloud], [Domain: Identity], [Domain: API], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Graph], [Data Source: Microsoft Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |1
 
 |<<microsoft-graph-request-email-access-by-unusual-user-and-client, Microsoft Graph Request Email Access by Unusual User and Client>> |Identifies access to email resources via Microsoft Graph API using an first-party application on behalf of a user principal. This behavior may indicate an adversary using a phished OAuth refresh token or a Primary Refresh Token (PRT) to access email resources. The pattern includes requests to Microsoft Graph API endpoints related to email, such as /me/mailFolders/inbox/messages or /users/{user_id}/messages, using a public client application ID and a user principal object ID. This is a New Terms rule that only signals if the application ID and user principal object ID have not been seen doing this activity in the last 14 days. |[Domain: Cloud], [Domain: Email], [Data Source: Azure], [Data Source: Microsoft Graph], [Data Source: Microsoft Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide] |None |6
 
@@ -1666,7 +1708,7 @@ and their rule type is `machine_learning`.
 
 |<<microsoft-windows-defender-tampering, Microsoft Windows Defender Tampering>> |Identifies when one or more features on Microsoft Defender are disabled. Adversaries may disable or tamper with Microsoft Defender features to evade detection and conceal malicious behavior. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Data Source: Crowdstrike] |None |320
 
-|<<mimikatz-memssp-log-file-detected, Mimikatz Memssp Log File Detected>> |Identifies the default Mimikatz MemSSP credential log file, mimilsa.log. This file is created after the misc::memssp module injects a malicious Security Support Provider into LSASS and can contain credentials from subsequent logons to the host. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike] |None |418
+|<<mimikatz-memssp-log-file-detected, Mimikatz Memssp Log File Detected>> |Identifies the default Mimikatz MemSSP credential log file, mimilsa.log. This file is created after the misc::memssp module injects a malicious Security Support Provider into LSASS and can contain credentials from subsequent logons to the host. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike] |None |419
 
 |<<modification-of-amsienable-registry-key, Modification of AmsiEnable Registry Key>> |Identifies modifications of the AmsiEnable registry key to 0, which disables Windows Script AMSI scanning for the affected user. Adversaries can modify this key to bypass AMSI protections for Windows Script Host or JScript execution. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |317
 
@@ -1886,11 +1928,11 @@ and their rule type is `machine_learning`.
 
 |<<persistence-via-folder-action-script, Persistence via Folder Action Script>> |Detects modification of a Folder Action script. A Folder Action script is executed when the folder to which it is attached has items added or removed, or when its window is opened, closed, moved, or resized. Adversaries may abuse this feature to establish persistence by utilizing a malicious script. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |113
 
-|<<persistence-via-hidden-run-key-detected, Persistence via Hidden Run Key Detected>> |Identifies a persistence mechanism that utilizes the NtSetValueKey native API to create a hidden (null terminated) registry key. An adversary may use this method to hide from system utilities such as the Registry Editor (regedit). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR] |None |215
+|<<persistence-via-hidden-run-key-detected, Persistence via Hidden Run Key Detected>> |Identifies a persistence mechanism that utilizes the NtSetValueKey native API to create a hidden (null terminated) registry key. An adversary may use this method to hide from system utilities such as the Registry Editor (regedit). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR] |None |216
 
 |<<persistence-via-login-or-logout-hook, Persistence via Login or Logout Hook>> |Identifies use of the Defaults command to install a login or logoff hook in MacOS. An adversary may abuse this capability to establish persistence in an environment by inserting code to be executed at login or logout. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |112
 
-|<<persistence-via-microsoft-office-addins, Persistence via Microsoft Office AddIns>> |Detects attempts to establish persistence on an endpoint by abusing Microsoft Office add-ins. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |313
+|<<persistence-via-microsoft-office-addins, Persistence via Microsoft Office AddIns>> |Detects attempts to establish persistence on an endpoint by abusing Microsoft Office add-ins. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |314
 
 |<<persistence-via-microsoft-outlook-vba, Persistence via Microsoft Outlook VBA>> |Detects attempts to establish persistence on an endpoint by installing a rogue Microsoft Outlook VBA Template. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |314
 
@@ -1900,13 +1942,13 @@ and their rule type is `machine_learning`.
 
 |<<persistence-via-suspicious-launch-agent-or-launch-daemon, Persistence via Suspicious Launch Agent or Launch Daemon>> |Identifies the creation of a launch agent or daemon property list file containing abnormal or suspicious values. An adversary may establish persistence by installing a new launch agent or daemon which executes at login. This rule looks for plist files created in LaunchAgents/LaunchDaemons directories with paths commonly used by malware. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1
 
-|<<persistence-via-telemetrycontroller-scheduled-task-hijack, Persistence via TelemetryController Scheduled Task Hijack>> |Detects the successful hijack of Microsoft Compatibility Appraiser scheduled task to establish persistence with an integrity level of system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [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 |317
+|<<persistence-via-telemetrycontroller-scheduled-task-hijack, Persistence via TelemetryController Scheduled Task Hijack>> |Detects the successful hijack of Microsoft Compatibility Appraiser scheduled task to establish persistence with an integrity level of system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |318
 
-|<<persistence-via-update-orchestrator-service-hijack, Persistence via Update Orchestrator Service Hijack>> |Identifies potential hijacking of the Microsoft Update Orchestrator Service to establish persistence with an integrity level of SYSTEM. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Use Case: Vulnerability], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: Windows Security Event Logs], [Data Source: SentinelOne] |None |318
+|<<persistence-via-update-orchestrator-service-hijack, Persistence via Update Orchestrator Service Hijack>> |Identifies potential hijacking of the Microsoft Update Orchestrator Service to establish persistence with an integrity level of SYSTEM. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Use Case: Vulnerability], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: Windows Security Event Logs], [Data Source: SentinelOne] |None |319
 
 |<<persistence-via-wmi-event-subscription, Persistence via WMI Event Subscription>> |An adversary can use Windows Management Instrumentation (WMI) to install event filters, providers, consumers, and bindings that execute code when a defined event occurs. Adversaries may use the capabilities of WMI to subscribe to an event and execute arbitrary code when that event occurs, providing persistence on a system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |319
 
-|<<persistence-via-wmi-standard-registry-provider, Persistence via WMI Standard Registry Provider>> |Identifies use of the Windows Management Instrumentation StdRegProv (registry provider) to modify commonly abused registry locations for persistence. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |113
+|<<persistence-via-wmi-standard-registry-provider, Persistence via WMI Standard Registry Provider>> |Identifies use of the Windows Management Instrumentation StdRegProv (registry provider) to modify commonly abused registry locations for persistence. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |114
 
 |<<persistence-via-a-hidden-plist-filename, Persistence via a Hidden Plist Filename>> |Identifies the creation of a hidden launch agent or daemon property list file. An adversary may establish persistence by installing a new launch agent or daemon which executes at login. Hidden plist files with filenames starting with a dot are particularly suspicious. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1
 
@@ -1930,7 +1972,7 @@ and their rule type is `machine_learning`.
 
 |<<port-forwarding-rule-addition, Port Forwarding Rule Addition>> |Identifies the creation of a new port forwarding rule. An adversary may abuse this technique to bypass network segmentation restrictions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike] |None |419
 
-|<<possible-fin7-dga-command-and-control-behavior, Possible FIN7 DGA Command and Control Behavior>> |This rule detects a known command and control pattern in network events. The FIN7 threat group is known to use this command and control technique, while maintaining persistence in their target's network. |[Use Case: Threat Detection], [Tactic: Command and Control], [Domain: Endpoint], [Data Source: PAN-OS], [Resources: Investigation Guide] |None |109
+|<<possible-fin7-dga-command-and-control-behavior, Possible FIN7 DGA Command and Control Behavior>> |This rule detects a known command and control pattern in network events. The FIN7 threat group is known to use this command and control technique, while maintaining persistence in their target's network. |[Use Case: Threat Detection], [Tactic: Command and Control], [Domain: Endpoint], [Data Source: PAN-OS], [Resources: Investigation Guide] |None |110
 
 |<<possible-okta-dos-attack, Possible Okta DoS Attack>> |Detects possible Denial of Service (DoS) attacks against an Okta organization. An adversary may attempt to disrupt an organization's business operations by performing a DoS attack against its Okta service. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Impact], [Resources: Investigation Guide] |None |414
 
@@ -1962,7 +2004,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-cve-2025-32463-sudo-chroot-execution-attempt, Potential CVE-2025-32463 Sudo Chroot Execution Attempt>> |Detects suspicious use of sudo's --chroot / -R option consistent with attempts to exploit CVE-2025-32463 (the "sudo chroot" privilege escalation), where an attacker tricks sudo into using attacker-controlled NSS files or libraries to gain root. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Use Case: Vulnerability], [Resources: Investigation Guide] |None |3
 
-|<<potential-cve-2025-33053-exploitation, Potential CVE-2025-33053 Exploitation>> |Identifies a suspicious Diagnostics Utility for Internet Explorer child process. This may indicate the successful exploitation of the vulnerability CVE-2025-33053. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |3
+|<<potential-cve-2025-33053-exploitation, Potential CVE-2025-33053 Exploitation>> |Identifies Internet Explorer Diagnostics launching a helper name from a non-System32 path, which may indicate CVE-2025-33053 exploitation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |4
 
 |<<potential-cve-2025-41244-vmtoolsd-lpe-exploitation-attempt, Potential CVE-2025-41244 vmtoolsd LPE Exploitation Attempt>> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Use Case: Vulnerability], [Resources: Investigation Guide] |None |3
 
@@ -1970,7 +2012,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-code-execution-via-postgresql, Potential Code Execution via Postgresql>> |This rule monitors for suspicious activities that may indicate an attacker attempting to execute arbitrary code within a PostgreSQL environment. Attackers can execute code via PostgreSQL as a result of gaining unauthorized access to a public facing PostgreSQL database or exploiting vulnerabilities, such as remote command execution and SQL injection attacks, which can result in unauthorized access and malicious actions, and facilitate post-exploitation activities for unauthorized access and malicious actions. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |13
 
-|<<potential-command-shell-via-netcat, Potential Command Shell via NetCat>> |Identifies potential attempt to execute via a reverse shell using the netcat utility to execute Windows commands using the default interpreters like Cmd.exe and Powershell. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |2
+|<<potential-command-shell-via-netcat, Potential Command Shell via NetCat>> |Identifies potential attempt to execute via a reverse shell using the netcat utility to execute Windows commands using the default interpreters like Cmd.exe and Powershell. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |3
 
 |<<potential-command-and-control-via-internet-explorer, Potential Command and Control via Internet Explorer>> |Identifies instances of Internet Explorer (iexplore.exe) being started via the Component Object Model (COM) making unusual network connections. Adversaries could abuse Internet Explorer via COM to avoid suspicious processes making network connections and bypass host-based firewall restrictions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |111
 
@@ -2040,7 +2082,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-enumeration-via-active-directory-web-service, Potential Enumeration via Active Directory Web Service>> |Identifies processes loading Active Directory related modules followed by a network connection to the ADWS dedicated TCP port. Adversaries may abuse the ADWS Windows service that allows Active Directory to be queried via this web service. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |7
 
-|<<potential-escalation-via-vulnerable-msi-repair, Potential Escalation via Vulnerable MSI Repair>> |Identifies when a browser process navigates to the Microsoft Help page followed by spawning an elevated process. This may indicate a successful exploitation for privilege escalation abusing a vulnerable Windows Installer repair setup. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Resources: Investigation Guide] |None |206
+|<<potential-escalation-via-vulnerable-msi-repair, Potential Escalation via Vulnerable MSI Repair>> |Identifies when a browser process navigates to the Microsoft Help page followed by spawning an elevated process. This may indicate a successful exploitation for privilege escalation abusing a vulnerable Windows Installer repair setup. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Resources: Investigation Guide] |None |207
 
 |<<potential-etherhiding-c2-via-blockchain-connection, Potential Etherhiding C2 via Blockchain Connection>> |Detects when a scripting interpreter makes an outbound network connection to an Ethereum blockchain endpoint for command and control purposes. Adversaries may leverage Ethereum blockchain infrastructure as a covert C2 channel to receive commands and exfiltrate data, as observed in campaigns like SleepyDuck malware. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2
 
@@ -2050,7 +2092,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-execution-of-rc-local-script, Potential Execution of rc.local Script>> |This rule detects the potential execution of the "/etc/rc.local" script through the "already_running" event action created by the "rc-local.service" systemd service. The "/etc/rc.local" script is a legacy initialization script that is executed at the end of the boot process. The "/etc/rc.local" script is not enabled by default on most Linux distributions. The "/etc/rc.local" script can be used by attackers to persistently execute malicious commands or scripts on a compromised system at reboot. As the rc.local file is executed prior to the initialization of Elastic Defend, the execution event is not ingested, and therefore the "already_running" event is leveraged to provide insight into the potential execution of "rc.local". |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |7
 
-|<<potential-execution-via-filefix-phishing-attack, Potential Execution via FileFix Phishing Attack>> |Identifies the execution of Windows commands or downloaded files via the browser's dialog box. Adversaries may use phishing to instruct the victim to copy and paste malicious commands for execution via crafted phsihing web pages. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Initial Access], [Tactic: Defense Evasion], [Data Source: Windows Security Event Logs], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Resources: Investigation Guide] |None |3
+|<<potential-execution-via-filefix-phishing-attack, Potential Execution via FileFix Phishing Attack>> |Identifies the execution of Windows commands or downloaded files via the browser's dialog box. Adversaries may use phishing to instruct the victim to copy and paste malicious commands for execution via crafted phishing web pages. |[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], [Resources: Investigation Guide] |None |4
 
 |<<potential-execution-via-ssh-backdoor, Potential Execution via SSH Backdoor>> |It identifies potential malicious shell executions through remote SSH and detects cases where the sshd service suddenly terminates soon after successful execution, suggesting suspicious behavior similar to the XZ backdoor. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Persistence], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |11
 
@@ -2058,7 +2100,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-external-linux-ssh-brute-force-detected, Potential External Linux SSH Brute Force Detected>> |Identifies multiple external consecutive login failures targeting a user account from the same source address within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to these accounts. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |11
 
-|<<potential-fake-captcha-phishing-attack, Potential Fake CAPTCHA Phishing Attack>> |Identifies potential fake CAPTCHA phishing attack based on PowerShell or Cmd argument values. Adversaries employ this technique via compromised websites with browser injects, posing either as fake CAPTCHAs to access the site or as a page loading error requiring a fix to display the page. The victim is instructed to copy and past a malicious command to the Windows Run dialog box. |[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], [Resources: Investigation Guide] |None |3
+|<<potential-fake-captcha-phishing-attack, Potential Fake CAPTCHA Phishing Attack>> |Identifies potential fake CAPTCHA phishing attacks based on PowerShell, Cmd, or Mshta command-line values. Adversaries employ this technique via compromised websites with browser injects, posing either as fake CAPTCHAs to access the site or as a page loading error requiring a fix to display the page. The victim is instructed to copy and paste a malicious command to the Windows Run dialog box. |[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], [Resources: Investigation Guide] |None |4
 
 |<<potential-file-download-via-a-headless-browser, Potential File Download via a Headless Browser>> |Identifies headless browser execution from a suspicious parent process with arguments consistent with scripted retrieval. Adversaries use browsers because they are trusted, signed binaries that proxy and application-control policies allow through, bypassing restrictions on direct download tools. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Windows], [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], [Data Source: Crowdstrike] |None |209
 
@@ -2066,7 +2108,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-file-transfer-via-curl-for-windows, Potential File Transfer via Curl for Windows>> |Identifies Curl for Windows making an HTTP request. Adversaries could abuse Curl to download files or upload data to a remote URL. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Data Source: Sysmon], [Resources: Investigation Guide] |None |8
 
-|<<potential-foxmail-exploitation, Potential Foxmail Exploitation>> |Identifies the Foxmail client spawning a child process with argument pointing to the Foxmail temp directory. This may indicate the successful exploitation of a Foxmail vulnerability for initial access and execution via a malicious email. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Windows Security Event Logs], [Data Source: Elastic Endgame], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |208
+|<<potential-foxmail-exploitation, Potential Foxmail Exploitation>> |Identifies the Foxmail client spawning a child process with arguments pointing to user-profile AppData paths or remote shares. This may indicate exploitation of a Foxmail vulnerability for initial access and execution via a malicious email. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Windows Security Event Logs], [Data Source: Elastic Endgame], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |209
 
 |<<potential-git-cve-2025-48384-exploitation, Potential Git CVE-2025-48384 Exploitation>> |This rule detects potential exploitation of CVE-2025-48384 via Git. This vulnerability allows attackers to execute arbitrary code by leveraging Git's recursive clone feature to fetch and execute malicious scripts from a remote repository. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |2
 
@@ -2130,7 +2172,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-machine-account-relay-attack-via-smb, Potential Machine Account Relay Attack via SMB>> |Identifies potential relay attacks against a machine account by identifying network share access events coming from a remote source.ip but using the target server computer account. This may indicate an SMB relay attack. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |4
 
-|<<potential-malicious-powershell-based-on-alert-correlation, Potential Malicious PowerShell Based on Alert Correlation>> |Identifies PowerShell script blocks linked to multiple distinct PowerShell detections via the same ScriptBlock ID, indicating compound suspicious behavior. Attackers often chain obfuscation, decoding, and execution within a single script block. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |5
+|<<potential-malicious-powershell-based-on-alert-correlation, Potential Malicious PowerShell Based on Alert Correlation>> |Identifies PowerShell script blocks linked to multiple distinct PowerShell detections via the same ScriptBlock ID, indicating compound suspicious behavior. Attackers often chain obfuscation, decoding, and execution within a single script block. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |7
 
 |<<potential-malware-driven-ssh-brute-force-attempt, Potential Malware-Driven SSH Brute Force Attempt>> |This detection identifies a Linux host that has potentially been infected with malware and is being used to conduct brute-force attacks against external systems over SSH (port 22 and common alternative SSH ports). The detection looks for a high volume of outbound connection attempts to non-private IP addresses from a single process. A compromised host may be part of a botnet or controlled by an attacker, attempting to gain unauthorized access to remote systems. This behavior is commonly observed in SSH brute-force campaigns where malware hijacks vulnerable machines to expand its attack surface. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Impact], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |13
 
@@ -2152,7 +2194,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-microsoft-office-sandbox-evasion, Potential Microsoft Office Sandbox Evasion>> |Identifies the creation of a suspicious zip file prepended with special characters. Sandboxed Microsoft Office applications on macOS are allowed to write files that start with special characters, which can be combined with an AutoStart location to achieve sandbox evasion. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |111
 
-|<<potential-modification-of-accessibility-binaries, Potential Modification of Accessibility Binaries>> |Windows contains accessibility features that may be launched with a key combination before a user has logged in. An adversary can modify the way these programs are launched to get a command prompt or backdoor without logging in to the system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR] |None |217
+|<<potential-modification-of-accessibility-binaries, Potential Modification of Accessibility Binaries>> |Windows contains accessibility features that may be launched with a key combination before a user has logged in. An adversary can modify the way these programs are launched to get a command prompt or backdoor without logging in to the system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR] |None |218
 
 |<<potential-ntlm-relay-attack-against-a-computer-account, Potential NTLM Relay Attack against a Computer Account>> |Detects potential relay attacks by identifying coercion attempts followed by authentication events using a target server's computer account, originating from a different host. This may indicate that an attacker has captured and relayed the server's computer account hash to execute code on behalf of the compromised system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |2
 
@@ -2166,7 +2208,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-network-sweep-detected, Potential Network Sweep Detected>> |This rule identifies a potential network sweep. A network sweep is a method used by attackers to scan a target network, identifying active hosts, open ports, and available services to gather information on vulnerabilities and weaknesses. This reconnaissance helps them plan subsequent attacks and exploit potential entry points for unauthorized access, data theft, or other malicious activities. This rule defines a threshold-based approach to detect multiple connection attempts from a single host to numerous destination hosts over commonly used network services. |[Domain: Network], [Tactic: Discovery], [Tactic: Reconnaissance], [Use Case: Network Security Monitoring], [Data Source: PAN-OS], [Resources: Investigation Guide] |None |15
 
-|<<potential-notepad-markdown-rce-exploitation, Potential Notepad Markdown RCE Exploitation>> |Identifies a process started by Notepad after opening a Markdown file. This may indicate successful exploitation of a Notepad markdown parsing vulnerability (CVE-2026-20841) that can lead to arbitrary code execution. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |4
+|<<potential-notepad-markdown-rce-exploitation, Potential Notepad Markdown RCE Exploitation>> |Identifies a process started by Notepad after opening a Markdown file. This may indicate successful exploitation of a Notepad markdown parsing vulnerability (CVE-2026-20841) that can lead to arbitrary code execution. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |5
 
 |<<potential-okta-brute-force-device-token-rotation, Potential Okta Brute Force (Device Token Rotation)>> |Detects potential brute force attacks against a single Okta user account where excessive unique device token hashes are generated, indicating automated tooling that fails to persist browser cookies between attempts. |[Domain: Identity], [Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |212
 
@@ -2204,7 +2246,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-port-scanning-activity-from-compromised-host, Potential Port Scanning Activity from Compromised Host>> |This rule detects potential port scanning activity from a compromised host. Port scanning is a common reconnaissance technique used by attackers to identify open ports and services on a target system. A compromised host may exhibit port scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable services, or prepare for further exploitation. This rule identifies potential port scanning activity by monitoring network connection attempts from a single host to a large number of ports within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |13
 
-|<<potential-powershell-hacktool-script-by-author, Potential PowerShell HackTool Script by Author>> |Identifies PowerShell script block content containing known offensive-tool author handles or attribution strings (for example, public tool author names). Attackers often run public PowerShell tooling with minimal changes, leaving author artifacts in comments or headers. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |109
+|<<potential-powershell-hacktool-script-by-author, Potential PowerShell HackTool Script by Author>> |Identifies PowerShell script block content containing known offensive-tool author handles or attribution strings (for example, public tool author names). Attackers often run public PowerShell tooling with minimal changes, leaving author artifacts in comments or headers. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |110
 
 |<<potential-powershell-hacktool-script-by-function-names, Potential PowerShell HackTool Script by Function Names>> |Detects PowerShell scripts containing function names and helpers from common offensive frameworks and tools used for discovery, credential access, injection, persistence, and exfiltration. Attackers often reuse these public functions with minimal changes, leaving recognizable function-name artifacts. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |221
 
@@ -2246,25 +2288,29 @@ and their rule type is `machine_learning`.
 
 |<<potential-privilege-escalation-via-enlightenment, Potential Privilege Escalation via Enlightenment>> |Identifies an attempt to exploit a local privilege escalation CVE-2022-37706 via a flaw in Linux window manager package Enlightenment. enlightenment_sys in Enlightenment before 0.25.4 allows local users to gain privileges because it is setuid root, and the system library function mishandles pathnames that begin with a /dev/.. substring. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |7
 
-|<<potential-privilege-escalation-via-installerfiletakeover, Potential Privilege Escalation via InstallerFileTakeOver>> |Identifies a potential exploitation of InstallerTakeOver (CVE-2021-41379) default PoC execution. Successful exploitation allows an unprivileged user to escalate privileges to SYSTEM. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide], [Use Case: Vulnerability], [Data Source: Elastic Defend] |None |115
+|<<potential-privilege-escalation-via-installerfiletakeover, Potential Privilege Escalation via InstallerFileTakeOver>> |Identifies a potential exploitation of InstallerTakeOver (CVE-2021-41379) default PoC execution. Successful exploitation allows an unprivileged user to escalate privileges to SYSTEM. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide], [Use Case: Vulnerability], [Data Source: Elastic Defend] |None |116
 
 |<<potential-privilege-escalation-via-linux-dac-permissions, Potential Privilege Escalation via Linux DAC permissions>> |Identifies potential privilege escalation exploitation of DAC (Discretionary access control) file permissions. The rule identifies exploitation of DAC checks on sensitive file paths via suspicious processes whose capabilities include CAP_DAC_OVERRIDE (where a process can bypass all read write and execution checks) or CAP_DAC_READ_SEARCH (where a process can read any file or perform any executable permission on the directories). |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |8
 
-|<<potential-privilege-escalation-via-overlayfs, Potential Privilege Escalation via OverlayFS>> |Identifies an attempt to exploit a local privilege escalation (CVE-2023-2640 and CVE-2023-32629) via a flaw in Ubuntu's modifications to OverlayFS. These flaws allow the creation of specialized executables, which, upon execution, grant the ability to escalate privileges to root on the affected machine. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |10
-
 |<<potential-privilege-escalation-via-pkexec, Potential Privilege Escalation via PKEXEC>> |Identifies an attempt to exploit a local privilege escalation in polkit pkexec (CVE-2021-4034) via unsecure environment variable injection. Successful exploitation allows an unprivileged user to escalate to the root user. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |213
 
 |<<potential-privilege-escalation-via-python-cap-setuid, Potential Privilege Escalation via Python cap_setuid>> |This detection rule monitors for the execution of a system command with setuid or setgid capabilities via Python, followed by a uid or gid change to the root user. This sequence of events may indicate successful privilege escalation. Setuid (Set User ID) and setgid (Set Group ID) are Unix-like OS features that enable processes to run with elevated privileges, based on the file owner or group. Threat actors can exploit these attributes to escalate privileges to the privileges that are set on the binary that is being executed. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |9
 
 |<<potential-privilege-escalation-via-recently-compiled-executable, Potential Privilege Escalation via Recently Compiled Executable>> |This rule monitors a sequence involving a program compilation event followed by its execution and a subsequent alteration of UID permissions to root privileges. This behavior can potentially indicate the execution of a kernel or software privilege escalation exploit. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |10
 
+|<<potential-privilege-escalation-via-suid-sgid, Potential Privilege Escalation via SUID/SGID>> |Detects potential privilege escalation under the root effective user when the real user and parent user are not root, indicative of the execution of binaries with SUID or SGID bits set. |[Data Source: Elastic Defend], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1
+
 |<<potential-privilege-escalation-via-suid-sgid-proxy-execution, Potential Privilege Escalation via SUID/SGID Proxy Execution>> |Detects potential privilege escalation via SUID/SGID proxy execution on Linux systems. Attackers may exploit binaries with the SUID/SGID bit set to execute commands with elevated privileges. This rule identifies instances where a process is executed with root privileges (user ID 0 or group ID 0) while the real user or group ID is non-root, indicating potential misuse of SUID/SGID binaries. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |3
 
 |<<potential-privilege-escalation-via-service-imagepath-modification, Potential Privilege Escalation via Service ImagePath Modification>> |Identifies registry modifications to default services that could enable privilege escalation to SYSTEM. Attackers with privileges from groups like Server Operators may change the ImagePath of services to executables under their control or to execute commands. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Crowdstrike], [Resources: Investigation Guide], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Elastic Endgame] |None |110
 
 |<<potential-privilege-escalation-via-sudoers-file-modification, Potential Privilege Escalation via Sudoers File Modification>> |A sudoers file specifies the commands users or groups can run and from which terminals. Adversaries can take advantage of these configurations to execute commands as other users or spawn processes with higher privileges. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |108
 
-|<<potential-privileged-escalation-via-samaccountname-spoofing, Potential Privileged Escalation via SamAccountName Spoofing>> |Identifies a suspicious computer account name rename event, which may indicate an attempt to exploit CVE-2021-42278 to elevate privileges from a standard domain user to a user with domain admin privileges. CVE-2021-42278 is a security vulnerability that allows potential attackers to impersonate a domain controller via samAccountName attribute spoofing. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Use Case: Vulnerability], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |215
+|<<potential-privilege-escalation-via-unshare-followed-by-root-process, Potential Privilege Escalation via unshare Followed by Root Process>> |Detects a short sequence where a non-root user performs unshare-related namespace activity (often associated with user namespace privilege escalation primitives) and then a root process is executed shortly after. This can indicate a successful local privilege escalation attempt or suspicious namespace manipulation captured in Auditd Manager telemetry. |[Data Source: Auditd Manager], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1
+
+|<<potential-privilege-escalation-via-unshare-and-uid-change, Potential Privilege Escalation via unshare and UID Change>> |Identifies potentially suspicious use of unshare to create a user namespace context followed by a UID change event indicating a transition to root. Adversaries may use unshare-based primitives as part of local privilege escalation chains. This rule is intentionally generic and can surface multiple local privesc patterns beyond a single CVE. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |11
+
+|<<potential-privileged-escalation-via-samaccountname-spoofing, Potential Privileged Escalation via SamAccountName Spoofing>> |Identifies a suspicious computer account name rename event, which may indicate an attempt to exploit CVE-2021-42278 to elevate privileges from a standard domain user to a user with domain admin privileges. CVE-2021-42278 is a security vulnerability that allows potential attackers to impersonate a domain controller via samAccountName attribute spoofing. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Use Case: Vulnerability], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |216
 
 |<<potential-process-injection-from-malicious-document, Potential Process Injection from Malicious Document>> |Identifies child processes of frequently targeted Microsoft Office applications (Word, PowerPoint, Excel) with unusual process arguments and path. This behavior is often observed during exploitation of Office applications or from documents with malicious macros. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Privilege Escalation], [Tactic: Initial Access], [Rule Type: BBR], [Data Source: Elastic Defend] |None |4
 
@@ -2284,11 +2330,11 @@ and their rule type is `machine_learning`.
 
 |<<potential-ransomware-behavior-note-files-by-system, Potential Ransomware Behavior - Note Files by System>> |This rule identifies the creation of multiple files with same name and over SMB by the same user. This behavior may indicate the successful remote execution of a ransomware dropping file notes to different folders. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |216
 
-|<<potential-ransomware-note-file-dropped-via-smb, Potential Ransomware Note File Dropped via SMB>> |Identifies an incoming SMB connection followed by the creation of a file with a name similar to ransomware note files. This may indicate a remote ransomware attack via the SMB protocol. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |7
+|<<potential-ransomware-note-file-dropped-via-smb, Potential Ransomware Note File Dropped via SMB>> |Identifies an incoming SMB connection followed by the creation of a file with a name similar to ransomware note files. This may indicate a remote ransomware attack via the SMB protocol. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |8
 
 |<<potential-remote-credential-access-via-registry, Potential Remote Credential Access via Registry>> |Identifies remote access to the registry to potentially dump credential data from the Security Account Manager (SAM) registry hive in preparation for credential access and privileges elevation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |114
 
-|<<potential-remote-desktop-shadowing-activity, Potential Remote Desktop Shadowing Activity>> |Identifies the modification of the Remote Desktop Protocol (RDP) Shadow registry or the execution of processes indicative of an active RDP shadowing session. An adversary may abuse the RDP Shadowing feature to spy on or control other users active RDP sessions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |315
+|<<potential-remote-desktop-shadowing-activity, Potential Remote Desktop Shadowing Activity>> |Identifies the modification of the Remote Desktop Protocol (RDP) Shadow registry or the execution of processes indicative of an active RDP shadowing session. An adversary may abuse the RDP Shadowing feature to spy on or control other users active RDP sessions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |316
 
 |<<potential-remote-desktop-tunneling-detected, Potential Remote Desktop Tunneling Detected>> |Identifies potential use of an SSH utility to establish RDP over an SSH Tunnel. This can be used by attackers to enable routing of network packets that would otherwise not reach their intended destination. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Lateral Movement], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Windows Security Event Logs], [Data Source: Crowdstrike], [Data Source: Sysmon] |None |421
 
@@ -2306,7 +2352,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-reverse-shell-via-child, Potential Reverse Shell via Child>> |This detection rule identifies suspicious network traffic patterns associated with TCP reverse shell activity. This activity consists of a network event that is followed by the creation of a shell process with suspicious command line arguments. An attacker may establish a Linux TCP reverse shell to gain remote access to a target system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |9
 
-|<<potential-reverse-shell-via-java, Potential Reverse Shell via Java>> |This detection rule identifies the execution of a Linux shell process from a Java JAR application post an incoming network connection. This behavior may indicate reverse shell activity via a Java application. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |13
+|<<potential-reverse-shell-via-java, Potential Reverse Shell via Java>> |This detection rule identifies the execution of a Linux shell process from a Java JAR application post an incoming network connection. This behavior may indicate reverse shell activity via a Java application. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |14
 
 |<<potential-reverse-shell-via-suspicious-binary, Potential Reverse Shell via Suspicious Binary>> |This detection rule detects the creation of a shell through a chain consisting of the execution of a suspicious binary (located in a commonly abused location or executed manually) followed by a network event and ending with a shell being spawned. Stageless reverse tcp shells display this behaviour. Attackers may spawn reverse shells to establish persistence onto a target system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |13
 
@@ -2332,7 +2378,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-shadow-file-read-via-command-line-utilities, Potential Shadow File Read via Command Line Utilities>> |Identifies access to the /etc/shadow file via the commandline using standard system utilities. After elevating privileges to root, threat actors may attempt to read or dump this file in order to gain valid credentials. They may utilize these to move laterally undetected and access additional resources. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Credential Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |213
 
-|<<potential-sharprdp-behavior, Potential SharpRDP Behavior>> |Identifies potential behavior of SharpRDP, which is a tool that can be used to perform authenticated command execution against a remote target via Remote Desktop Protocol (RDP) for the purposes of lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |112
+|<<potential-sharprdp-behavior, Potential SharpRDP Behavior>> |Identifies potential behavior of SharpRDP, which is a tool that can be used to perform authenticated command execution against a remote target via Remote Desktop Protocol (RDP) for the purposes of lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |113
 
 |<<potential-shell-via-wildcard-injection-detected, Potential Shell via Wildcard Injection Detected>> |This rule monitors for the execution of a set of linux binaries, that are potentially vulnerable to wildcard injection, with suspicious command line flags followed by a shell spawn event. Linux wildcard injection is a type of security vulnerability where attackers manipulate commands or input containing wildcards (e.g., *, ?, []) to execute unintended operations or access sensitive data by tricking the system into interpreting the wildcard characters in unexpected ways. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |113
 
@@ -2352,7 +2398,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-suspicious-file-edit, Potential Suspicious File Edit>> |This rule monitors for the potential edit of a suspicious file. In Linux, when editing a file through an editor, a temporary .swp file is created. By monitoring for the creation of this .swp file, we can detect potential file edits of suspicious files. The execution of this rule is not a clear sign of the file being edited, as just opening the file through an editor will trigger this event. Attackers may alter any of the files added in this rule to establish persistence, escalate privileges or perform reconnaisance on the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |110
 
-|<<potential-system-tampering-via-file-modification, Potential System Tampering via File Modification>> |Identifies attempts to delete or modify critical files used during the boot process to prevent the system from booting. This may indicate a destructive attack behavior. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Impact], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |4
+|<<potential-system-tampering-via-file-modification, Potential System Tampering via File Modification>> |Identifies attempts to delete or modify critical files used during the boot process to prevent the system from booting. This may indicate a destructive attack behavior. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne] |None |5
 
 |<<potential-thc-tool-downloaded, Potential THC Tool Downloaded>> |Identifies processes that are capable of downloading files with command line arguments containing URLs to SSH-IT's autonomous SSH worm. This worm intercepts outgoing SSH connections every time a user uses ssh. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |109
 
@@ -2386,9 +2432,11 @@ and their rule type is `machine_learning`.
 
 |<<potential-windows-session-hijacking-via-ccmexec, Potential Windows Session Hijacking via CcmExec>> |This detection rule identifies when 'SCNotification.exe' loads an untrusted DLL, which is a potential indicator of an attacker attempt to hijack/impersonate a Windows user session. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6
 
-|<<potential-macos-ssh-brute-force-detected, Potential macOS SSH Brute Force Detected>> |Identifies a high number (20) of macOS SSH KeyGen process executions from the same host. An adversary may attempt a brute force attack to obtain unauthorized access to user accounts. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |112
+|<<potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940, Potential cPanel WHM CRLF Authentication Bypass (CVE-2026-41940)>> |Identifies the network signature of CVE-2026-41940, a pre-auth root-level authentication bypass in cPanel and WebHost Manager (WHM) caused by a CRLF injection in the session writer. The exploit-inherent shape on the wire is a `GET /` request to a cPanel/WHM admin port (typically TCP/2087, 2086, 2083, 2082, 2095, 2096) carrying an `Authorization: Basic` header whose base64-decoded value contains CRLF-injected session fields, which causes cpsrvd to respond with a 3xx redirect whose `Location` header leaks a `/cpsessNNNNNNNNNN` token granting the attacker a privileged session. This is the network-layer equivalent of the cPanel `access_log` artifact identified by Unfold and watchTowr as the first bulletproof detection for this CVE: a `GET /` recorded with `auth_method=b` (HTTP Basic). Legitimate access to `GET /` on a WHM admin port returns 200 with the login screen and never includes HTTP Basic credentials, so this combination is not produced by normal use. |[Domain: Network], [Domain: Application], [Domain: Web], [Use Case: Threat Detection], [Use Case: Vulnerability], [Tactic: Initial Access], [Data Source: Network Packet Capture], [Data Source: Network Traffic], [Resources: Investigation Guide] |None |1
+
+|<<potential-macos-ssh-brute-force-detected, Potential macOS SSH Brute Force Detected>> |Identifies a high number of inbound SSH login attempts on a macOS host within a short time window. On macOS, each inbound SSH authentication attempt spawns the sshd-keygen-wrapper process once, whether the login succeeds or fails. Adversaries may perform password brute force or password spraying against exposed SSH services to obtain unauthorized access. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |113
 
-|<<potential-privilege-escalation-via-cve-2022-38028, Potential privilege escalation via CVE-2022-38028>> |Identifies a privilege escalation attempt via exploiting CVE-2022-38028 to hijack the print spooler service execution. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |210
+|<<potential-privilege-escalation-via-cve-2022-38028, Potential privilege escalation via CVE-2022-38028>> |Identifies a potential privilege escalation attempt via CVE-2022-38028 through modification of the protected Print to PDF MPDW constraints script. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |211
 
 |<<potential-snap-confine-privilege-escalation-via-cve-2026-3888, Potential snap-confine Privilege Escalation via CVE-2026-3888>> |This rule detects non-root file creation within "/tmp/.snap" or its host backing path "/tmp/snap-private-tmp/*/tmp/.snap", which may indicate exploitation attempts related to CVE-2026-3888. In vulnerable Ubuntu systems, the snap-confine utility normally creates the "/tmp/.snap" directory as root when initializing a snap sandbox. The vulnerability arises when systemd-tmpfiles deletes this directory after it becomes stale, allowing an unprivileged user to recreate it and populate attacker-controlled files. During subsequent snap sandbox initialization, snap-confine may bind-mount or trust these attacker-controlled paths, enabling manipulation of libraries or configuration files that can lead to local privilege escalation to root. Because legitimate creation of ".snap" directories should only be performed by root, non-root file activity in these locations is highly suspicious. This detection helps identify early stages of the exploit before privilege escalation is completed. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Use Case: Vulnerability], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2
 
@@ -2410,7 +2458,7 @@ and their rule type is `machine_learning`.
 
 |<<powershell-obfuscation-via-negative-index-string-reversal, PowerShell Obfuscation via Negative Index String Reversal>> |Detects PowerShell scripts that uses negative index ranges (for example, $var[-1..0]) to reverse strings or arrays and rebuild content at runtime. Attackers use index reversal to reconstruct hidden commands or payloads and evade static analysis and AMSI. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |10
 
-|<<powershell-psreflect-script, PowerShell PSReflect Script>> |Detects PowerShell scripts that implements PSReflect-style helpers (for example, Add-Win32Type, New-InMemoryModule, or DllImport patterns) for dynamic Win32 API invocation. Attackers use PSReflect to call native APIs from PowerShell for execution, injection, or privilege manipulation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |317
+|<<powershell-psreflect-script, PowerShell PSReflect Script>> |Detects PowerShell script block content containing PSReflect-style helper indicators, such as Add-Win32Type, New-InMemoryModule, or DllImport patterns, that may support dynamic Win32 API invocation from PowerShell. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |318
 
 |<<powershell-script-block-logging-disabled, PowerShell Script Block Logging Disabled>> |Detects registry changes that disable PowerShell Script Block Logging. Attackers may disable this logging to conceal their activities in the host and evade detection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |317
 
@@ -2452,15 +2500,15 @@ and their rule type is `machine_learning`.
 
 |<<privilege-escalation-via-gdb-cap-sys-ptrace, Privilege Escalation via GDB CAP_SYS_PTRACE>> |Identifies instances where GDB (granted the CAP_SYS_PTRACE capability) is executed, after which the user's access is elevated to UID/GID 0 (root). In Linux, the CAP_SYS_PTRACE capability grants a process the ability to use the ptrace system call, which is typically used for debugging and allows the process to trace and control other processes. Attackers may leverage this capability to hook and inject into a process that is running with root permissions in order to escalate their privileges to root. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |7
 
-|<<privilege-escalation-via-named-pipe-impersonation, Privilege Escalation via Named Pipe Impersonation>> |Identifies a privilege escalation attempt via named pipe impersonation. An adversary may abuse this technique by utilizing a framework such Metasploit's meterpreter getsystem command. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |318
+|<<privilege-escalation-via-named-pipe-impersonation, Privilege Escalation via Named Pipe Impersonation>> |Identifies a privilege escalation attempt via named pipe impersonation. An adversary may abuse this technique by utilizing a framework such as Metasploit's meterpreter getsystem command. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |319
 
-|<<privilege-escalation-via-rogue-named-pipe-impersonation, Privilege Escalation via Rogue Named Pipe Impersonation>> |Identifies a privilege escalation attempt via rogue named pipe impersonation. An adversary may abuse this technique by masquerading as a known named pipe and manipulating a privileged process to connect to it. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Sysmon], [Resources: Investigation Guide] |None |211
+|<<privilege-escalation-via-rogue-named-pipe-impersonation, Privilege Escalation via Rogue Named Pipe Impersonation>> |Identifies a privilege escalation attempt via rogue named pipe impersonation. An adversary may abuse this technique by masquerading as a known named pipe and manipulating a privileged process to connect to it. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Sysmon], [Resources: Investigation Guide] |None |212
 
 |<<privilege-escalation-via-root-crontab-file-modification, Privilege Escalation via Root Crontab File Modification>> |Identifies modifications to the root crontab file. Adversaries may overwrite this file to gain code execution with root privileges by exploiting privileged file write or move related vulnerabilities. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |110
 
 |<<privilege-escalation-via-suid-sgid, Privilege Escalation via SUID/SGID>> |Identifies instances where a process is executed with user/group ID 0 (root), and a real user/group ID that is not 0. This is indicative of a process that has been granted SUID/SGID permissions, allowing it to run with elevated privileges. Attackers may leverage a misconfiguration for exploitation in order to escalate their privileges to root, or establish a backdoor for persistence. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |112
 
-|<<privilege-escalation-via-windir-environment-variable, Privilege Escalation via Windir Environment Variable>> |Identifies a privilege escalation attempt via a rogue Windows directory (Windir) environment variable. This is a known primitive that is often combined with other vulnerabilities to elevate privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |315
+|<<privilege-escalation-via-windir-environment-variable, Privilege Escalation via Windir Environment Variable>> |Identifies a privilege escalation attempt via a rogue Windows directory (Windir) environment variable. This is a known primitive that is often combined with other vulnerabilities to elevate privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |316
 
 |<<privileged-accounts-brute-force, Privileged Accounts Brute Force>> |Identifies multiple consecutive logon failures targeting more than one Admin account from the same source address and within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs] |None |119
 
@@ -2468,7 +2516,7 @@ and their rule type is `machine_learning`.
 
 |<<privileged-docker-container-creation, Privileged Docker Container Creation>> |This rule leverages the new_terms rule type to identify the creation of a potentially unsafe docker container from an unusual parent process. Attackers can use the "--privileged" flag to create containers with escalated privileges, which can lead to trivial privilege escalation, docker escaping and persistence. access. |[Domain: Endpoint], [Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |7
 
-|<<privileges-elevation-via-parent-process-pid-spoofing, Privileges Elevation via Parent Process PID Spoofing>> |Identifies parent process spoofing used to create an elevated child process. Adversaries may spoof the parent process identifier (PPID) of a new process to evade process-monitoring defenses or to elevate privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |11
+|<<privileges-elevation-via-parent-process-pid-spoofing, Privileges Elevation via Parent Process PID Spoofing>> |Identifies parent process spoofing used to create an elevated child process. Adversaries may spoof the parent process identifier (PPID) of a new process to evade process-monitoring defenses or to elevate privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |12
 
 |<<process-activity-via-compiled-html-file, Process Activity via Compiled HTML File>> |Compiled HTML files (.chm) are commonly distributed as part of the Microsoft HTML Help system. Adversaries may conceal malicious code in a CHM file and deliver it to a victim for execution. CHM content is loaded by the HTML Help executable program (hh.exe). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |319
 
@@ -2480,7 +2528,7 @@ and their rule type is `machine_learning`.
 
 |<<process-created-with-a-duplicated-token, Process Created with a Duplicated Token>> |Identifies the creation of a process impersonating the token of another user logon session. Adversaries may create a new process with a different token to escalate privileges and bypass access controls. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |7
 
-|<<process-created-with-an-elevated-token, Process Created with an Elevated Token>> |Identifies the creation of a process running as SYSTEM and impersonating a Windows core binary privileges. Adversaries may create a new process with a different token to escalate privileges and bypass access controls. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |11
+|<<process-created-with-an-elevated-token, Process Created with an Elevated Token>> |Identifies the creation of a process running as SYSTEM while impersonating the token context of a Windows core binary. Adversaries may create a new process with a different token to escalate privileges and bypass access controls. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |12
 
 |<<process-creation-via-secondary-logon, Process Creation via Secondary Logon>> |Identifies process creation with alternate credentials. Adversaries may create a new process with a different token to escalate privileges and bypass access controls. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |116
 
@@ -2564,7 +2612,7 @@ and their rule type is `machine_learning`.
 
 |<<registry-persistence-via-appinit-dll, Registry Persistence via AppInit DLL>> |AppInit DLLs are dynamic-link libraries (DLLs) that are loaded into every process that creates a user interface (loads user32.dll) on Microsoft Windows operating systems. The AppInit DLL mechanism is used to load custom code into user-mode processes, allowing for the customization of the user interface and the behavior of Windows-based applications. Attackers who add those DLLs to the registry locations can execute code with elevated privileges, similar to process injection, and provide a solid and constant persistence on the machine. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |317
 
-|<<remote-computer-account-dnshostname-update, Remote Computer Account DnsHostName Update>> |Identifies the remote update to a computer account's DnsHostName attribute. If the new value set is a valid domain controller DNS hostname and the subject computer name is not a domain controller, then it's highly likely a preparation step to exploit CVE-2022-26923 in an attempt to elevate privileges from a standard domain user to domain admin privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Use Case: Vulnerability], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |214
+|<<remote-computer-account-dnshostname-update, Remote Computer Account DnsHostName Update>> |Identifies the remote update to a computer account's DnsHostName attribute. If the new value set is a valid domain controller DNS hostname and the subject computer name is not a domain controller, then it's highly likely a preparation step to exploit CVE-2022-26923 in an attempt to elevate privileges from a standard domain user to domain admin privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Use Case: Vulnerability], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |215
 
 |<<remote-desktop-enabled-in-windows-firewall-by-netsh, Remote Desktop Enabled in Windows Firewall by Netsh>> |Identifies use of the network shell utility (netsh.exe) to enable inbound Remote Desktop Protocol (RDP) connections in the Windows Firewall. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |318
 
@@ -2644,7 +2692,7 @@ and their rule type is `machine_learning`.
 
 |<<scheduled-tasks-at-command-enabled, Scheduled Tasks AT Command Enabled>> |Identifies attempts to enable the Windows scheduled tasks AT command via the registry. Attackers may use this method to move laterally or persist locally. The AT command has been deprecated since Windows 8 and Windows Server 2012, but still exists for backwards compatibility. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |316
 
-|<<screenconnect-server-spawning-suspicious-processes, ScreenConnect Server Spawning Suspicious Processes>> |Identifies suspicious processes being spawned by the ScreenConnect server process (ScreenConnect.Service.exe). This activity may indicate exploitation activity or access to an existing web shell backdoor. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |210
+|<<screenconnect-server-spawning-suspicious-processes, ScreenConnect Server Spawning Suspicious Processes>> |Identifies suspicious processes being spawned by the ScreenConnect server process (ScreenConnect.Service.exe). This activity may indicate exploitation activity or access to an existing web shell backdoor. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |211
 
 |<<screensaver-plist-file-modified-by-unexpected-process, Screensaver Plist File Modified by Unexpected Process>> |Identifies when a screensaver plist file is modified by an unexpected process. An adversary can maintain persistence on a macOS endpoint by creating a malicious screensaver (.saver) file and configuring the screensaver plist file to execute code each time the screensaver is activated. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |113
 
@@ -2668,7 +2716,7 @@ and their rule type is `machine_learning`.
 
 |<<sensitive-file-access-followed-by-compression, Sensitive File Access followed by Compression>> |Detects when a sensitive file is accessed followed by the immediate creation of a compressed file in a suspicious location. This activity can indicate an attempt to collect sensitive local data and stage it for exfiltration. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Collection], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2
 
-|<<sensitive-files-compression, Sensitive Files Compression>> |Identifies the use of a compression utility to collect known files containing sensitive information, such as credentials and system configurations. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Collection], [Tactic: Credential Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Auditd Manager], [Resources: Investigation Guide] |None |214
+|<<sensitive-files-compression, Sensitive Files Compression>> |Identifies the use of a compression utility to collect known files containing sensitive information, such as credentials and system configurations. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Collection], [Tactic: Credential Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Auditd Manager], [Resources: Investigation Guide] |None |215
 
 |<<sensitive-files-compression-inside-a-container, Sensitive Files Compression Inside A Container>> |Identifies the use of a compression utility to collect known files containing sensitive information, such as credentials and system configurations inside a container. |[Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Collection], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |4
 
@@ -2688,7 +2736,7 @@ and their rule type is `machine_learning`.
 
 |<<service-control-spawned-via-script-interpreter, Service Control Spawned via Script Interpreter>> |Identifies Service Control (sc.exe) spawning from script interpreter processes to create, modify, or start services. This can potentially indicate an attempt to elevate privileges or maintain persistence. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike] |None |220
 
-|<<service-creation-via-local-kerberos-authentication, Service Creation via Local Kerberos Authentication>> |Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to localhost, followed by a sevice creation from the same LogonId. This may indicate an attempt to leverage a Kerberos relay attack variant that can be used to elevate privilege locally from a domain joined user to local System privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Credential Access], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |213
+|<<service-creation-via-local-kerberos-authentication, Service Creation via Local Kerberos Authentication>> |Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to localhost, followed by service creation from the same LogonId. This may indicate an attempt to leverage a Kerberos relay attack variant that can elevate privileges locally from a domain-joined user to LocalSystem privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |214
 
 |<<service-dacl-modification-via-sc-exe, Service DACL Modification via sc.exe>> |Identifies DACL modifications to deny access to a service, making it unstoppable, or hide it from system and users. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike] |None |209
 
@@ -2838,7 +2886,7 @@ and their rule type is `machine_learning`.
 
 |<<suspicious-child-process-of-adobe-acrobat-reader-update-service, Suspicious Child Process of Adobe Acrobat Reader Update Service>> |Detects attempts to exploit privilege escalation vulnerabilities related to the Adobe Acrobat Reader PrivilegedHelperTool responsible for installing updates. For more information, refer to CVE-2020-9615, CVE-2020-9614 and CVE-2020-9613 and verify that the impacted system is patched. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |110
 
-|<<suspicious-cmd-execution-via-wmi, Suspicious Cmd Execution via WMI>> |Identifies suspicious command execution (cmd) via Windows Management Instrumentation (WMI) on a remote host. This could be indicative of adversary lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |321
+|<<suspicious-cmd-execution-via-wmi, Suspicious Cmd Execution via WMI>> |Identifies suspicious command execution (cmd) via Windows Management Instrumentation (WMI) on a remote host. This could be indicative of adversary lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |322
 
 |<<suspicious-command-prompt-network-connection, Suspicious Command Prompt Network Connection>> |Identifies a network connection by the command prompt (cmd.exe) when it is executed with specific arguments, such as a script or a URL, or when it is spawned by Microsoft Office applications. Adversaries often abuse cmd.exe to download malicious payloads or establish command and control channels from a remote source. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne] |None |215
 
@@ -2866,13 +2914,13 @@ and their rule type is `machine_learning`.
 
 |<<suspicious-execution-from-foomatic-rip-or-cupsd-parent, Suspicious Execution from Foomatic-rip or Cupsd Parent>> |This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects suspicious process command lines executed by child processes of foomatic-rip and cupsd. These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Use Case: Vulnerability], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |107
 
-|<<suspicious-execution-from-inet-cache, Suspicious Execution from INET Cache>> |Identifies the execution of a process with arguments pointing to the INetCache Folder. Adversaries may deliver malicious content via WININET during initial access. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Command and Control], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |212
+|<<suspicious-execution-from-inet-cache, Suspicious Execution from INET Cache>> |Identifies the execution of a process with arguments pointing to the INetCache Folder. Adversaries may deliver malicious content via WININET during initial access. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |213
 
 |<<suspicious-execution-from-vs-code-extension, Suspicious Execution from VS Code Extension>> |Detects suspicious process execution launched from a VS Code extension context (parent command line contains .vscode/extensions). Malicious extensions can run on startup and drop or execute payloads (e.g. RATs like ScreenConnect, script interpreters, or download utilities). This covers both script/LOLBin children and recently created executables from non-Program Files paths, as seen in campaigns such as the fake Clawdbot extension that installed ScreenConnect RAT. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |3
 
 |<<suspicious-execution-from-a-mounted-device, Suspicious Execution from a Mounted Device>> |Identifies when a script interpreter or signed binary is launched via a non-standard working directory. An attacker may use this technique to evade defenses. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |214
 
-|<<suspicious-execution-from-a-webdav-share, Suspicious Execution from a WebDav Share>> |Identifies attempt to execute Windows scripts from a remote WebDav Share. Adversaries may abuse this method to evade dropping malicious files to victim file system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |3
+|<<suspicious-execution-from-a-webdav-share, Suspicious Execution from a WebDav Share>> |Identifies attempts to execute or invoke content from remote WebDAV shares. Adversaries may abuse WebDAV paths, public tunnels, or host@port UNC paths to run tools or scripts while reducing local staging on the victim file system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |4
 
 |<<suspicious-execution-via-msiexec, Suspicious Execution via MSIEXEC>> |Identifies suspicious execution of the built-in Windows Installer, msiexec.exe, to install a package from usual paths or parent process. Adversaries may abuse msiexec.exe to launch malicious local MSI files. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame] |None |105
 
@@ -2882,7 +2930,7 @@ and their rule type is `machine_learning`.
 
 |<<suspicious-execution-via-windows-subsystem-for-linux, Suspicious Execution via Windows Subsystem for Linux>> |Detects Linux Bash commands from the the Windows Subsystem for Linux. Adversaries may enable and use WSL for Linux to avoid detection. |[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] |None |213
 
-|<<suspicious-execution-with-nodejs, Suspicious Execution with NodeJS>> |Identifies suspicious execution patterns using NodeJS interpeter like process path and arguments. |[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] |None |3
+|<<suspicious-execution-with-nodejs, Suspicious Execution with NodeJS>> |Identifies suspicious Node.js execution patterns, including user-writable runtimes, preload arguments, and inline eval, decode, or child-process usage. |[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] |None |4
 
 |<<suspicious-explorer-child-process, Suspicious Explorer Child Process>> |Identifies a suspicious Windows explorer child process. Explorer.exe can be abused to launch malicious scripts or executables from a trusted parent process. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |315
 
@@ -2894,7 +2942,7 @@ and their rule type is `machine_learning`.
 
 |<<suspicious-file-made-executable-via-chmod-inside-a-container, Suspicious File Made Executable via Chmod Inside A Container>> |This rule detects when chmod or chown are used to add the execute permission to a file in a world-writeable directory, and inside of a container. Modifying file permissions to make a file executable could indicate malicious activity, as an attacker may attempt to run unauthorized or malicious code inside the container. |[Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |4
 
-|<<suspicious-file-renamed-via-smb, Suspicious File Renamed via SMB>> |Identifies an incoming SMB connection followed by a suspicious file rename operation. This may indicate a remote ransomware attack via the SMB protocol. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |7
+|<<suspicious-file-renamed-via-smb, Suspicious File Renamed via SMB>> |Identifies an incoming SMB connection followed by a suspicious file rename operation. This may indicate a remote ransomware attack via the SMB protocol. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |8
 
 |<<suspicious-html-file-creation, Suspicious HTML File Creation>> |Identifies the execution of a browser process to open an HTML file with high entropy and size. Adversaries may smuggle data and files past content filters by hiding malicious payloads inside of seemingly benign HTML files. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |113
 
@@ -2902,17 +2950,17 @@ and their rule type is `machine_learning`.
 
 |<<suspicious-image-load-taskschd-dll-from-ms-office, Suspicious Image Load (taskschd.dll) from MS Office>> |Identifies a suspicious image load (taskschd.dll) from Microsoft Office processes. This behavior may indicate adversarial activity where a scheduled task is configured via Windows Component Object Model (COM). This technique can be used to configure persistence and evade monitoring by avoiding the usage of the traditional Windows binary (schtasks.exe) used to manage scheduled tasks. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |214
 
-|<<suspicious-imagepath-service-creation, Suspicious ImagePath Service Creation>> |Identifies the creation of a suspicious ImagePath value. This could be an indication of an adversary attempting to stealthily persist or escalate privileges through abnormal service creation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |314
+|<<suspicious-imagepath-service-creation, Suspicious ImagePath Service Creation>> |Identifies the creation of a suspicious ImagePath value. This could be an indication of an adversary attempting to stealthily persist or escalate privileges through abnormal service creation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |315
 
 |<<suspicious-installer-package-spawns-network-event, Suspicious Installer Package Spawns Network Event>> |Detects the execution of a MacOS installer package with an abnormal child process (e.g bash) followed immediately by a network connection via a suspicious process (e.g curl). Threat actors will build and distribute malicious MacOS installer packages, which have a .pkg extension, many times imitating valid software in order to persuade and infect their victims often using the package files (e.g pre/post install scripts etc.) to download additional tools or malicious software. If this rule fires it should indicate the installation of a malicious or suspicious package. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |113
 
 |<<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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |12
 
-|<<suspicious-javascript-execution-via-deno, Suspicious JavaScript Execution via Deno>> |Detects execution of JavaScript via Deno with suspicious command-line patterns (base64, eval, http, or import in a javascript context). Adversaries may abuse Deno to run malicious JavaScript for execution or staging. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Data Source: Elastic Endgame], [Data Source: Windows Security Event Logs] |None |3
+|<<suspicious-javascript-execution-via-deno, Suspicious JavaScript Execution via Deno>> |Detects execution of JavaScript via Deno with suspicious command-line patterns (base64, eval, http, or import in a javascript context). Adversaries may abuse Deno to run malicious JavaScript for execution or staging. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Data Source: Elastic Endgame], [Data Source: Windows Security Event Logs] |None |4
 
 |<<suspicious-jetbrains-teamcity-child-process, Suspicious JetBrains TeamCity Child Process>> |Identifies suspicious processes being spawned by the JetBrain TeamCity process. This activity could be related to JetBrains remote code execution vulnerabilities. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR], [Data Source: Windows Security Event Logs], [Data Source: Sysmon], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |210
 
-|<<suspicious-kerberos-authentication-ticket-request, Suspicious Kerberos Authentication Ticket Request>> |Correlates network connections to the standard Kerberos port by an unusual process from the source machine with a Kerberos authentication ticket request from the target domain controller. |[Domain: Endpoint], [Domain: Identity], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Lateral Movement], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |4
+|<<suspicious-kerberos-authentication-ticket-request, Suspicious Kerberos Authentication Ticket Request>> |Correlates network connections to the standard Kerberos port by an unusual process from the source machine with a Kerberos authentication ticket request from the target domain controller. |[Domain: Endpoint], [Domain: Identity], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |5
 
 |<<suspicious-kernel-feature-activity, Suspicious Kernel Feature Activity>> |This rule detects the modification and reading of kernel features through built-in commands. Attackers may collect information, disable or weaken Linux kernel protections. For example, an attacker may modify ASLR protection by disabling kernel.randomize_va_space, allow ptrace by setting kernel.yama.ptrace_scope to 0, or disable the NMI watchdog by setting kernel.nmi_watchdog to 0. These changes may be used to impair defenses and evade detection. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |5
 
@@ -2940,7 +2988,7 @@ and their rule type is `machine_learning`.
 
 |<<suspicious-modprobe-file-event, Suspicious Modprobe File Event>> |Detects file events involving kernel modules in modprobe configuration files, which may indicate unauthorized access or manipulation of critical kernel modules. Attackers may tamper with the modprobe files to load malicious or unauthorized kernel modules, potentially bypassing security measures, escalating privileges, or hiding their activities within the system. |[Data Source: Auditd Manager], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR] |None |112
 
-|<<suspicious-module-loaded-by-lsass, Suspicious Module Loaded by LSASS>> |Identifies LSASS loading an unsigned or untrusted DLL. Windows Security Support Provider (SSP) DLLs are loaded into LSSAS process at system start. Once loaded into the LSA, SSP DLLs have access to encrypted and plaintext passwords that are stored in Windows, such as any logged-on user's Domain password or smart card PINs. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |14
+|<<suspicious-module-loaded-by-lsass, Suspicious Module Loaded by LSASS>> |Identifies LSASS loading an unsigned or untrusted DLL. Windows Security Support Provider (SSP) DLLs are loaded into LSSAS process at system start. Once loaded into the LSA, SSP DLLs have access to encrypted and plaintext passwords that are stored in Windows, such as any logged-on user's Domain password or smart card PINs. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |15
 
 |<<suspicious-named-pipe-creation, Suspicious Named Pipe Creation>> |This rule detects the creation of unusually labeled named pipes (FIFOs) by the mkfifo command, which is often used by attackers to establish persistence on a target system or to execute commands in the background. Through the new_terms rule type, this rule can identify uncommon process command lines that may indicate the presence of a malicious named pipe. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike], [Data Source: SentinelOne] |None |5
 
@@ -2970,7 +3018,7 @@ and their rule type is `machine_learning`.
 
 |<<suspicious-print-spooler-file-deletion, Suspicious Print Spooler File Deletion>> |Detects deletion of print driver files by an unusual process. This may indicate a clean up attempt post successful privilege escalation via Print Spooler service related vulnerabilities. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |313
 
-|<<suspicious-print-spooler-point-and-print-dll, Suspicious Print Spooler Point and Print DLL>> |Detects attempts to exploit a privilege escalation vulnerability (CVE-2020-1030) related to the print spooler service. Exploitation involves chaining multiple primitives to load an arbitrary DLL into the print spooler process running as SYSTEM. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR] |None |214
+|<<suspicious-print-spooler-point-and-print-dll, Suspicious Print Spooler Point and Print DLL>> |Detects attempts to exploit a privilege escalation vulnerability (CVE-2020-1030) related to the print spooler service. Exploitation involves chaining multiple primitives to load an arbitrary DLL into the print spooler process running as SYSTEM. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR] |None |215
 
 |<<suspicious-print-spooler-spl-file-created, Suspicious Print Spooler SPL File Created>> |Detects attempts to exploit privilege escalation vulnerabilities related to the Print Spooler service including CVE-2020-1048 and CVE-2020-1337. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR] |None |118
 
@@ -2994,13 +3042,15 @@ and their rule type is `machine_learning`.
 
 |<<suspicious-sip-check-by-macos-application, Suspicious SIP Check by macOS Application>> |Detects the unusual use of csrutil by a macOS application to check System Integrity Protection (SIP) status. While not malicious in itself, this activity is highly indicative of malware verifying it is not running in a virtual machine or protected environment prior to executing its payload. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Discovery], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2
 
-|<<suspicious-suid-binary-execution, Suspicious SUID Binary Execution>> |Detects execution of common privilege elevation helpers (su, sudo, pkexec, passwd, chsh, newgrp) under the root effective user when the real user and parent user are not root, combined with minimal argument counts and suspicious parent context (interpreters, short shell -c invocations, or parents running from user-writable paths). |[Data Source: Elastic Defend], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1
+|<<suspicious-suid-binary-execution, Suspicious SUID Binary Execution>> |Detects execution of SUID binaries that may be used for privilege escalation under the root effective user when the real user and parent user are not root, combined with minimal argument counts and suspicious parent context (interpreters, short shell -c invocations, or parents running from user-writable paths) to indicate potential misuse of SUID binaries for privilege escalation. |[Data Source: Elastic Defend], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |2
+
+|<<suspicious-suid-binary-execution-auditd-sequence, Suspicious SUID Binary Execution (Auditd Sequence)>> |Detects suspicious sequences where a non-root user launches a high-risk parent process (interpreter, shell one-liner, or execution from user-writable paths) and then quickly executes a common privilege elevation helper (su, sudo, pkexec, passwd, chsh, newgrp) that gains an effective UID of 0 while the real UID remains non-root. This can indicate misuse of SUID/SGID helpers, polkit/sudo abuse, or interactive privilege escalation attempts captured via Auditd Manager telemetry. |[Data Source: Auditd Manager], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1
 
 |<<suspicious-screenconnect-client-child-process, Suspicious ScreenConnect Client Child Process>> |Identifies suspicious processes being spawned by the ScreenConnect client processes. This activity may indicate execution abusing unauthorized access to the ScreenConnect remote access software. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Windows Security Event Logs], [Data Source: Crowdstrike] |None |315
 
 |<<suspicious-script-object-execution, Suspicious Script Object Execution>> |Identifies scrobj.dll loaded into unusual Microsoft processes. This usually means a malicious scriptlet is being executed in the target process. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Sysmon], [Resources: Investigation Guide] |None |214
 
-|<<suspicious-seincreasebasepriorityprivilege-use, Suspicious SeIncreaseBasePriorityPrivilege Use>> |Identifies attempts to use the SeIncreaseBasePriorityPrivilege privilege by an unusual process. This could be related to hijack execution flow of a process via threats priority manipulation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |2
+|<<suspicious-seincreasebasepriorityprivilege-use, Suspicious SeIncreaseBasePriorityPrivilege Use>> |Identifies attempts to use the SeIncreaseBasePriorityPrivilege privilege by an unusual process. This could be related to hijack execution flow of a process via threats priority manipulation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |3
 
 |<<suspicious-service-was-installed-in-the-system, Suspicious Service was Installed in the System>> |Identifies the creation of a new Windows service with suspicious Service command values. Windows services typically run as SYSTEM and can be used for privilege escalation and persistence. |[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] |None |117
 
@@ -3008,9 +3058,9 @@ and their rule type is `machine_learning`.
 
 |<<suspicious-solarwinds-child-process, Suspicious SolarWinds Child Process>> |A suspicious SolarWinds child process was detected, which may indicate an attempt to execute malicious programs. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |214
 
-|<<suspicious-solarwinds-web-help-desk-java-module-load-or-child-process, Suspicious SolarWinds Web Help Desk Java Module Load or Child Process>> |Identifies the SolarWinds Web Help Desk Java process loading an untrusted or remote native module (DLL). This behavior is uncommon for the Web Help Desk server and may indicate successful exploitation of deserialization vulnerabilities (CVE-2025-40536, CVE-2025-40551), which allow attackers to load malicious SQLite extensions and achieve remote code execution. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2
+|<<suspicious-solarwinds-web-help-desk-java-module-load-or-child-process, Suspicious SolarWinds Web Help Desk Java Module Load or Child Process>> |Identifies the SolarWinds Web Help Desk Java process loading an untrusted or remote native module (DLL) or spawning a suspicious child process such as cmd, PowerShell, or rundll32. This behavior is uncommon for the Web Help Desk server and may indicate successful exploitation of deserialization vulnerabilities (CVE-2025-40536, CVE-2025-40551), which allow attackers to load malicious SQLite extensions and achieve remote code execution. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |3
 
-|<<suspicious-startup-shell-folder-modification, Suspicious Startup Shell Folder Modification>> |Identifies suspicious startup shell folder modifications to change the default Startup directory in order to bypass detections monitoring file creation in the Windows Startup folder. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |319
+|<<suspicious-startup-shell-folder-modification, Suspicious Startup Shell Folder Modification>> |Identifies suspicious startup shell folder modifications to change the default Startup directory in order to bypass detections monitoring file creation in the Windows Startup folder. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |320
 
 |<<suspicious-startupitem-plist-creation, Suspicious StartupItem Plist Creation>> |Detects the creation or modification of a StartupParameters.plist file, indicating the presence of a StartupItem on the system. StartupItems have been deprecated on modern macOS systems (post Mavericks) in favor of Launch Daemons but still function. Creation of a StartupItem should be highly suspicious as legitimate applications no longer use this method for persistence. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1
 
@@ -3040,7 +3090,7 @@ and their rule type is `machine_learning`.
 
 |<<suspicious-werfault-child-process, Suspicious WerFault Child Process>> |A suspicious WerFault child process was detected, which may indicate an attempt to run via the SilentProcessExit registry key manipulation. Verify process details such as command line, network connections and file writes. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |420
 
-|<<suspicious-windows-command-shell-arguments, Suspicious Windows Command Shell Arguments>> |Identifies the execution of the Windows Command Shell process (cmd.exe) with suspicious argument values. This behavior is often observed during malware installation. |[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 |208
+|<<suspicious-windows-command-shell-arguments, Suspicious Windows Command Shell Arguments>> |Identifies the execution of the Windows Command Shell process (cmd.exe) with suspicious argument values. This behavior is often observed during malware installation. |[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 |209
 
 |<<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. |[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] |None |214
 
@@ -3048,7 +3098,7 @@ and their rule type is `machine_learning`.
 
 |<<suspicious-zoom-child-process, Suspicious Zoom Child Process>> |A suspicious Zoom child process was detected, which may indicate an attempt to run unnoticed. Verify process details such as command line, network connections, file writes and associated file signature details as well. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Windows Security Event Logs], [Data Source: Crowdstrike], [Data Source: Sysmon] |None |423
 
-|<<suspicious-macos-ms-office-child-process, Suspicious macOS MS Office Child Process>> |Identifies suspicious child processes of frequently targeted Microsoft Office applications (Word, PowerPoint, and Excel). These child processes are often launched during exploitation of Office applications or by documents with malicious macros. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Initial Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |212
+|<<suspicious-macos-ms-office-child-process, Suspicious macOS MS Office Child Process>> |Identifies suspicious child processes of frequently targeted Microsoft Office applications (Word, PowerPoint, and Excel). These child processes are often launched during exploitation of Office applications or by documents with malicious macros. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Initial Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |213
 
 |<<suspicious-pbpaste-high-volume-activity, Suspicious pbpaste High Volume Activity>> |Identifies a high volume of `pbpaste` executions, which may indicate a bash loop continuously collecting clipboard contents, potentially allowing an attacker to harvest user credentials or other sensitive information. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Jamf Protect], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |5
 
@@ -3080,7 +3130,7 @@ and their rule type is `machine_learning`.
 
 |<<system-owner-user-discovery-linux, System Owner/User Discovery Linux>> |Identifies the use of built-in tools which adversaries may use to enumerate the system owner/user of a compromised system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: SentinelOne] |None |8
 
-|<<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. Malwares tend to perform this action to assess potential targets. |[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] |None |3
+|<<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. |[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] |None |4
 
 |<<system-service-discovery-through-built-in-windows-utilities, System Service Discovery through built-in Windows Utilities>> |Detects the usage of commonly used system service discovery techniques, which attackers may use during the reconnaissance phase after compromising a system in order to gain a better understanding of the environment and/or escalate privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Rule Type: BBR], [Data Source: Windows Security Event Logs] |None |114
 
@@ -3140,13 +3190,13 @@ and their rule type is `machine_learning`.
 
 |<<uac-bypass-attempt-via-privileged-ifileoperation-com-interface, UAC Bypass Attempt via Privileged IFileOperation COM Interface>> |Identifies attempts to bypass User Account Control (UAC) via DLL side-loading. Attackers may attempt to bypass UAC to stealthily execute code with elevated permissions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |314
 
-|<<uac-bypass-attempt-via-windows-directory-masquerading, UAC Bypass Attempt via Windows Directory Masquerading>> |Identifies an attempt to bypass User Account Control (UAC) by masquerading as a Microsoft trusted Windows directory. Attackers may bypass UAC to stealthily execute code with elevated permissions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |322
+|<<uac-bypass-attempt-via-windows-directory-masquerading, UAC Bypass Attempt via Windows Directory Masquerading>> |Identifies an attempt to bypass User Account Control (UAC) by masquerading as a Microsoft trusted Windows directory. Attackers may 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: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |323
 
-|<<uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface, UAC Bypass Attempt with IEditionUpgradeManager Elevated COM Interface>> |Identifies attempts to bypass User Account Control (UAC) by abusing an elevated COM Interface to launch a rogue Windows ClipUp program. Attackers may attempt to bypass UAC to stealthily execute code with elevated permissions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |313
+|<<uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface, UAC Bypass Attempt with IEditionUpgradeManager Elevated COM Interface>> |Identifies attempts to bypass User Account Control (UAC) by abusing an elevated COM Interface to launch a rogue Windows ClipUp program. Attackers may attempt to bypass UAC to stealthily execute code with elevated permissions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |314
 
 |<<uac-bypass-via-diskcleanup-scheduled-task-hijack, UAC Bypass via DiskCleanup Scheduled Task Hijack>> |Identifies User Account Control (UAC) bypass via hijacking DiskCleanup Scheduled Task. Attackers bypass UAC to stealthily execute code with elevated permissions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |318
 
-|<<uac-bypass-via-icmluautil-elevated-com-interface, UAC Bypass via ICMLuaUtil Elevated COM Interface>> |Identifies User Account Control (UAC) bypass attempts via the ICMLuaUtil Elevated COM interface. Attackers may attempt to bypass UAC to stealthily execute code with elevated permissions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Resources: Investigation Guide] |None |214
+|<<uac-bypass-via-icmluautil-elevated-com-interface, UAC Bypass via ICMLuaUtil Elevated COM Interface>> |Identifies User Account Control (UAC) bypass attempts via the ICMLuaUtil Elevated COM interface. Attackers may attempt to bypass UAC to stealthily execute code with elevated permissions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Resources: Investigation Guide] |None |215
 
 |<<uac-bypass-via-windows-firewall-snap-in-hijack, UAC Bypass via Windows Firewall Snap-In Hijack>> |Identifies attempts to bypass User Account Control (UAC) by hijacking the Microsoft Management Console (MMC) Windows Firewall snap-in. Attackers bypass UAC to stealthily execute code with elevated permissions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne] |None |318
 
@@ -3178,7 +3228,7 @@ and their rule type is `machine_learning`.
 
 |<<untrusted-dll-loaded-by-azure-ad-connect-authentication-agent, Untrusted DLL Loaded by Azure AD Connect Authentication Agent>> |Identifies the load of an untrusted DLL by the Azure AD Connect Authentication Agent, which may indicate an attempt to persist or intercept credentials passing through the Pass-through Authentication service. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |107
 
-|<<untrusted-driver-loaded, Untrusted Driver Loaded>> |Identifies attempt to load an untrusted driver. Adversaries may modify code signing policies to enable execution of unsigned or self-signed code. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |13
+|<<untrusted-driver-loaded, Untrusted Driver Loaded>> |Identifies an untrusted driver loaded by the Windows kernel. Adversaries may modify code signing policies to enable execution of unsigned or self-signed kernel code. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |14
 
 |<<unusual-aws-command-for-a-user, Unusual AWS Command for a User>> |A machine learning job detected an AWS API command that, while not inherently suspicious or abnormal, is being made by a user context that does not normally use the command. This can be the result of compromised credentials or keys as someone uses a valid account to persist, move laterally, or exfiltrate data. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |213
 
@@ -3188,7 +3238,7 @@ and their rule type is `machine_learning`.
 
 |<<unusual-child-process-from-a-system-virtual-process, Unusual Child Process from a System Virtual Process>> |Identifies a suspicious child process of the Windows virtual system process, which could indicate code injection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |319
 
-|<<unusual-child-process-of-dns-exe, Unusual Child Process of dns.exe>> |Identifies an unexpected process spawning from dns.exe, the process responsible for Windows DNS server services, which may indicate activity related to remote code execution or other forms of exploitation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |319
+|<<unusual-child-process-of-dns-exe, Unusual Child Process of dns.exe>> |Identifies an unexpected process spawning from dns.exe, the process responsible for Windows DNS server services, which may indicate activity related to remote code execution or other forms of exploitation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |320
 
 |<<unusual-child-processes-of-rundll32, Unusual Child Processes of RunDLL32>> |Identifies a no-argument or malformed Rundll32 launch followed by child process execution. This unusual sequence can indicate Rundll32 abuse for proxy execution or payload handoff. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |214
 
@@ -3212,7 +3262,7 @@ and their rule type is `machine_learning`.
 
 |<<unusual-execution-from-kernel-thread-kthreadd-parent, Unusual Execution from Kernel Thread (kthreadd) Parent>> |This rule detects suspicious child process from the kernel thread (kthreadd) parent process. Attackers may execute payloads from kernel space via kthreadd to perform actions on the host and evade detection. Through the usage of the new_terms rule type, this rule can identify uncommon child processes that may indicate the presence of a malicious process. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |4
 
-|<<unusual-execution-via-microsoft-common-console-file, Unusual Execution via Microsoft Common Console File>> |Identifies the execution of a child process from a Microsoft Common Console file. Adversaries may embed a malicious command in an MSC file in order to trick victims into executing malicious commands. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Initial Access], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne] |None |207
+|<<unusual-execution-via-microsoft-common-console-file, Unusual Execution via Microsoft Common Console File>> |Identifies the execution of a child process from a Microsoft Common Console file. Adversaries may embed a malicious command in an MSC file in order to trick victims into executing malicious commands. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Initial Access], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne] |None |208
 
 |<<unusual-exim4-child-process, Unusual Exim4 Child Process>> |This rule detects the execution of unusual commands via a descendant process of exim4. Attackers may use descendant processes of exim4 to evade detection and establish persistence or execute post-exploitation commands on a target system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |4
 
@@ -3392,7 +3442,7 @@ and their rule type is `machine_learning`.
 
 |<<user-added-to-privileged-group-in-active-directory, User Added to Privileged Group in Active Directory>> |Identifies a user being added to a privileged group in Active Directory. Privileged accounts and groups in Active Directory are those to which powerful rights, privileges, and permissions are granted that allow them to perform nearly any action in Active Directory and on domain-joined systems. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs] |None |217
 
-|<<user-added-to-the-admin-group, User Added to the Admin Group>> |Identifies users being added to the admin group. This could be an indication of privilege escalation activity. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Jamf Protect], [Resources: Investigation Guide] |None |5
+|<<user-added-to-the-admin-group, User Added to the Admin Group>> |Identifies users being added to the admin group. This could be an indication of privilege escalation activity. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Jamf Protect], [Resources: Investigation Guide] |None |6
 
 |<<user-detected-with-suspicious-windows-process-es, User Detected with Suspicious Windows Process(es)>> |A machine learning job combination has identified a user with one or more suspicious Windows processes that exhibit unusually high malicious probability scores. These process(es) have been classified as malicious in several ways. The process(es) were predicted to be malicious by the ProblemChild supervised ML model. If the anomaly contains a cluster of suspicious processes, each process has the same user name, and the aggregate score of the event cluster was calculated to be unusually high by an unsupervised ML model. Such a cluster often contains suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules. |[Domain: Endpoint], [OS: Windows], [Use Case: Living off the Land Attack Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |111
 
@@ -3412,11 +3462,11 @@ and their rule type is `machine_learning`.
 
 |<<virtual-private-network-connection-attempt, Virtual Private Network Connection Attempt>> |Identifies the execution of macOS built-in commands to connect to an existing Virtual Private Network (VPN). Adversaries may use VPN connections to laterally move and control remote systems on a network. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |113
 
-|<<volume-shadow-copy-deleted-or-resized-via-vssadmin, Volume Shadow Copy Deleted or Resized via VssAdmin>> |Identifies use of vssadmin.exe for shadow copy deletion or resizing on endpoints. This commonly occurs in tandem with ransomware or other destructive attacks. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |317
+|<<volume-shadow-copy-deleted-or-resized-via-vssadmin, Volume Shadow Copy Deleted or Resized via VssAdmin>> |Identifies use of vssadmin.exe for shadow copy deletion or resizing on endpoints. This commonly occurs in tandem with ransomware or other destructive attacks. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |318
 
-|<<volume-shadow-copy-deletion-via-powershell, Volume Shadow Copy Deletion via PowerShell>> |Identifies the use of the Win32_ShadowCopy class and related cmdlets to achieve shadow copy deletion. This commonly occurs in tandem with ransomware or other destructive attacks. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [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] |None |318
+|<<volume-shadow-copy-deletion-via-powershell, Volume Shadow Copy Deletion via PowerShell>> |Identifies the use of the Win32_ShadowCopy class and related cmdlets to achieve shadow copy deletion. This commonly occurs in tandem with ransomware or other destructive attacks. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |319
 
-|<<volume-shadow-copy-deletion-via-wmic, Volume Shadow Copy Deletion via WMIC>> |Identifies use of wmic.exe for shadow copy deletion on endpoints. This commonly occurs in tandem with ransomware or other destructive attacks. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [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] |None |317
+|<<volume-shadow-copy-deletion-via-wmic, Volume Shadow Copy Deletion via WMIC>> |Identifies use of wmic.exe for shadow copy deletion on endpoints. This commonly occurs in tandem with ransomware or other destructive attacks. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |318
 
 |<<wdac-policy-file-by-an-unusual-process, WDAC Policy File by an Unusual Process>> |Identifies the creation of a Windows Defender Application Control (WDAC) policy file by an unusual process. Adversaries may use a specially crafted WDAC policy to restrict the execution of security products. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |7
 
@@ -3426,7 +3476,7 @@ and their rule type is `machine_learning`.
 
 |<<wmic-remote-command, WMIC Remote Command>> |Identifies the use of wmic.exe to run commands on remote hosts. While this can be used by administrators legitimately, attackers can abuse this built-in utility to achieve lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Rule Type: BBR], [Data Source: Sysmon], [Data Source: Elastic Endgame], [Data Source: Windows Security Event Logs] |None |111
 
-|<<wps-office-exploitation-via-dll-hijack, WPS Office Exploitation via DLL Hijack>> |Identifies the load of a remote library by the WPS Office promecefpluginhost.exe executable. This may indicate the successful exploitation of CVE-2024-7262 or CVE-2024-7263 via DLL hijack abusing the ksoqing custom protocol handler. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |105
+|<<wps-office-exploitation-via-dll-hijack, WPS Office Exploitation via DLL Hijack>> |Identifies the load of a remote library by the WPS Office promecefpluginhost.exe executable. This may indicate the successful exploitation of CVE-2024-7262 or CVE-2024-7263 via DLL hijack abusing the ksoqing custom protocol handler. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Execution], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |106
 
 |<<writedac-access-on-active-directory-object, WRITEDAC Access on Active Directory Object>> |Identifies the access on an object with WRITEDAC permissions. With the WRITEDAC permission, the user can perform a Write Discretionary Access Control List (WriteDACL) operation, which is used to modify the access control rules associated with a specific object within Active Directory. Attackers may abuse this privilege to grant themselves or other compromised accounts additional rights, ultimately compromising the target object, resulting in privilege escalation, lateral movement, and persistence. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Rule Type: BBR], [Data Source: Windows Security Event Logs] |None |111
 
@@ -3448,7 +3498,7 @@ and their rule type is `machine_learning`.
 
 |<<web-server-suspicious-user-agent-requests, Web Server Suspicious User Agent Requests>> |This rule detects unusual spikes in web server requests with uncommon or suspicious user-agent strings. Such activity may indicate reconnaissance attempts by attackers trying to identify vulnerabilities in web applications or servers. These user-agents are often associated with automated tools used for scanning, vulnerability assessment, or brute-force attacks. |[Domain: Web], [Use Case: Threat Detection], [Tactic: Reconnaissance], [Tactic: Credential Access], [Data Source: Nginx], [Data Source: Apache], [Data Source: Apache Tomcat], [Data Source: IIS], [Data Source: Traefik], [Resources: Investigation Guide] |None |6
 
-|<<web-shell-detection-script-process-child-of-common-web-processes, Web Shell Detection: Script Process Child of Common Web Processes>> |Identifies suspicious commands executed via a web server, which may suggest a vulnerability and remote shell access. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Initial Access], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: Crowdstrike] |None |423
+|<<web-shell-detection-script-process-child-of-common-web-processes, Web Shell Detection: Script Process Child of Common Web Processes>> |Identifies suspicious commands executed via a web server, which may suggest a vulnerability and remote shell access. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: Crowdstrike] |None |424
 
 |<<webproxy-settings-modification, WebProxy Settings Modification>> |Identifies the use of the built-in networksetup command to configure webproxy settings. This may indicate an attempt to hijack web browser traffic for credential access via traffic sniffing or redirection. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |211
 
@@ -3484,9 +3534,9 @@ and their rule type is `machine_learning`.
 
 |<<windows-script-interpreter-executing-process-via-wmi, Windows Script Interpreter Executing Process via WMI>> |Identifies use of the built-in Windows script interpreters (cscript.exe or wscript.exe) being used to execute a process via Windows Management Instrumentation (WMI). This may be indicative of malicious activity. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |215
 
-|<<windows-server-update-service-spawning-suspicious-processes, Windows Server Update Service Spawning Suspicious Processes>> |Identifies suspicious processes being spawned by the Windows Server Update Service. This activity may indicate exploitation activity or access to an existing web shell backdoor. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |3
+|<<windows-server-update-service-spawning-suspicious-processes, Windows Server Update Service Spawning Suspicious Processes>> |Identifies suspicious processes being spawned by the Windows Server Update Service. This activity may indicate exploitation activity or access to an existing web shell backdoor. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |4
 
-|<<windows-service-installed-via-an-unusual-client, Windows Service Installed via an Unusual Client>> |Identifies the creation of a Windows service by an unusual client process. Services may be created with administrator privileges but are executed under SYSTEM privileges, so an adversary may also use a service to escalate privileges from administrator to SYSTEM. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |217
+|<<windows-service-installed-via-an-unusual-client, Windows Service Installed via an Unusual Client>> |Identifies the creation of a Windows service by an unusual client process. Services may be created with administrator privileges but are executed under SYSTEM privileges, so an adversary may also use a service to escalate privileges from administrator to SYSTEM. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |218
 
 |<<windows-subsystem-for-linux-distribution-installed, Windows Subsystem for Linux Distribution Installed>> |Detects changes to the registry that indicates the install of a new Windows Subsystem for Linux distribution by name. Adversaries may enable and use WSL for Linux to avoid detection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |215
 
@@ -3504,7 +3554,7 @@ and their rule type is `machine_learning`.
 
 |<<zoom-meeting-with-no-passcode, Zoom Meeting with no Passcode>> |This rule identifies Zoom meetings that are created without a passcode. Meetings without a passcode are susceptible to Zoombombing. Zoombombing is carried out by taking advantage of Zoom sessions that are not protected with a passcode. Zoombombing refers to the unwanted, disruptive intrusion, generally by Internet trolls and hackers, into a video conference call. In a typical Zoombombing incident, a teleconferencing session is hijacked by the insertion of material that is lewd, obscene, racist, or antisemitic in nature, typically resulting of the shutdown of the session. |[Data Source: Zoom], [Use Case: Configuration Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |106
 
-|<<dmsa-account-creation-by-an-unusual-user, dMSA Account Creation by an Unusual User>> |Detects the creation of a delegated Managed Service Account by an unusual subject account. Attackers can abuse the dMSA account migration feature to elevate privileges abusing weak persmission allowing users child objects rights or msDS-DelegatedManagedServiceAccount rights. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |4
+|<<dmsa-account-creation-by-an-unusual-user, dMSA Account Creation by an Unusual User>> |Detects creation of a delegated Managed Service Account by an unusual subject account. Attackers can abuse weak child-object or msDS-DelegatedManagedServiceAccount rights during account migration to elevate privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |5
 
 |<<rc-local-rc-common-file-creation, rc.local/rc.common File Creation>> |This rule monitors the creation of the rc.local/rc.common files. The "/etc/rc.local" file is used to start custom applications, services, scripts or commands during start-up. The rc.local file has mostly been replaced by Systemd. However, through the "systemd-rc-local-generator", rc.local files can be converted to services that run at boot. Adversaries may alter rc.local/rc.common to execute malicious code at start-up, and gain persistence onto the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |120
 
diff --git a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc
index 14e9a6bd79..81df30128a 100644
--- a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc
@@ -51,6 +51,9 @@ include::rule-details/aws-ec2-stop-start-and-user-data-modification-correlation.
 include::rule-details/aws-ec2-unauthorized-admin-credential-fetch-via-assumed-role.asciidoc[]
 include::rule-details/aws-ec2-user-data-retrieval-for-ec2-instance.asciidoc[]
 include::rule-details/aws-efs-file-system-deleted.asciidoc[]
+include::rule-details/aws-eks-access-entry-granted-cluster-admin-policy.asciidoc[]
+include::rule-details/aws-eks-access-entry-modified.asciidoc[]
+include::rule-details/aws-eks-control-plane-logging-disabled.asciidoc[]
 include::rule-details/aws-eventbridge-rule-disabled-or-deleted.asciidoc[]
 include::rule-details/aws-first-occurrence-of-sts-getfederationtoken-request-by-user.asciidoc[]
 include::rule-details/aws-guardduty-detector-deletion.asciidoc[]
@@ -289,6 +292,7 @@ include::rule-details/connection-to-commonly-abused-web-services.asciidoc[]
 include::rule-details/connection-to-external-network-via-telnet.asciidoc[]
 include::rule-details/connection-to-internal-network-via-telnet.asciidoc[]
 include::rule-details/container-management-utility-run-inside-a-container.asciidoc[]
+include::rule-details/container-runtime-cli-execution-with-suspicious-arguments.asciidoc[]
 include::rule-details/control-panel-process-with-unusual-arguments.asciidoc[]
 include::rule-details/correlated-alerts-on-similar-user-identities.asciidoc[]
 include::rule-details/creation-of-hidden-files-and-directories-via-commandline.asciidoc[]
@@ -371,6 +375,7 @@ include::rule-details/dynamic-iex-reconstruction-via-method-string-access.asciid
 include::rule-details/dynamic-linker-ld-so-creation.asciidoc[]
 include::rule-details/dynamic-linker-copy.asciidoc[]
 include::rule-details/dynamic-linker-creation.asciidoc[]
+include::rule-details/eks-authentication-configuration-modified.asciidoc[]
 include::rule-details/esxi-discovery-via-find.asciidoc[]
 include::rule-details/esxi-discovery-via-grep.asciidoc[]
 include::rule-details/esxi-timestomping-using-touch-command.asciidoc[]
@@ -402,16 +407,19 @@ include::rule-details/entra-id-high-risk-user-sign-in-heuristic.asciidoc[]
 include::rule-details/entra-id-illicit-consent-grant-via-registered-application.asciidoc[]
 include::rule-details/entra-id-mfa-disabled-for-user.asciidoc[]
 include::rule-details/entra-id-mfa-totp-brute-force-attempted.asciidoc[]
+include::rule-details/entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc[]
 include::rule-details/entra-id-oauth-authorization-code-grant-for-unusual-user-app-and-resource.asciidoc[]
 include::rule-details/entra-id-oauth-device-code-flow-with-concurrent-sign-ins.asciidoc[]
 include::rule-details/entra-id-oauth-device-code-grant-by-microsoft-authentication-broker.asciidoc[]
 include::rule-details/entra-id-oauth-device-code-grant-by-unusual-user.asciidoc[]
+include::rule-details/entra-id-oauth-device-code-phishing-via-aitm.asciidoc[]
 include::rule-details/entra-id-oauth-flow-by-microsoft-authentication-broker-to-device-registration-service-drs.asciidoc[]
 include::rule-details/entra-id-oauth-prt-issuance-to-non-managed-device-detected.asciidoc[]
 include::rule-details/entra-id-oauth-phishing-via-first-party-microsoft-application.asciidoc[]
 include::rule-details/entra-id-oauth-ropc-grant-login-detected.asciidoc[]
 include::rule-details/entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc[]
 include::rule-details/entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client.asciidoc[]
+include::rule-details/entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa.asciidoc[]
 include::rule-details/entra-id-powershell-sign-in.asciidoc[]
 include::rule-details/entra-id-privileged-identity-management-pim-role-modified.asciidoc[]
 include::rule-details/entra-id-protection-risk-detection.asciidoc[]
@@ -420,6 +428,7 @@ include::rule-details/entra-id-protection-risk-detection-user-risk.asciidoc[]
 include::rule-details/entra-id-protection-admin-confirmed-compromise.asciidoc[]
 include::rule-details/entra-id-protection-alerts-for-user-detected.asciidoc[]
 include::rule-details/entra-id-protection-user-alert-and-device-registration.asciidoc[]
+include::rule-details/entra-id-register-device-with-unusual-user-agent-azure-ad-join.asciidoc[]
 include::rule-details/entra-id-service-principal-created.asciidoc[]
 include::rule-details/entra-id-service-principal-credentials-created-by-unusual-user.asciidoc[]
 include::rule-details/entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc[]
@@ -590,6 +599,7 @@ include::rule-details/google-workspace-admin-role-deletion.asciidoc[]
 include::rule-details/google-workspace-bitlocker-setting-disabled.asciidoc[]
 include::rule-details/google-workspace-custom-admin-role-created.asciidoc[]
 include::rule-details/google-workspace-custom-gmail-route-created-or-modified.asciidoc[]
+include::rule-details/google-workspace-device-registration-after-oauth-from-suspicious-asn.asciidoc[]
 include::rule-details/google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc[]
 include::rule-details/google-workspace-mfa-enforcement-disabled.asciidoc[]
 include::rule-details/google-workspace-object-copied-to-external-drive-with-app-consent.asciidoc[]
@@ -672,14 +682,20 @@ include::rule-details/kubectl-network-configuration-modification.asciidoc[]
 include::rule-details/kubectl-permission-discovery.asciidoc[]
 include::rule-details/kubectl-workload-and-cluster-discovery.asciidoc[]
 include::rule-details/kubelet-api-connection-attempt-to-internal-ip.asciidoc[]
+include::rule-details/kubernetes-api-request-impersonating-privileged-identity.asciidoc[]
+include::rule-details/kubernetes-api-server-proxying-request-to-kubelet.asciidoc[]
+include::rule-details/kubernetes-admission-webhook-created-or-modified.asciidoc[]
 include::rule-details/kubernetes-anonymous-request-authorized-by-unusual-user-agent.asciidoc[]
 include::rule-details/kubernetes-anonymous-user-create-update-patch-pods-request.asciidoc[]
+include::rule-details/kubernetes-client-certificate-signing-request-created-or-approved.asciidoc[]
 include::rule-details/kubernetes-cluster-admin-role-binding-created.asciidoc[]
 include::rule-details/kubernetes-container-created-with-excessive-linux-capabilities.asciidoc[]
+include::rule-details/kubernetes-coredns-or-kube-dns-configuration-modified.asciidoc[]
 include::rule-details/kubernetes-creation-of-a-rolebinding-referencing-a-serviceaccount.asciidoc[]
 include::rule-details/kubernetes-creation-or-modification-of-sensitive-role.asciidoc[]
 include::rule-details/kubernetes-denied-service-account-request-via-unusual-user-agent.asciidoc[]
 include::rule-details/kubernetes-direct-api-request-via-curl-or-wget.asciidoc[]
+include::rule-details/kubernetes-ephemeral-container-added-to-pod.asciidoc[]
 include::rule-details/kubernetes-events-deleted.asciidoc[]
 include::rule-details/kubernetes-exposed-service-created-with-type-nodeport.asciidoc[]
 include::rule-details/kubernetes-forbidden-creation-request.asciidoc[]
@@ -708,10 +724,13 @@ include::rule-details/kubernetes-sensitive-configuration-file-activity.asciidoc[
 include::rule-details/kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc[]
 include::rule-details/kubernetes-service-account-modified-rbac-objects.asciidoc[]
 include::rule-details/kubernetes-service-account-secret-access.asciidoc[]
+include::rule-details/kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc[]
+include::rule-details/kubernetes-static-pod-manifest-file-access.asciidoc[]
 include::rule-details/kubernetes-suspicious-assignment-of-controller-service-account.asciidoc[]
 include::rule-details/kubernetes-suspicious-self-subject-review-via-unusual-user-agent.asciidoc[]
 include::rule-details/kubernetes-unusual-decision-by-user-agent.asciidoc[]
 include::rule-details/kubernetes-user-exec-into-pod.asciidoc[]
+include::rule-details/kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc[]
 include::rule-details/lsass-memory-dump-creation.asciidoc[]
 include::rule-details/lsass-memory-dump-handle-access.asciidoc[]
 include::rule-details/lsass-process-access-via-windows-api.asciidoc[]
@@ -761,7 +780,7 @@ include::rule-details/m365-exchange-malware-filter-policy-deleted.asciidoc[]
 include::rule-details/m365-exchange-malware-filter-rule-modified.asciidoc[]
 include::rule-details/m365-exchange-management-group-role-assigned.asciidoc[]
 include::rule-details/m365-identity-global-administrator-role-assigned.asciidoc[]
-include::rule-details/m365-identity-login-from-atypical-travel-location.asciidoc[]
+include::rule-details/m365-identity-login-from-atypical-region.asciidoc[]
 include::rule-details/m365-identity-login-from-impossible-travel-location.asciidoc[]
 include::rule-details/m365-identity-oauth-flow-by-first-party-microsoft-app-from-multiple-ips.asciidoc[]
 include::rule-details/m365-identity-oauth-flow-by-user-sign-in-to-device-registration.asciidoc[]
@@ -772,6 +791,7 @@ include::rule-details/m365-identity-user-account-lockouts.asciidoc[]
 include::rule-details/m365-identity-user-brute-force-attempted.asciidoc[]
 include::rule-details/m365-onedrive-malware-file-upload.asciidoc[]
 include::rule-details/m365-onedrive-sharepoint-excessive-file-downloads.asciidoc[]
+include::rule-details/m365-potential-aitm-userloggedin-via-office-app-tycoon2fa.asciidoc[]
 include::rule-details/m365-purview-dlp-signal.asciidoc[]
 include::rule-details/m365-purview-insider-risk-signal.asciidoc[]
 include::rule-details/m365-purview-security-compliance-signal.asciidoc[]
@@ -817,6 +837,7 @@ include::rule-details/microsoft-entra-id-exccessive-account-lockouts-detected.as
 include::rule-details/microsoft-exchange-server-um-spawning-suspicious-processes.asciidoc[]
 include::rule-details/microsoft-exchange-server-um-writing-suspicious-files.asciidoc[]
 include::rule-details/microsoft-exchange-worker-spawning-suspicious-processes.asciidoc[]
+include::rule-details/microsoft-graph-multi-category-reconnaissance-burst.asciidoc[]
 include::rule-details/microsoft-graph-request-email-access-by-unusual-user-and-client.asciidoc[]
 include::rule-details/microsoft-graph-request-user-impersonation-by-unusual-client.asciidoc[]
 include::rule-details/microsoft-iis-connection-strings-decryption.asciidoc[]
@@ -1116,13 +1137,15 @@ include::rule-details/potential-privilege-escalation-via-container-misconfigurat
 include::rule-details/potential-privilege-escalation-via-enlightenment.asciidoc[]
 include::rule-details/potential-privilege-escalation-via-installerfiletakeover.asciidoc[]
 include::rule-details/potential-privilege-escalation-via-linux-dac-permissions.asciidoc[]
-include::rule-details/potential-privilege-escalation-via-overlayfs.asciidoc[]
 include::rule-details/potential-privilege-escalation-via-pkexec.asciidoc[]
 include::rule-details/potential-privilege-escalation-via-python-cap-setuid.asciidoc[]
 include::rule-details/potential-privilege-escalation-via-recently-compiled-executable.asciidoc[]
+include::rule-details/potential-privilege-escalation-via-suid-sgid.asciidoc[]
 include::rule-details/potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc[]
 include::rule-details/potential-privilege-escalation-via-service-imagepath-modification.asciidoc[]
 include::rule-details/potential-privilege-escalation-via-sudoers-file-modification.asciidoc[]
+include::rule-details/potential-privilege-escalation-via-unshare-followed-by-root-process.asciidoc[]
+include::rule-details/potential-privilege-escalation-via-unshare-and-uid-change.asciidoc[]
 include::rule-details/potential-privileged-escalation-via-samaccountname-spoofing.asciidoc[]
 include::rule-details/potential-process-injection-from-malicious-document.asciidoc[]
 include::rule-details/potential-process-injection-via-powershell.asciidoc[]
@@ -1184,6 +1207,7 @@ include::rule-details/potential-webshell-deployed-via-apache-struts-cve-2023-501
 include::rule-details/potential-widespread-malware-infection-across-multiple-hosts.asciidoc[]
 include::rule-details/potential-windows-error-manager-masquerading.asciidoc[]
 include::rule-details/potential-windows-session-hijacking-via-ccmexec.asciidoc[]
+include::rule-details/potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc[]
 include::rule-details/potential-macos-ssh-brute-force-detected.asciidoc[]
 include::rule-details/potential-privilege-escalation-via-cve-2022-38028.asciidoc[]
 include::rule-details/potential-snap-confine-privilege-escalation-via-cve-2026-3888.asciidoc[]
@@ -1489,6 +1513,7 @@ include::rule-details/suspicious-remote-registry-access-via-sebackupprivilege.as
 include::rule-details/suspicious-renaming-of-esxi-files.asciidoc[]
 include::rule-details/suspicious-sip-check-by-macos-application.asciidoc[]
 include::rule-details/suspicious-suid-binary-execution.asciidoc[]
+include::rule-details/suspicious-suid-binary-execution-auditd-sequence.asciidoc[]
 include::rule-details/suspicious-screenconnect-client-child-process.asciidoc[]
 include::rule-details/suspicious-script-object-execution.asciidoc[]
 include::rule-details/suspicious-seincreasebasepriorityprivilege-use.asciidoc[]
diff --git a/docs/detections/prebuilt-rules/rule-details/adminsdholder-backdoor.asciidoc b/docs/detections/prebuilt-rules/rule-details/adminsdholder-backdoor.asciidoc
index 93466171da..35256e984a 100644
--- a/docs/detections/prebuilt-rules/rule-details/adminsdholder-backdoor.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/adminsdholder-backdoor.asciidoc
@@ -24,7 +24,7 @@ Detects modifications in the AdminSDHolder object. Attackers can abuse the SDPro
 *References*: 
 
 * https://adsecurity.org/?p=1906
-* https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory#adminsdholder
+* https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory
 
 *Tags*: 
 
@@ -37,7 +37,7 @@ Detects modifications in the AdminSDHolder object. Attackers can abuse the SDPro
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 215
+*Version*: 216
 
 *Rule authors*: 
 
@@ -53,47 +53,73 @@ Detects modifications in the AdminSDHolder object. Attackers can abuse the SDPro
 *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 AdminSDHolder Backdoor*
 
 
-The AdminSDHolder object in Active Directory is crucial for maintaining consistent permissions across privileged accounts. It ensures that any changes to these accounts are reverted to match the AdminSDHolder's settings. Adversaries exploit this by modifying the AdminSDHolder to create persistent backdoors, regaining administrative privileges. The detection rule identifies such abuses by monitoring specific directory service changes, focusing on modifications to the AdminSDHolder object, thus alerting security teams to potential threats.
-
 
 *Possible investigation steps*
 
 
-- Review the event logs for entries with event.code:5136 to identify specific changes made to the AdminSDHolder object.
-- Examine the winlog.event_data.ObjectDN field to confirm the object path is CN=AdminSDHolder,CN=System* and verify the nature of the modifications.
-- Identify the user account responsible for the changes by checking the event logs for the associated user information.
-- Investigate the history of the identified user account to determine if there are any other suspicious activities or patterns of behavior.
-- Assess the current permissions on the AdminSDHolder object and compare them with the expected baseline to identify unauthorized changes.
-- Check for any recent changes in group memberships or permissions of privileged accounts that could indicate exploitation of the AdminSDHolder backdoor.
-- Collaborate with the IT or security team to determine if the changes were authorized or if further action is needed to secure the environment.
+- What AdminSDHolder change did the alert preserve?
+  - Focus: confirm `winlog.event_data.ObjectDN` under AdminSDHolder, then read `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.OperationType`, `winlog.event_data.AttributeValue`, and `winlog.event_data.AttributeSyntaxOID`.
+  - Implication: escalate on "nTSecurityDescriptor", ownership data, or any value that can alter control of protected objects; lower concern only for non-security metadata tied to a recognized tier-0 maintenance workflow.
+
+- What did the correlated 5136 operation contain?
+  - Why: one alert document may show only part of a logical directory change; `winlog.event_data.OpCorrelationID` reconstructs the rest of the operation.
+  - Focus: review same-controller `5136` events for the same `host.id`, `winlog.computer_name`, and `winlog.event_data.OpCorrelationID`; compare attribute, value, and operation type. !{investigate{"description":"","label":"All 5136 events in this AdminSDHolder change set","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.OpCorrelationID","queryType":"phrase","value":"{{winlog.event_data.OpCorrelationID}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Implication: escalate when the operation adds multiple ACL changes, touches unrelated sensitive attributes, or suggests a staged AdminSDHolder template rewrite; lower concern only when bounded to one expected non-security update on the same object.
+
+- Does the recovered value grant or preserve access that SDProp can stamp onto protected identities?
+  - Why: AdminSDHolder is the ACL template for protected accounts and groups, so a small template edit can become persistent privileged access after SDProp runs.
+  - Focus: interpret attribute name, value, and syntax for a new trustee, ACE, owner reference, or delegated right rather than non-security metadata.
+  - Implication: escalate when the value adds a SID, DN, ACE, owner path, Full Control, Modify, WriteDacl, WriteOwner, or GenericAll outside the expected tier-0 admin set; truncated or opaque values keep permission impact unresolved and require preserving raw change data.
+
+- Who initiated the modification, and where did the session originate?
+  - Focus: identify the writer and controller with `user.id`, `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectLogonId`, and `winlog.computer_name`.
+  - Hint: on the same `winlog.computer_name`, match `5136` `winlog.event_data.SubjectLogonId` to `4624` `winlog.event_data.TargetLogonId`; search `4648` for the same `winlog.event_data.SubjectLogonId` when explicit credentials matter, then read `source.ip` and `winlog.event_data.AuthenticationPackageName`. Missing linked authentication records or `source.ip` leaves origin unresolved, not benign.
+    - !{investigate{"description":"","label":"Linked logon for the modifying session","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Explicit credential events for the modifying session","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Implication: escalate when the writer is unexpected, source or auth method does not fit tier-0 administration, or origin remains unresolved with a security-relevant change; do not wait on auth pivots when the attribute/value and change set already prove unauthorized rights.
+
+- Did the template change propagate or get forced onto protected objects?
+  - Why: SDProp can apply the AdminSDHolder template to protected accounts and groups, so impact may appear after the initial directory-change event.
+  - Focus: on the same `winlog.event_data.DSName` or `winlog.computer_name`, review later `5136` events for object, attribute, writer, and time on protected users or groups.
+  - Hint: if the logging controller has no follow-on records, search the same `winlog.event_data.DSName` across domain controllers; absence on one controller does not clear propagation. !{investigate{"description":"","label":"Later 5136 changes in the same directory service","providers":[[{"excluded":false,"field":"winlog.event_data.DSName","queryType":"phrase","value":"{{winlog.event_data.DSName}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}}
+  - Implication: escalate when later events show security-descriptor, owner, or trustee changes on protected identities after the AdminSDHolder edit; no follow-on `5136` visibility leaves propagation unresolved, not benign.
+
+- Escalate when object, security-relevant attribute/value, `winlog.event_data.OpCorrelationID`, writer/session origin, or propagation evidence shows unauthorized control; close only when the exact change, bounded `5136` set, actor/session origin, and available change or baseline record all point to one recognized tier-0 workflow; preserve directory-change evidence and escalate mixed or incomplete answers. If local answers stay suspicious or unresolved, review alerts for the modifying `user.id`; use controller `host.id` alert history only when actor evidence is sparse or controller compromise is plausible.
+    - !{investigate{"description":"","label":"Recent alerts tied to this modifying identity","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":"Recent alerts on this domain controller","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"}}
 
 
 *False positive analysis*
 
 
-- Routine administrative changes to the AdminSDHolder object can trigger alerts. To manage this, establish a baseline of expected changes and create exceptions for these known activities.
-- Scheduled maintenance or updates to Active Directory may result in temporary modifications to the AdminSDHolder object. Document these events and exclude them from triggering alerts during the maintenance window.
-- Automated scripts or tools used for Active Directory management might modify the AdminSDHolder object as part of their normal operation. Identify these tools and whitelist their activities to prevent false positives.
-- Changes made by trusted security personnel or systems should be logged and reviewed. Implement a process to verify and exclude these changes from alerting if they are part of approved security operations.
+- AdminSDHolder ACL hardening, delegated-directory cleanup, security-baseline tooling, or migration automation are narrow tier-0 exceptions, not routine administration. Confirm the exact attribute/value/operation for `winlog.event_data.ObjectDN`, expected admin or service-account session, bounded `winlog.event_data.OpCorrelationID`, matching controller/template rollout, and no unrelated actor or controller alerts. If change records, automation inventory, or deployment records exist, require alignment; otherwise prove the current actor/action or service-account/template fit from telemetry first, then use prior recurrence only to support exception stability.
+- Before creating an exception, validate recurrence of the same `user.id` or `winlog.event_data.SubjectUserSid`, specific attribute, object, `winlog.event_data.DSName`, bounded operation shape, and controller pattern across prior alerts from this rule. Build the exception from that minimum confirmed workflow only after the current event is fully explained, and avoid exceptions on AdminSDHolder changes, Windows Security event "5136", or the rule name alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
-- Revert any unauthorized changes to the AdminSDHolder object by restoring it from a known good backup or manually resetting its permissions to the default secure state.
-- Conduct a thorough review of all privileged accounts and groups to ensure their permissions align with organizational security policies and have not been altered to match the compromised AdminSDHolder settings.
-- Reset passwords for all accounts that were potentially affected or had their permissions altered, focusing on privileged accounts to prevent adversaries from regaining access.
-- Implement additional monitoring on the AdminSDHolder object and other critical Active Directory objects to detect any future unauthorized modifications promptly.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach, including identifying any other compromised systems or accounts.
-- Review and update access control policies and security configurations to prevent similar attacks, ensuring that only authorized personnel have the ability to modify critical Active Directory objects.
+- If confirmed benign, reverse any temporary containment and record the exact actor, session, AdminSDHolder object, changed attribute, operation-correlation, and controller pattern that proved the recognized workflow. Do not keep a broad exception unless the same workflow recurs.
+- If suspicious but unconfirmed, preserve the triggering `5136` event, the correlated `winlog.event_data.OpCorrelationID` change set, the current AdminSDHolder security descriptor, linked `4624` or `4648` session records, and case exports before containment. Apply reversible containment first, such as temporarily restricting the modifying account's directory-write path or increasing monitoring on the recovered actor and controller. Use broader account disablement or domain-controller isolation only if related alerts or follow-on directory abuse show active compromise and the AD response owner accepts the operational impact.
+- If confirmed malicious, export the current AdminSDHolder security descriptor, recovered `5136` change set, replication context, implicated object identity, actor SID, logon session, and source-origin evidence before rollback or account action. Contain the modifying account and any recovered source endpoint or IP through identity-response or endpoint-response tooling; if direct response is unavailable, escalate that preserved evidence set to the AD or incident-response team that can act.
+- After containment, review protected users and groups for unauthorized ACEs, owner changes, or delegated rights that may have been restamped from the tampered template before removing them. Restore the AdminSDHolder ACL to a known-good state, verify clean replication across domain controllers, then reset or rotate privileged credentials exposed or newly granted through the unauthorized template.
+- Post-incident hardening: restrict AdminSDHolder write access to dedicated tier-0 administration paths, baseline the expected AdminSDHolder security descriptor, keep directory-service change auditing for `5136` and linked authentication logging enabled on domain controllers, and record telemetry gaps that limited the investigation.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Audit Directory Service Changes must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-directory-service-changes
+
 
 ==== Rule query
 
diff --git a/docs/detections/prebuilt-rules/rule-details/adminsdholder-sdprop-exclusion-added.asciidoc b/docs/detections/prebuilt-rules/rule-details/adminsdholder-sdprop-exclusion-added.asciidoc
index 6dd6327b54..0469cf4479 100644
--- a/docs/detections/prebuilt-rules/rule-details/adminsdholder-sdprop-exclusion-added.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/adminsdholder-sdprop-exclusion-added.asciidoc
@@ -37,7 +37,7 @@ Identifies a modification on the dsHeuristics attribute on the bit that holds th
 * Use Case: Active Directory Monitoring
 * Data Source: Windows Security Event Logs
 
-*Version*: 218
+*Version*: 219
 
 *Rule authors*: 
 
@@ -57,44 +57,59 @@ Identifies a modification on the dsHeuristics attribute on the bit that holds th
 *Investigating AdminSDHolder SDProp Exclusion Added*
 
 
-The SDProp process compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, it resets the permissions on the protected accounts and groups to match those defined in the domain AdminSDHolder object.
 
-The dSHeuristics is a Unicode string attribute, in which each character in the string represents a heuristic that is used to determine the behavior of Active Directory.
+*Possible investigation steps*
 
-Administrators can use the dSHeuristics attribute to exclude privilege groups from the SDProp process by setting the 16th bit (dwAdminSDExMask) of the string to a certain value, which represents the group(s):
 
-- For example, to exclude the Account Operators group, an administrator would modify the string, so the 16th character is set to 1 (i.e., 0000000001000001).
+- What did the 5136 record do to the SDProp exclusion mask?
+  - Focus: `winlog.event_data.OperationType` and `winlog.event_data.AttributeValue`; decode position "1" = Account Operators, "2" = Server Operators, "4" = Print Operators, "8" = Backup Operators, with additive hex combinations.
+  - Implication: escalate when an added or replaced value leaves any operator group excluded from SDProp, especially multiple groups; lower concern only when paired 5136 records prove removal and rollback to 0. If the active mask is unproven, treat as unresolved.
 
-The usage of this exclusion can leave the accounts unprotected and facilitate the misconfiguration of privileges for the excluded groups, enabling attackers to add accounts to these groups to maintain long-term persistence with high privileges.
+- Did the change land on the forest configuration object controlling SDProp behavior?
+  - Focus: `winlog.event_data.ObjectDN`, `winlog.event_data.DSName`, and `host.name`.
+  - Implication: forest-impacting when `winlog.event_data.ObjectDN` is the Directory Service object under "CN=Windows NT,CN=Services,CN=Configuration" and the naming context is in scope; narrow only when `winlog.event_data.DSName` and `host.name` identify a lab or recovery forest.
 
-This rule matches changes of the dsHeuristics object where the 16th bit is set to a value other than zero.
+- Which identity changed "dSHeuristics", and does it fit directory configuration work?
+  - Focus: `user.id`, `user.name`, `user.domain`, and `winlog.event_data.SubjectLogonId`.
+  - Implication: suspicious when the writer is not a dedicated directory-configuration identity for the affected forest; reduce concern only when identity and object match confirmed hardening or recovery.
 
+- What source session produced the directory change?
+  - Why: the 5136 event names the writer, but session origin separates console or jump-host administration from remote or alternate-credential use.
+  - Focus: on the domain controller, find 4624 events where `winlog.event_data.TargetLogonId` equals the 5136 `winlog.event_data.SubjectLogonId`; read `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Linked logon for the modifying session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Hint: search 4648 by `winlog.event_data.SubjectLogonId` when explicit-credential use would change the answer. !{investigate{"description":"","label":"Explicit credential events for the modifying session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Hint: Missing authentication telemetry is unresolved, not benign.
+  - Implication: escalate for unexpected workstation, direct DC logon, remote-interactive path, NTLM where Kerberos is expected, or explicit-credential use; reduce concern when origin, logon type, and authentication package fit the confirmed directory-configuration case.
 
-*Possible investigation steps*
+- Did the same operation or session change other privileged directory state?
+  - Why: SDProp exclusion is most damaging with AdminSDHolder ACL, privileged membership, delegation, or security-descriptor changes that persist because SDProp no longer resets excluded groups.
+  - Focus: 5136 events on the same `host.id` where `winlog.event_data.OpCorrelationID` matches, then the same `winlog.event_data.SubjectLogonId` if needed; read `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeLDAPDisplayName`, and `winlog.event_data.AttributeValue`. !{investigate{"description":"","label":"All 5136 events in this SDProp exclusion change set","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.OpCorrelationID","queryType":"phrase","value":"{{winlog.event_data.OpCorrelationID}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Range: inspect the alert burst first; if the mask stayed non-zero, extend through the weakened interval for follow-on membership, ACL, delegation, or security-descriptor changes on excluded groups.
+  - Implication: escalate when the same burst touches AdminSDHolder, privileged groups, delegation attributes, or security descriptors; lower suspicion only when grouped changes stay limited to one intentional SDProp configuration action.
 
+- If local evidence remains suspicious or unresolved, do related alerts change scope or urgency?
+  - Focus: recent alerts for the same `user.id`. !{investigate{"description":"","label":"Alerts associated with the writer","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: also review domain controller `host.id` when controller compromise or change spread remains unresolved. !{investigate{"description":"","label":"Alerts associated with the domain controller","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 response when the writer or controller has related AD tampering, unusual authentication, privilege abuse, persistence, credential-access, or lateral-movement alerts; keep scope local only when related alerts are quiet and local telemetry supports a bounded explanation.
 
-- 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.
-- Check the value assigned to the 16th bit of the string on the `winlog.event_data.AttributeValue` field:
-    - Account Operators eq 1
-    - Server Operators eq 2
-    - Print Operators eq 4
-    - Backup Operators eq 8
-    The field value can range from 0 to f (15). If more than one group is specified, the values will be summed together; for example, Backup Operators and Print Operators will set the `c` value on the bit.
+- Escalate for an active non-zero in-scope mask, abnormal writer or source session, or grouped privileged changes; close only when mask, operation, scope, writer, session, and grouped 5136 prove rollback to 0 or confirmed hardening/testing without contradictions; preserve and escalate mixed or incomplete cases.
 
 
 *False positive analysis*
 
 
-- While this modification can be done legitimately, it is not a best practice. Any potential benign true positive (B-TP) should be mapped and reviewed by the security team for alternatives as this weakens the security of the privileged group.
+- Treat non-zero SDProp exclusions as suspicious. Directory hardening or delegated-admin redesign is benign only when excluded operator groups were intentionally stripped of privileged rights and a dedicated configuration workflow made the change. Confirm `winlog.event_data.AttributeValue` maps to the planned group set, `winlog.event_data.ObjectDN` and `winlog.event_data.DSName` identify the expected Directory Service object, `user.id` and recovered `source.ip` identify the authorized admin session, and `winlog.event_data.OpCorrelationID` activity stays bounded to maintenance. If evidence is unavailable, the alert remains unresolved; do not close from repetition.
+- Lab-forest or recovery-forest testing may intentionally change "dSHeuristics". Confirm `winlog.event_data.DSName` and `host.name` place the event in that forest, `user.id` and `winlog.event_data.SubjectLogonId` identify the designated test administrator, and related alerts on `host.id` lack unrelated credential-access, persistence, or lateral-movement activity. If records are unavailable, treat as unresolved unless another reliable source confirms forest identity and administrator.
+- Before creating an exception, validate recurrence for the same `user.id`, `host.id`, `winlog.event_data.ObjectDN`, `winlog.event_data.DSName`, `winlog.event_data.AttributeValue`, and bounded `winlog.event_data.OpCorrelationID` pattern. Avoid exceptions on "dSHeuristics", event 5136, or rule name alone.
 
 
 *Response and remediation*
 
 
-- The change can be reverted by setting the dwAdminSDExMask (16th bit) to 0 in dSHeuristics.
-- 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).
+- If confirmed benign, reverse temporary containment and document the mask, object scope, writer, session origin, controller, and confirmation source proving the authorized workflow. Keep exceptions tied to the recurring workflow pattern, not the attribute or event code.
+- If suspicious but unconfirmed, preserve triggering and grouped 5136 records, linked 4624 or 4648 authentication records, and key identifiers: `winlog.event_data.ObjectGUID`, `winlog.event_data.OpCorrelationID`, `user.id`, `host.id`, and recovered `source.ip`. Apply reversible containment tied to those findings: restrict the implicated account from directory-configuration changes, increase DC monitoring, or contain the recovered source host if not a critical controller. Escalate to account disablement or host isolation only when related alerts or session evidence show broader abuse.
+- If confirmed malicious, preserve directory-change and authentication evidence before changing configuration. Restore "dSHeuristics" to the expected value, verify rollback replication on other domain controllers, and review the same `winlog.event_data.OpCorrelationID` or `winlog.event_data.SubjectLogonId` for unauthorized directory changes. Contain the writer account or recovered source host with identity or endpoint response tooling; avoid isolating a domain controller unless broader compromise is confirmed and directory owners can tolerate the action.
+- After containment, check whether excluded operator groups received unauthorized membership, ACL, delegation, or security-descriptor changes while SDProp protection was weakened, and roll back only malicious changes identified.
+- Post-incident hardening: keep Windows Security 5136 directory-service auditing enabled on domain controllers, restrict "dSHeuristics" changes to dedicated directory-configuration workflows, reduce or remove privileged rights from built-in operator groups where possible, and record visibility gaps or adjacent variants for engineering review.
 
 
 ==== Setup
@@ -104,19 +119,8 @@ This rule matches changes of the dsHeuristics object where the 16th bit is set t
 *Setup*
 
 
-The 'Audit Directory Service Changes' logging policy must be configured for (Success).
-Steps to implement the logging policy with Advanced Audit Configuration:
-
-```
-Computer Configuration >
-Policies >
-Windows Settings >
-Security Settings >
-Advanced Audit Policies Configuration >
-Audit Policies >
-DS Access >
-Audit Directory Service Changes (Success)
-```
+Audit Directory Service Changes must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-directory-service-changes
 
 
 ==== Rule query
@@ -126,6 +130,7 @@ Audit Directory Service Changes (Success)
 ----------------------------------
 any where host.os.type == "windows" and event.code == "5136" and
   winlog.event_data.AttributeLDAPDisplayName : "dSHeuristics" and
+  winlog.event_data.OperationType : "%%14674" and
   length(winlog.event_data.AttributeValue) > 15 and
   winlog.event_data.AttributeValue regex~ "[0-9]{15}([1-9a-f]).*"
 
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-eks-access-entry-granted-cluster-admin-policy.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-eks-access-entry-granted-cluster-admin-policy.asciidoc
new file mode 100644
index 0000000000..9158dfde84
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/aws-eks-access-entry-granted-cluster-admin-policy.asciidoc
@@ -0,0 +1,128 @@
+[[aws-eks-access-entry-granted-cluster-admin-policy]]
+=== AWS EKS Access Entry Granted Cluster Admin Policy
+
+Detects when the AmazonEKSClusterAdminPolicy or AmazonEKSAdminPolicy is associated with a principal via the EKS Access Entries API. This grants full cluster-admin equivalent access to the specified IAM user or role. Unlike the legacy aws-auth ConfigMap which is only visible in Kubernetes audit logs, Access Entries modifications appear in CloudTrail, providing an additional detection surface. Attackers who have obtained IAM permissions to manage EKS access entries can use this API to backdoor cluster access for persistence, mapping attacker-controlled IAM identities to cluster-admin privileges without modifying any Kubernetes resources.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html
+* https://docs.aws.amazon.com/eks/latest/APIReference/API_AssociateAccessPolicy.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Kubernetes
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS CloudTrail
+* 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 AWS EKS Access Entry Granted Cluster Admin Policy*
+
+
+Successful AssociateAccessPolicy with AmazonEKSClusterAdminPolicy or AmazonEKSAdminPolicy binds highly privileged
+Kubernetes access to an IAM principal. Review who invoked the API (user.name, aws.cloudtrail.user_identity fields),
+source.ip, user_agent.original, cloud.account.id, and cloud.region.
+
+
+*Possible investigation steps*
+
+
+- Parse aws.cloudtrail.request_parameters and response elements for cluster name, access entry ARN, and policy ARN.
+- Confirm whether the IAM principal receiving the policy is expected to have cluster-admin-class access.
+- Correlate with other EKS API calls (CreateAccessEntry, UpdateAccessEntry) and with Kubernetes audit activity from
+  newly authorized principals.
+- Compare against change records for migrations from aws-auth or new administrator onboarding.
+
+
+*Response and remediation*
+
+
+- If unauthorized, disassociate the policy or remove the access entry per AWS guidance; audit who can call eks:*
+  APIs in IAM.
+- Rotate credentials for any suspected compromised IAM principal; review organizational SCPs and cluster auth mode.
+
+
+*Additional information*
+
+
+- https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html[Amazon EKS access entries]
+- https://docs.aws.amazon.com/eks/latest/APIReference/API_AssociateAccessPolicy.html[AssociateAccessPolicy]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"aws.cloudtrail" and
+event.provider:"eks.amazonaws.com" and
+event.action:"AssociateAccessPolicy" and
+event.outcome:"success" and
+aws.cloudtrail.request_parameters:(*AmazonEKSClusterAdminPolicy* or *AmazonEKSAdminPolicy*)
+
+----------------------------------
+
+*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/rule-details/aws-eks-access-entry-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-eks-access-entry-modified.asciidoc
new file mode 100644
index 0000000000..174df18224
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/aws-eks-access-entry-modified.asciidoc
@@ -0,0 +1,123 @@
+[[aws-eks-access-entry-modified]]
+=== AWS EKS Access Entry Modified
+
+Detects successful Amazon EKS Access Entries API operations that create, update, attach, detach, or delete authentication mappings between IAM principals and the cluster. Changes to access entries alter who can authenticate to Kubernetes and what Kubernetes-level permissions they receive, without requiring edits to in-cluster RBAC objects. Unexpected callers or timing may indicate persistence or privilege abuse. Common automation identities (service-linked roles, eksctl, Terraform, CloudFormation role patterns) are excluded to reduce noise; tune further for your deployment pipelines.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-aws.cloudtrail-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Kubernetes
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS CloudTrail
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Privilege Escalation
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating AWS EKS Access Entry Modified*
+
+
+Review aws.cloudtrail.user_identity (ARN, type), user.name, source.ip, user_agent.original, cloud.account.id, and
+cloud.region. Map event.action to intent: new principal (CreateAccessEntry), policy binding changes (AssociateAccessPolicy,
+DisassociateAccessPolicy), metadata updates (UpdateAccessEntry), or removal (DeleteAccessEntry).
+
+
+*Possible investigation steps*
+
+
+- Inspect aws.cloudtrail.request_parameters and response_elements for cluster name, principal ARN, and policy ARNs.
+- Compare against change management and infrastructure-as-code deploy windows.
+- Correlate with Kubernetes audit logs for subsequent API activity from identities tied to the affected access entry.
+- Pair with the higher-fidelity rule EKS Access Entry Granted Cluster Admin Policy when AssociateAccessPolicy fires.
+
+
+*Response and remediation*
+
+
+- If unauthorized, revert access entry changes via AWS APIs or console; restrict eks:* permissions and review SCPs.
+- Rotate credentials for compromised IAM principals as appropriate.
+
+
+*Additional information*
+
+
+- https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html[Amazon EKS access entries]
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"aws.cloudtrail" and event.provider:"eks.amazonaws.com" and
+event.action:("CreateAccessEntry" or "AssociateAccessPolicy" or "UpdateAccessEntry" or "DisassociateAccessPolicy" or "DeleteAccessEntry") and
+event.outcome:"success" and
+not aws.cloudtrail.user_identity.arn:(*AWSServiceRoleForAmazonEKS* or *eksctl* or *terraform* or *AWSCloudFormation*)
+
+----------------------------------
+
+*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 Container Cluster Roles
+** ID: T1098.006
+** Reference URL: https://attack.mitre.org/techniques/T1098/006/
+* 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/
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-eks-control-plane-logging-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-eks-control-plane-logging-disabled.asciidoc
new file mode 100644
index 0000000000..873e3ec12c
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/aws-eks-control-plane-logging-disabled.asciidoc
@@ -0,0 +1,102 @@
+[[aws-eks-control-plane-logging-disabled]]
+=== AWS EKS Control Plane Logging Disabled
+
+Detects successful Amazon EKS UpdateClusterConfig requests that disable control plane logging. Disabling EKS API server and control plane logs can reduce visibility into cluster activity and may indicate defense evasion following compromised AWS credentials or unauthorized administrative access. EKS control plane logging changes are typically rare and should align with approved maintenance or cost optimization workflows.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-aws.cloudtrail-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html
+* https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Kubernetes
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS CloudTrail
+* 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 EKS Control Plane Logging Disabled*
+
+
+Review the caller (user.name, aws.cloudtrail.user_identity.arn, type), source.ip, user_agent.original, cloud.account.id, and cloud.region. Confirm which log types were disabled and whether the change aligns with a planned change window.
+
+
+*Possible investigation steps*
+
+
+- Inspect aws.cloudtrail.request_parameters and response elements for cluster name and logging settings.
+- Correlate with adjacent EKS and IAM activity from the same principal (access entry changes, iam policy attachments, sts assume events) and with any Kubernetes audit telemetry available.
+- Check whether control plane logs stopped ingesting shortly after the change and scope potential visibility gaps.
+
+
+*Response and remediation*
+
+
+- If unauthorized, re-enable EKS control plane logging and restrict IAM permissions that allow eks:UpdateClusterConfig.
+- Rotate or revoke compromised credentials and review for additional EKS or IAM persistence changes.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"aws.cloudtrail" and
+event.provider:"eks.amazonaws.com" and
+event.action:"UpdateClusterConfig" and
+event.outcome:"success" and
+aws.cloudtrail.request_parameters:*logging*enabled=false*
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
+* Sub-technique:
+** Name: Disable or Modify Cloud Logs
+** ID: T1562.008
+** Reference URL: https://attack.mitre.org/techniques/T1562/008/
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-ssm-session-manager-child-process-execution.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ssm-session-manager-child-process-execution.asciidoc
index d80bfe4e76..b196ba9638 100644
--- a/docs/detections/prebuilt-rules/rule-details/aws-ssm-session-manager-child-process-execution.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/aws-ssm-session-manager-child-process-execution.asciidoc
@@ -13,9 +13,9 @@ Identifies process start events where the parent process is the AWS Systems Mana
 * logs-crowdstrike.fdr*
 * logs-sentinel_one_cloud_funnel.*
 
-*Severity*: low
+*Severity*: medium
 
-*Risk score*: 21
+*Risk score*: 47
 
 *Runs every*: 5m
 
@@ -44,7 +44,7 @@ Identifies process start events where the parent process is the AWS Systems Mana
 * Data Source: SentinelOne
 * Resources: Investigation Guide
 
-*Version*: 1
+*Version*: 2
 
 *Rule authors*: 
 
@@ -112,7 +112,8 @@ event.category: "process" and event.action : ("exec" or "exec_event" or "start"
  ) and 
  process.command_line:* and 
  not (process.name : "powershell.exe" and process.args :("$str.Substring($str.length" or *Convert-GuidToCompressedGuid* or get-wmiobject* or $wmi_proc* or *win32_quickfixengineering*)) and 
- not process.executable : ("/usr/bin/lscpu" or "/usr/bin/snap" or "/usr/bin/rpm" or "/usr/bin/dpkg-query" or /snap/snapd/*/usr/bin/snap or "/usr/bin/id" or "C:\\Program Files\\Amazon\\SSM\\Plugins\\SessionManagerShell\\winpty-agent.exe")
+ not process.executable : ("/usr/bin/lscpu" or "/usr/bin/snap" or "/usr/bin/rpm" or "/usr/bin/dpkg-query" or /snap/snapd/*/usr/bin/snap or "/usr/bin/id" or "C:\\Program Files\\Amazon\\SSM\\Plugins\\SessionManagerShell\\winpty-agent.exe") and 
+ not (process.name : (dash or bash or sh or _script.sh) and process.args : /var/lib/amazon/ssm/*/document/orchestration/*/_script.sh)
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/bypass-uac-via-event-viewer.asciidoc b/docs/detections/prebuilt-rules/rule-details/bypass-uac-via-event-viewer.asciidoc
index dca392c52e..5572c142c1 100644
--- a/docs/detections/prebuilt-rules/rule-details/bypass-uac-via-event-viewer.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/bypass-uac-via-event-viewer.asciidoc
@@ -35,7 +35,6 @@ Identifies User Account Control (UAC) bypass via eventvwr.exe. Attackers bypass
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Privilege Escalation
-* Tactic: Defense Evasion
 * Resources: Investigation Guide
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
@@ -45,7 +44,7 @@ Identifies User Account Control (UAC) bypass via eventvwr.exe. Attackers bypass
 * Data Source: SentinelOne
 * Data Source: Crowdstrike
 
-*Version*: 322
+*Version*: 323
 
 *Rule authors*: 
 
@@ -65,61 +64,86 @@ Identifies User Account Control (UAC) bypass via eventvwr.exe. Attackers bypass
 *Investigating Bypass UAC via Event Viewer*
 
 
-Windows User Account Control (UAC) allows a program to elevate its privileges (tracked as low to high integrity levels) to perform a task under administrator-level permissions, possibly by prompting the user for confirmation. UAC can deny an operation under high-integrity enforcement, or allow the user to perform the action if they are in the local administrators group and enter an administrator password when prompted.
 
-For more information about the UAC and how it works, check the https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works[official Microsoft docs page].
+*Possible investigation steps*
 
-During startup, `eventvwr.exe` checks the registry value of the `HKCU\Software\Classes\mscfile\shell\open\command` registry key for the location of `mmc.exe`, which is used to open the `eventvwr.msc` saved console file. If the location of another binary or script is added to this registry value, it will be executed as a high-integrity process without a UAC prompt being displayed to the user. This rule detects this UAC bypass by monitoring processes spawned by `eventvwr.exe` other than `mmc.exe` and `werfault.exe`.
 
-> **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.
+- What did Event Viewer launch in the alert?
+  - Focus: alert time, host/user scope, `process.parent.executable`, `process.executable`, `process.command_line`, and integrity level.
+  - Implication: escalate when eventvwr.exe launches an unexpected high-integrity child or script/LOLBIN command instead of the normal console or error-reporting helper; lower suspicion only when path normalization proves helper behavior or fields match controlled UAC testing.
 
+- Does the child payload identity and command line fit helper behavior or payload execution?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.command_line`.
+  - Hint: use `process.pe.original_file_name` when path, filename, or signer conflicts suggest masquerading.
+  - Implication: escalate when the child is unsigned, rare, user-writable, signer-mismatched, or runs PowerShell, cmd.exe, rundll32.exe, mshta.exe, wscript.exe, regsvr32.exe, remote retrieval, encoded content, or admin-path writes; lower suspicion only when identity, signer, hash history, and command intent fit controlled testing or helper behavior.
 
-*Possible investigation steps*
+- What started Event Viewer, and did the session fit an interactive admin task?
+  - Focus: recover the Event Viewer start using `host.id` + `process.parent.entity_id`, then review executable, command line, and logon type. !{investigate{"description":"","label":"Event Viewer parent process event","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `process.parent.entity_id` is absent, use `host.id` + `process.parent.pid` in a tight `@timestamp` window; PID-only recovery is weaker. Inspect `process.Ext.ancestry` only when direct lineage is incomplete.
+  - Implication: escalate when Office, browser, archive, scripting, RMM, or remote/noninteractive activity launched Event Viewer; lower suspicion only when launcher and session also support controlled testing or helper behavior. Routine Event Viewer use should open Microsoft Management Console, not an arbitrary child.
 
+- Is there corroborating current-user mscfile hijack evidence when process evidence stays suspicious?
+  - Focus: if registry telemetry exists, review current-user mscfile shell-open command content, creator/deleter process, and timing; HKCU may render as HKEY_USERS\<user SID>\Software\Classes\mscfile\shell\open\command.
+  - Hint: use this as corroboration, not as a prerequisite for escalation. Missing registry telemetry is unresolved, not benign; absence of the key after the alert can mean cleanup.
+  - Implication: escalate or raise confidence when the value points to the alert child, a script interpreter, a temp/user path, or was created or removed around the alert; lower suspicion only when artifact evidence fits the same confirmed test or helper behavior already supported by process evidence.
 
-- 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.
-- Inspect the host for suspicious or abnormal behavior in the alert timeframe.
-- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes.
-- Examine the host for derived artifacts that indicate suspicious activities:
-  - Analyze the process executable using a private sandboxed analysis system.
-  - Observe and collect information about the following activities in both the sandbox and the alert subject host:
-    - Attempts to contact external domains and addresses.
-      - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.
-      - Examine the DNS cache for suspicious or anomalous entries.
-        - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}}
-    - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
-    - Examine the host services for suspicious or anomalous entries.
-      - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}}
-      - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}}
-      - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}}
-  - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
-- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.
+- What did the elevated child do next?
+  - Focus: child process events where `process.parent.entity_id` matches `process.entity_id`; review executable, command line, and integrity level. !{investigate{"description":"","label":"Process starts from the elevated child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}}
+  - Hint: prefer entity-ID matches; if only PID matches are available, keep them tightly anchored to `@timestamp`.
+  - Implication: escalate when the elevated child spawns shells, discovery, credential tools, droppers, installers, persistence helpers, or network-capable tooling; do not close on absent follow-on children when the original command, lineage, or mscfile evidence remains suspicious.
 
+- Does the same Event Viewer payload pattern recur beyond this host?
+  - Range: run only when local process, command, artifact, or lineage evidence remains suspicious or unresolved.
+  - Focus: `process.hash.sha256`, stable command-line fragments, and `process.executable`, scoped by host and user.
+    - !{investigate{"description":"","label":"Recent process starts with the same child identity","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Alerts associated with the user or host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}],[{"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 the same payload or Event Viewer child pattern appears for unrelated hosts or users; keep locally scoped when recurrence is limited to the same confirmed test cohort and no contradictory local evidence remains.
+
+- Based on the evidence gathered, what disposition is supported?
+  - Escalate on strong local abuse signals across child behavior, payload identity, command intent, launcher/session, mscfile artifacts, follow-on children, or scope; close only when process evidence and recovery prove helper normalization or controlled testing; preserve evidence and escalate when registry corroboration is unavailable or evidence is mixed.
 
 
 *False positive analysis*
 
 
-- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+- This behavior is an operational anti-pattern. Realistic benign paths are controlled UAC testing or a sensor/path-normalization miss for expected Microsoft Management Console (mmc.exe) or Windows Error Reporting (WerFault.exe) child activity. Confirm identity, launcher/session context, command line, and any recovered mscfile artifact support the same benign explanation; if any dimension contradicts it, do not close as benign.
+- Build exceptions from the minimum confirmed pattern: stable child hash or signer, exact Event Viewer parent-child relationship, bounded `user.id` and `host.id`, and test or normalization evidence. Avoid exceptions on `process.parent.name`, `process.name`, or `user.name` alone.
 
 
 *Response and remediation*
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Isolate the involved host to prevent further post-compromise behavior.
-- If the triage identified malware, search the environment for additional compromised hosts.
-  - Implement temporary network rules, procedures, and segmentation to contain the malware.
-  - Stop suspicious processes.
-  - Immediately block the identified indicators of compromise (IoCs).
-  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
-- Remove and block malicious artifacts identified during triage.
-- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
-- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
-- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+- If confirmed benign, document the exact evidence that resolved the alert, reverse temporary containment, and keep any exception scoped to the confirmed child identity, parent-child pattern, and host/user cohort.
+- If suspicious but unconfirmed, preserve the alert, process event exports, Event Viewer parent and child entity IDs, command lines, hashes/signers, recovered mscfile value/history, child process tree, and process-scoped file or network indicators when available.
+- After preservation, apply reversible containment tied to the findings, such as endpoint isolation for non-critical hosts or temporary egress restrictions for confirmed suspicious destinations. Weigh host criticality before isolation.
+- If confirmed malicious, preserve the confirmed hashes/domains/destinations and elevated child process details, then isolate the host as needed, block confirmed malicious indicators, and suspend or terminate malicious processes only after recording their evidence.
+- Eradicate only the artifacts found during triage: remove malicious payloads, restore the current-user mscfile handler to the expected mmc.exe behavior or remove the malicious override, clean related persistence, and remediate the entry vector that launched Event Viewer.
+- Reset credentials or disable accounts only when process/session evidence shows credential exposure, explicit misuse, or attacker use of the affected `user.id`.
+- After eradication, reduce repeat exposure by reviewing local administrator membership, using the highest feasible UAC prompt level, and patching affected Windows builds.
+
+
+==== 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
diff --git a/docs/detections/prebuilt-rules/rule-details/cobalt-strike-command-and-control-beacon.asciidoc b/docs/detections/prebuilt-rules/rule-details/cobalt-strike-command-and-control-beacon.asciidoc
index 560048fe3a..ab912678a8 100644
--- a/docs/detections/prebuilt-rules/rule-details/cobalt-strike-command-and-control-beacon.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/cobalt-strike-command-and-control-beacon.asciidoc
@@ -35,7 +35,7 @@ Cobalt Strike is a threat emulation platform commonly modified and used by adver
 * Domain: Endpoint
 * Resources: Investigation Guide
 
-*Version*: 108
+*Version*: 109
 
 *Rule authors*: 
 
@@ -104,7 +104,7 @@ This activity has been observed in FIN7 campaigns.
 
 [source, js]
 ----------------------------------
-((event.category: (network OR network_traffic) AND type: (tls OR http))
+((event.category: (network OR network_traffic) AND network.protocol: (tls OR http))
     OR data_stream.dataset: (network_traffic.tls OR network_traffic.http)
 ) AND destination.domain:/[a-z]{3}.stage.[0-9]{8}\..*/
 
diff --git a/docs/detections/prebuilt-rules/rule-details/command-and-scripting-interpreter-via-windows-scripts.asciidoc b/docs/detections/prebuilt-rules/rule-details/command-and-scripting-interpreter-via-windows-scripts.asciidoc
index db59acbf74..a47eb9b11e 100644
--- a/docs/detections/prebuilt-rules/rule-details/command-and-scripting-interpreter-via-windows-scripts.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/command-and-scripting-interpreter-via-windows-scripts.asciidoc
@@ -1,7 +1,7 @@
 [[command-and-scripting-interpreter-via-windows-scripts]]
 === Command and Scripting Interpreter via Windows Scripts
 
-Identifies PowerShell.exe or Cmd.exe execution spawning from Windows Script Host processes Wscript.exe.
+Identifies PowerShell, PowerShell ISE, or Cmd execution spawned from Windows Script Host or MSHTA.
 
 *Rule type*: eql
 
@@ -42,7 +42,7 @@ Identifies PowerShell.exe or Cmd.exe execution spawning from Windows Script Host
 * Data Source: Elastic Endgame
 * Data Source: Crowdstrike
 
-*Version*: 210
+*Version*: 211
 
 *Rule authors*: 
 
@@ -58,46 +58,85 @@ Identifies PowerShell.exe or Cmd.exe execution spawning from Windows Script Host
 *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 Command and Scripting Interpreter via Windows Scripts*
 
 
-PowerShell, a powerful scripting language in Windows, is often targeted by adversaries for executing malicious scripts. Attackers exploit Windows Script Host processes like cscript or wscript to launch PowerShell with obfuscated commands, evading detection. The detection rule identifies such suspicious activity by monitoring PowerShell executions with specific patterns and parent processes, while filtering out known legitimate use cases to reduce false positives.
-
 
 *Possible investigation steps*
 
 
-- Review the process command line and arguments to identify any obfuscation patterns or suspicious commands, such as Base64 encoding or web requests, that match the query's suspicious patterns.
-- Examine the parent process details, specifically focusing on wscript.exe, cscript.exe, or mshta.exe, to determine if the PowerShell execution was initiated by a legitimate script or a potentially malicious one.
-- Check the process execution context, including the user account and host, to assess if the activity aligns with expected behavior for that user or system.
-- Investigate any network connections or file downloads initiated by the PowerShell process, especially those involving external IP addresses or domains, to identify potential data exfiltration or further malicious activity.
-- Correlate the alert with other security events or logs from the same host or user to identify any preceding or subsequent suspicious activities that could indicate a broader attack campaign.
+- What script-host-to-interpreter chain did the alert capture?
+  - Focus: `process.parent.name`, `process.parent.executable`, `process.parent.command_line`, `process.name`, and `process.command_line`.
+  - Implication: escalate when "wscript.exe" or "mshta.exe" launches PowerShell/pwsh/ISE/cmd from user-writable script/HTA, archive, download path, or URL; lower suspicion only when parent source, child command, `user.id`, and `host.id` fit one recognized logon, deployment, or vendor workflow.
+
+- Does the child command express staging, retrieval, persistence, or defense evasion?
+  - Focus: `process.command_line`: "-EncodedCommand"/"-e", "-NoProfile", hidden windows, execution-policy bypass, Invoke-Expression/DownloadString, cmd "/c" chaining, curl/bitsadmin retrieval, or schtasks/sc.exe changes.
+  - Hint: decode or reconstruct encoded or inline PowerShell before deciding intent; use script-block logs as optional corroboration.
+  - Follow-on: inspect child starts from `process.entity_id`; PID-only matches are timestamp-bound candidates. !{investigate{"description":"","label":"Child process events for the script-launched process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the command fetches content, decodes or executes inline script, launches another shell, or changes tasks/services; lower risk only when it runs a local script from the same logon, deployment, or vendor source without staging or unexpected egress.
+
+- Does the child binary identity fit the observed command line and location?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the child is renamed, unsigned or untrusted from a user-writable path, or mismatched to original file name; lower identity risk when signer, path, and hash history fit the expected interpreter, but identity alone never clears suspicious command intent.
+
+- Did the alerting process stage scripts, archives, or follow-on payloads?
+  - Focus: file events scoped by `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` in a tight window, checking `file.path`, `file.Ext.original.path`, `file.Ext.original.extension`, `file.Ext.header_bytes`, and `file.Ext.windows.zone_identifier`. !{investigate{"description":"","label":"File events for the script-launched 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"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: for PID fallback, require file time within the child lifetime.
+  - Implication: escalate when the child writes or renames scriptable or executable content under temp, profile, public, startup, or deceptive paths, especially with internet provenance or type/extension mismatch; absent file telemetry is unresolved, not benign.
+
+- Did same-process network events show retrieval, staging, or callback behavior?
+  - Focus: network events scoped by `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` in a tight window, separating DNS `dns.question.name` and `dns.resolved_ip` from connection `destination.ip`, `destination.port`, and `destination.as.organization.name`. !{investigate{"description":"","label":"Network events for the script-launched 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"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: map DNS `dns.resolved_ip` to later connections before treating a domain as confirmed.
+  - Implication: escalate when the process reaches external script-delivery, paste, storage, or C2 infra unrelated to the workflow; lower network risk when connections stay on recognized internal, proxy, or vendor services. Missing network telemetry is unresolved, not benign.
+
+- If local evidence stays suspicious or unresolved, does the same pattern appear in related alerts?
+  - Focus: related alerts for `user.id`, checking execution, persistence, defense-evasion, or outbound context before comparing preserved `process.parent.executable`, `process.parent.command_line`, or `process.command_line` fragments. !{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: use `host.id` alerts to test whether the chain is isolated, repeats with suspicious activity, or appears as adjacent variants such as "cscript.exe" launchers or delayed descendant shells. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same user or host shows repeated script-host launches, task or service changes, persistence, or outbound staging; keep local only when the pattern is isolated and local evidence supports one recognized workflow.
+
+- Escalate when parent provenance, command intent, identity, artifacts, destinations, or related alerts support proxy execution or second-stage activity; close only when alert-local evidence and recovery bind one recognized workflow, with outside confirmation for telemetry gaps; preserve artifacts and escalate when evidence conflicts or visibility is incomplete.
 
 
 *False positive analysis*
 
 
-- Legitimate PowerShell commands using non-shortened execution flags may trigger false positives. To manage this, exclude processes with arguments like "-EncodedCommand", "Import-Module*", and "-NonInteractive" unless they are associated with suspicious activity.
-- Third-party installation scripts, such as those related to Microsoft System Center or WebLogic, can cause false positives. Exclude these by filtering out specific parent process arguments or command lines, such as "Microsoft.SystemCenter.ICMPProbe.WithConsecutiveSamples.vbs" and "WEBLOGIC_ARGS_CURRENT_1.DATA".
-- Routine administrative tasks, like gathering network information, may be flagged. Exclude known scripts like "gatherNetworkInfo.vbs" from detection to prevent unnecessary alerts.
-- Exclude specific user scripts or tools that are known to be safe, such as those located in user directories like "C:\Users\Prestige\AppData\Local\Temp\Rar$*\KMS_VL_ALL_AIO.cmd" if they are verified as non-malicious.
-- Regularly review and update exclusion lists to ensure they reflect current legitimate activities and do not inadvertently allow new threats.
+- Logon scripts and deployment wrappers can legitimately launch cmd or PowerShell through Windows Script Host. Confirm only when `process.parent.executable`, `process.parent.command_line`, `process.command_line`, `user.id`, `host.id`, and same-process `file.path` or `destination.ip` recovered through `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` in a tight window, align with one recognized workflow. If file or network telemetry is absent, use outside confirmation. Stable recurrence for that parent source, child command, user, and host can support closure when script inventory or change context exists; first-observed workflows need outside confirmation before exceptioning. Any mismatch keeps the case suspicious.
+- Vendor/installer/hardware-diagnostic HTA/VBS launchers can trigger this rule. Confirm only when `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, parent script path, file writes, and destinations match one vendor package. Without package context, recurring signer/hash, parent source, child command, and host cohort can support closure; first-observed packages need outside confirmation.
+- For exceptions, validate: `process.parent.executable`, `process.parent.command_line`, child `process.executable`, stable `process.command_line` fragment, `process.code_signature.subject_name`, `user.id`, and `host.id`. Avoid exceptions on `process.name`, child `process.executable`, or parent process name alone.
 
 
 *Response and remediation*
 
 
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious execution.
-- Conduct a thorough review of the affected system's PowerShell execution logs to identify any additional malicious scripts or commands that may have been executed.
-- Remove any malicious scripts or files identified during the investigation from the system to prevent re-execution.
-- Restore the system from a known good backup if any critical system files or configurations have been altered by the malicious activity.
-- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- If confirmed benign, reverse temporary containment and record the parent script path, child command pattern, signer, `user.id`, and `host.id` proving the workflow. Create exceptions only for exact workflows recurring in prior rule alerts.
+- If suspicious but unconfirmed, preserve the process event, `process.entity_id` or `process.pid` with `host.id` and time, command lines, suspicious `file.path` values, and confirmed `dns.question.name`, `destination.ip`, or `destination.port` before response. Apply reversible containment first: temporary destination blocking, disabling newly created scripts or tasks, or heightened host monitoring. Isolate only when corroborating staging, persistence, or outbound activity is confirmed and interruption is tolerable. Avoid destructive cleanup until scope is clearer.
+- If confirmed malicious, preserve `process.entity_id`, `process.parent.entity_id`, command lines, written `file.path` artifacts, and confirmed destinations, then isolate the host or block destinations based on staging and network evidence. Terminate malicious child or descendant processes after evidence capture; if direct endpoint response is unavailable, hand off artifacts for isolation or destination blocking.
+- Review related hosts and users for the same parent-child command pattern, confirmed destinations, and confirmed staged files only when endpoint file telemetry or related alerts preserve them. Then remove malicious scripts, HTA content, scheduled tasks, or dropped payloads, and remediate the delivery path.
+- Post-incident hardening: restrict unsupported "mshta.exe" and Windows Script Host use on workstations, retain process/file/network telemetry needed for this investigation, and record adjacent variants found during triage.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires telemetry from one of the configured source integrations to be enabled and ingested.
+
+
+*Supported data sources*
+
+
+This rule can use the following 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
 
diff --git a/docs/detections/prebuilt-rules/rule-details/conhost-spawned-by-suspicious-parent-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/conhost-spawned-by-suspicious-parent-process.asciidoc
index 6bbbf963e1..ca3da6b418 100644
--- a/docs/detections/prebuilt-rules/rule-details/conhost-spawned-by-suspicious-parent-process.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/conhost-spawned-by-suspicious-parent-process.asciidoc
@@ -26,7 +26,7 @@ Detects when the Console Window Host (conhost.exe) process is spawned by a suspi
 
 *References*: 
 
-* https://www.fireeye.com/blog/threat-research/2017/08/monitoring-windows-console-activity-part-one.html
+* https://cloud.google.com/blog/topics/threat-intelligence/monitoring-windows-console-activity-part-one
 
 *Tags*: 
 
@@ -34,8 +34,6 @@ Detects when the Console Window Host (conhost.exe) process is spawned by a suspi
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Execution
-* Tactic: Defense Evasion
-* Tactic: Privilege Escalation
 * Resources: Investigation Guide
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
@@ -43,7 +41,7 @@ Detects when the Console Window Host (conhost.exe) process is spawned by a suspi
 * Data Source: Microsoft Defender XDR
 * Data Source: SentinelOne
 
-*Version*: 313
+*Version*: 314
 
 *Rule authors*: 
 
@@ -63,57 +61,80 @@ Detects when the Console Window Host (conhost.exe) process is spawned by a suspi
 *Investigating Conhost Spawned By Suspicious Parent Process*
 
 
-The Windows Console Host, or `conhost.exe`, is both the server application for all of the Windows Console APIs as well as the classic Windows user interface for working with command-line applications.
 
-Attackers often rely on custom shell implementations to avoid using built-in command interpreters like `cmd.exe` and `PowerShell.exe` and bypass application allowlisting and security features. Attackers commonly inject these implementations into legitimate system processes.
+*Possible investigation steps*
 
 
-*Possible investigation steps*
+- Is the alerting "conhost.exe" the native console host, and which parent requested the console?
+  - Why: Windows creates "conhost.exe" for console clients; service, COM, logon, or shell parents rarely need direct console allocation.
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.parent.executable`, and `process.parent.command_line`.
+  - Implication: escalate if "conhost.exe" is renamed, outside the Windows directory, mismatched to its PE name, not Microsoft-signed, or if parent path and command line contradict its name; lower only when native child and parent identity fit one exact MSI, compatibility, or WebDAV helper action explaining direct parentage.
 
+- Does the parent identity, lineage, and session fit a legitimate console allocation path?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.code_signature.subject_name`, `process.Ext.ancestry`, and `process.Ext.session_info.logon_type`.
+  - Implication: escalate when system/logon, COM/LOLBin, or shell/input parents run from unexpected paths, have unfamiliar signers, appear in unexpected ancestry, or allocate a console in a mismatched session; lower when signed parent command line and session fit one bounded MSI custom action, Program Compatibility Assistant, or WebDAV workflow.
 
-- 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 abnormal behaviors observed by the subject process, such as network connections, registry or file modifications, and any spawned child processes.
-- Investigate other alerts associated with the user/host during the past 48 hours.
-- Inspect the host for suspicious or abnormal behavior in the alert timeframe.
-- Retrieve the parent process executable 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.
+- Did the same parent launch a shell, script host, LOLBin, or payload around the alert?
+  - Focus: same-host child process events by `process.parent.entity_id`; if absent, use `host.id`, `process.parent.pid`, and a tight alert-time window, then read child `process.executable`, `process.command_line`, and signer. !{investigate{"description":"","label":"Process starts from the same suspicious parent","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if clean but parent identity remains suspicious, check for pre-existing console or shell processes in the same `host.id` and session before closure.
+  - Implication: escalate when the parent starts shells, script hosts, downloaders, task/service tools, or unsigned payloads; lower only when "conhost.exe" is the lone unusual child and earlier evidence proves an exact bounded parent workflow, but do not close on this alone because attackers can reuse an existing console or shell.
 
+- If file or registry telemetry is available, did the same parent stage artifacts or change configuration?
+  - Focus: match parent `process.parent.entity_id` to actor `process.entity_id` on `host.id`; if absent, match parent/actor PID in a tight alert window, then read `file.path`. !{investigate{"description":"","label":"File events from the same suspicious parent","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: use the same joins for `registry.path`. !{investigate{"description":"","label":"Registry events from the same suspicious parent","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} Missing file or registry telemetry is unresolved, not benign.
+  - Implication: escalate when the parent writes executables or scripts, stages console clients, or changes persistence or security configuration; absent optional artifacts lower corroboration only and do not close.
 
-*False positive analysis*
+- If DNS or network telemetry is available, did the same parent contact staging, remote-control, or lateral destinations?
+  - Focus: match parent `process.parent.entity_id` to actor `process.entity_id` on `host.id`; if absent, match parent/actor PID in a tight alert window, then read DNS "lookup_result" events (`dns.question.name`, `dns.resolved_ip`) separately from connections (`destination.ip`). !{investigate{"description":"","label":"Network events from the same suspicious parent","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: missing DNS or network telemetry is unresolved, not benign; correlate `dns.resolved_ip` to `destination.ip` before treating a domain as contacted.
+  - Implication: escalate when the parent reaches public or internal destinations unrelated to the workflow, WebDAV/SMB destinations, or unexpected internal systems; lower only when destinations fit the same MSI, Program Compatibility Assistant, or WebDAV workflow proven by process evidence.
 
+- If the parent path, child execution, artifacts, or destinations remain suspicious or unexplained, do related alerts change scope or urgency?
+  - Focus: recent `host.id` alerts, especially process injection, indirect execution, suspicious shell, credential, or C2 activity. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: review the same `user.id` only when the local evidence suggests the operator or session may have moved to other systems. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same host or user has related injection, shell, credential, or C2 alerts; keep the case local when isolated and earlier process evidence fits one exact recognized workflow.
 
-- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+- Escalate for masqueraded parent, unexpected ancestry, unexplained console allocation, suspicious follow-on execution, staging, or remote-control corroboration; close only when native "conhost.exe" identity, parent identity/lineage, session, child processes, optional artifact or destination evidence, and related alerts align with one recognized installer, compatibility, or WebDAV workflow with no contradictions; if mixed or incomplete, preserve evidence and escalate.
 
 
-*Related rules*
+*False positive analysis*
 
 
-- Suspicious Process from Conhost - 28896382-7d4f-4d50-9b72-67091901fd26
-- Suspicious PowerShell Engine ImageLoad - 852c1f19-68e8-43a6-9dce-340771fe1be3
+- Installer repair, MSI custom actions, Program Compatibility Assistant activity, and WebDAV helpers can allocate "conhost.exe" from signed parents. Confirm parent path/command/signer, `process.executable`, `user.id`, and `host.id` describe one exact workflow, same-parent children show no shells, script hosts, LOLBins, or payloads, and optional file, registry, DNS, or network telemetry does not contradict it. Use change records, inventories, or owner confirmation only after telemetry fits.
+- Without organizational context, telemetry-only confirmation must prove the current event fits that workflow. Historical alerts corroborate only when the same parent path, signer, command line, child, user/host, and bounded child pattern recur without contradictions; do not close on recurrence while parentage or follow-on execution remains unexplained.
+- Before an exception, validate the minimum stable pattern: parent executable, command line, signer, child executable, `user.id`, and `host.id`. Avoid exceptions on "conhost.exe", parent name, or broad signers alone.
 
 
 *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.
-- 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).
+- If confirmed benign, reverse temporary containment, document native child identity, parent path/signer/command, session, `user.id`, `host.id`, and corroboration, and create exceptions only for the recurring minimum pattern above.
+- If suspicious but unconfirmed, preserve the alert export, parent/child timeline, entity IDs, command lines, artifact/destination indicators, and owner/change evidence before containment. Apply reversible controls first: temporary destination blocking or heightened `host.id` / `user.id` monitoring; disable a task, service, or startup item only after identifying it as malicious. Escalate to isolation or account action only when follow-on execution, persistence, remote control, or credential abuse is confirmed and the asset can tolerate interruption.
+- If confirmed malicious, isolate the host when unauthorized parent execution, payload launch, persistence, or remote control is confirmed, after weighing host role. Record parent/payload process IDs and command lines before suspending or terminating processes, then block confirmed malicious destinations, hashes, or domains.
+- Eradicate only malicious parent/payload artifacts and configuration changes. Review other hosts/users for the same parent path, command line, child executable, artifact, or destination before deleting payloads, removing persistence, restoring settings, or closing the execution vector.
+- Post-incident hardening: tighten the exposed MSI, Program Compatibility Assistant, or WebDAV workflow, and record variants such as existing-console reuse, injected "explorer.exe", or service-host console abuse.
+
+
+==== 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
diff --git a/docs/detections/prebuilt-rules/rule-details/container-runtime-cli-execution-with-suspicious-arguments.asciidoc b/docs/detections/prebuilt-rules/rule-details/container-runtime-cli-execution-with-suspicious-arguments.asciidoc
new file mode 100644
index 0000000000..dbb4154394
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/container-runtime-cli-execution-with-suspicious-arguments.asciidoc
@@ -0,0 +1,140 @@
+[[container-runtime-cli-execution-with-suspicious-arguments]]
+=== Container Runtime CLI Execution with Suspicious Arguments
+
+Detects execution of container runtime CLI tools (ctr, crictl, nerdctl) with arguments indicating container creation, command execution inside existing containers, image manipulation, or host filesystem mounting. These tools interact directly with the container runtime socket, bypassing the Kubernetes API server, RBAC authorization, admission webhooks, pod security standards, and Kubernetes audit logging entirely. Attackers with host-level access may use these tools to create privileged ghost containers, exec into other pods to steal service account tokens and secrets, pull attacker-controlled images, and destroy evidence, all while remaining invisible to Kubernetes-level monitoring.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* auditbeat-*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1609/
+* https://book.hacktricks.xyz/linux-hardening/privilege-escalation/containerd-ctr-privilege-escalation
+
+*Tags*: 
+
+* Data Source: Auditd Manager
+* Data Source: Elastic Defend
+* Domain: Container
+* Domain: Endpoint
+* OS: Linux
+* 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 Container Runtime CLI Execution with Suspicious Arguments*
+
+
+Review the full argv list and working directory. Confirm whether the session is interactive, whether the image or bundle
+referenced is trusted, and whether bind mounts or privileged flags target host paths such as `/`, `/etc`, or Docker
+sockets.
+
+
+*Possible investigation steps*
+
+
+- Reconstruct the container ID or snapshot key passed to `tasks`, `snapshots`, or `content` subcommands.
+- Correlate with file, network, and Kubernetes audit activity for pulls from unusual registries or subsequent pod
+  changes.
+- Check whether the parent should legitimately be kubelet, containerd, or systemd on that host class.
+
+
+*Response and remediation*
+
+
+- If unauthorized, isolate the node, revoke credentials available to the session, and hunt for new privileged
+  workloads or image imports.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Requires process execution telemetry with arguments from **Elastic Defend** (`logs-endpoint.events.process*`) and/or
+**Auditd Manager** / Auditbeat (`logs-auditd_manager.auditd-*`, `auditbeat-*`).
+
+Ensure exec-related auditing captures full argv for `ctr`, `crictl`, and `nerdctl`. See
+https://docs.elastic.co/integrations/auditd_manager
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "executed") and
+(
+  (
+    process.name in ("ctr", "crictl", "nerdctl") and
+    (
+      (process.args == "tasks" and process.args == "exec") or
+      (process.args == "run" and process.args in ("--privileged", "--rm", "--mount", "--net-host", "--pid-host")) or
+      (process.args == "snapshots" and process.args == "mount")
+    )
+  ) or
+  (
+    (process.executable like ("/dev/shm/*", "/tmp/*", "/var/tmp/*") or process.name : ".*") and
+    process.args like ("*containerd.sock*", "k8s.io")
+  )
+) and
+not process.parent.executable in (
+  "/usr/bin/kubelet", "/usr/local/bin/kubelet",
+  "/usr/bin/containerd", "/usr/sbin/containerd",
+  "/lib/systemd/systemd", "/usr/lib/systemd/systemd", "/sbin/init"
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Container Administration Command
+** ID: T1609
+** Reference URL: https://attack.mitre.org/techniques/T1609/
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Escape to Host
+** ID: T1611
+** Reference URL: https://attack.mitre.org/techniques/T1611/
diff --git a/docs/detections/prebuilt-rules/rule-details/creation-of-a-hidden-local-user-account.asciidoc b/docs/detections/prebuilt-rules/rule-details/creation-of-a-hidden-local-user-account.asciidoc
index 0987231ff9..20084928c1 100644
--- a/docs/detections/prebuilt-rules/rule-details/creation-of-a-hidden-local-user-account.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/creation-of-a-hidden-local-user-account.asciidoc
@@ -44,7 +44,7 @@ Identifies the creation of a hidden local user account by appending the dollar s
 * Data Source: SentinelOne
 * Data Source: Crowdstrike
 
-*Version*: 316
+*Version*: 317
 
 *Rule authors*: 
 
@@ -64,34 +64,79 @@ Identifies the creation of a hidden local user account by appending the dollar s
 *Investigating Creation of a Hidden Local User Account*
 
 
-Attackers can create accounts ending with a `$` symbol to make the account hidden to user enumeration utilities and bypass detections that identify computer accounts by this pattern to apply filters.
 
-This rule uses registry events to identify the creation of local hidden accounts.
+*Possible investigation steps*
 
 
-*Possible investigation steps*
+- What hidden local account did the SAM write create?
+  - Why: a `$` suffix is ambiguous in many logs, but `registry.path` under `SAM\SAM\Domains\Account\Users\Names` is a local account-name entry and can be omitted from casual `net user` review.
+  - Focus: `registry.hive`, `registry.path`, `registry.key`, and `@timestamp` for the exact account name and creation time.
+  - Implication: high concern unless the exact `$`-suffixed account, `host.id`, and time fit one narrowly recognized provisioning or recovery workflow; lower concern only when creator, use, and scope checks do not contradict it.
+
+- Which process and parent caused the SAM entry?
+  - Focus: `process.entity_id`, `process.executable`, `process.command_line`, `process.parent.executable`, and `process.parent.command_line`.
+  - Implication: escalate for shells, script interpreters, remote-service launchers such as sc.exe, service-created cmd/net user chains, PsExec-like tools, user-writable binaries, or mismatched parents; lower concern only when creator path, parent, and arguments match one recognized account-management workflow.
+
+- Did the creator or its children perform other account, privilege, or persistence actions?
+  - Why: remote account creation can surface as a service-launched command, and the decisive `net user`, local-group, or cleanup action may be in the creator's process tree rather than the registry event alone.
+  - Focus: same-host registry and process activity for creator `process.entity_id` and child `process.parent.entity_id`: `process.command_line`, `registry.path`, `registry.value`, and `registry.data.strings`. !{investigate{"description":"","label":"Creator process and child activity on this host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"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"},{"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":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Hint: if the parent is service-control or PsExec-like, keep service-created cmd/net user children in scope even when signed.
+  - Implication: escalate when the tree adds local-group membership, touches extra SAM or LSA paths, deletes staging commands, or creates other persistence; lower concern when activity stays limited to the recovered account inside the same recognized workflow.
+
+- Was the hidden account used by later process activity after creation?
+  - Why: remote or service use of `$`-suffixed accounts may leave little profile evidence, so process and session context carries more weight than profile artifacts.
+  - Focus: extract the account leaf from `registry.path`, then search same-host process starts after `@timestamp` where `user.name` matches it, reading `process.Ext.session_info.logon_type`, `process.executable`, and `process.command_line`.
+  - Hint: this pivot is manual unless the account name is normalized into a standalone alert field; avoid using the full SAM registry path as an account value.
+  - Implication: account use after creation strongly escalates when the account runs processes, appears in remote-interactive, network, service, or batch sessions, or launches administrative tooling; lower concern only when no process use appears and creator evidence fits a recognized provisioning path.
 
+- If local evidence is suspicious or unresolved, do recent same-actor or same-host alerts change scope?
+  - Focus: related alerts for creating `user.id` and `host.id`: account abuse, privilege escalation, remote execution, credential access, or additional persistence.
+  - Hint: use the creating-identity alert pivot. !{investigate{"description":"","label":"Alerts associated with the creating identity","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: use the host alert pivot. !{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 response when the same actor or host has related account, persistence, or privilege alerts; keep local when history is clean and local evidence already fits one recognized workflow.
 
-- Identify the user account that performed the action and whether it should perform this kind of action.
-- 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.
+- What disposition is supported?
+  - Escalate for unexpected account or creator lineage, privilege or cleanup activity, later account use, or wider scope; close only when same-host telemetry proves one exact recognized workflow, using records only as corroboration; preserve evidence and escalate when answers stay mixed or incomplete.
 
 
 *False positive analysis*
 
 
-- This activity is unlikely to happen legitimately. Benign true positive (B-TPs) can be added as exceptions if necessary.
+- A pre-established local support-account provisioning or recovery workflow can create a `$`-suffixed local account, but close only on a complete telemetry match: exact `registry.path`, creator `process.executable`, `process.command_line`, parent process, `user.id`, and `host.id`, with no extra SAM, LSA, privilege-grant, or cleanup activity outside it. Use build, vendor, or maintenance records only to corroborate that match; never close or exception on records alone.
+- Treat one-off interactive creation, remote service-created cmd.exe or net.exe, script-driven creation, and creation on ordinary workstations or servers as suspicious by default. Hidden support accounts elsewhere or a signed creator binary are not enough to close.
+- Build exceptions only from the minimum confirmed workflow: exact hidden-account `registry.path`, stable creator executable and command pattern, parent workflow, `user.id`, and bounded `host.id` cohort. Avoid exceptions on all `$`-suffixed names, the SAM hive, `process.name` alone, or the rule name.
 
 
 *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.
-- Delete the hidden account.
-- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed.
-- 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).
+- If confirmed benign, reverse temporary containment and record the exact account path, creator lineage, user, and host cohort that proved the recurring workflow. Keep any exception as narrow as that confirmed pattern.
+- If suspicious but unconfirmed, export the alert, the triggering registry event, creator process details, current hidden-account state, privilege evidence found in process or registry review, and any process or session use by the hidden account before containment. Apply reversible actions first: disable the account, restrict its logon rights, or increase monitoring on the affected `host.id` and creating `user.id`; avoid deleting the account until evidence is preserved.
+- If confirmed malicious, preserve account state, creator process lineage, and related registry or process artifacts first. Then isolate the host when its role allows, disable the hidden account, and contain the creating identity or remote source when the evidence identifies one. After preservation and containment, remove unauthorized privilege, SAM, LSA, service, or scheduled-task changes introduced around the same time.
+- Post-incident hardening: restrict hidden support-account creation to controlled management tooling, audit the host for other local accounts ending in `$`, retain registry and process telemetry needed to reconstruct future account creation, and document blind spots around preexisting hidden accounts or later privilege grants.
+
+
+==== 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-reg-setup[Sysmon Registry Events]
 
 
 ==== Rule query
@@ -99,7 +144,7 @@ This rule uses registry events to identify the creation of local hidden accounts
 
 [source, js]
 ----------------------------------
-registry where host.os.type == "windows" and event.type == "change" and
+registry where host.os.type == "windows" and event.type in ("change", "creation") and
   registry.path : (
     "HKLM\\SAM\\SAM\\Domains\\Account\\Users\\Names\\*$\\",
     "\\REGISTRY\\MACHINE\\SAM\\SAM\\Domains\\Account\\Users\\Names\\*$\\",
diff --git a/docs/detections/prebuilt-rules/rule-details/curl-or-wget-execution-from-container-context.asciidoc b/docs/detections/prebuilt-rules/rule-details/curl-or-wget-execution-from-container-context.asciidoc
index 3d9b304697..fca48e896b 100644
--- a/docs/detections/prebuilt-rules/rule-details/curl-or-wget-execution-from-container-context.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/curl-or-wget-execution-from-container-context.asciidoc
@@ -37,7 +37,7 @@ Detects execution of curl or wget from processes whose title aligns with **`runc
 * Data Source: Auditd Manager
 * Resources: Investigation Guide
 
-*Version*: 1
+*Version*: 2
 
 *Rule authors*: 
 
@@ -131,7 +131,8 @@ process.title:"runc init" and
 (
   process.name:(curl or wget) or
   process.args:(* curl* or */bin/curl* or *wget*)
-)
+) and 
+not process.args :(*127.0.0.1* or *localhost* or "wget --no-verbose --tries=1 --spider --no-check-certificate http://${WEB_HOST}:${WEB_PORT}/api/ping || exit 1")
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/delegated-managed-service-account-modification-by-an-unusual-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/delegated-managed-service-account-modification-by-an-unusual-user.asciidoc
index df12baa478..9007c88071 100644
--- a/docs/detections/prebuilt-rules/rule-details/delegated-managed-service-account-modification-by-an-unusual-user.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/delegated-managed-service-account-modification-by-an-unusual-user.asciidoc
@@ -1,7 +1,7 @@
 [[delegated-managed-service-account-modification-by-an-unusual-user]]
 === Delegated Managed Service Account Modification by an Unusual User
 
-Detects modifications in the msDS-ManagedAccountPrecededByLink attribute of a delegated managed service account by an unusual subject account. Attackers can abuse this attribute to take over the permission of a target account and inherit it's permissions allowing them to further elevate privileges.
+Detects modifications to the msDS-ManagedAccountPrecededByLink attribute of a delegated managed service account by an unusual subject account. Attackers can abuse this attribute to inherit a target account's permissions and further elevate privileges.
 
 *Rule type*: new_terms
 
@@ -36,7 +36,7 @@ Detects modifications in the msDS-ManagedAccountPrecededByLink attribute of a de
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 3
+*Version*: 4
 
 *Rule authors*: 
 
@@ -59,27 +59,62 @@ Detects modifications in the msDS-ManagedAccountPrecededByLink attribute of a de
 
 *Possible investigation steps*
 
-- Examine the winlog.event_data.SubjectUserName field and verify if he is allowed and used to perform this kind of dMSA changes.
-- Examine the winlog.event_data.AttributeValue field to verify the targeted account and if it's supposed to use dMSA.
-- Examine if there are any recent dMSA account creation by the same winlog.event_data.SubjectUserName.
-- Investigate the history of the identified user account to determine if there are any other suspicious activities or patterns of behavior.
-- Collaborate with the IT or security team to determine if the changes were authorized or if further action is needed to secure the environment.
+
+- What dMSA link did the alert record?
+  - Focus: confirm 5136 with `winlog.event_data.AttributeLDAPDisplayName` "msDS-ManagedAccountPrecededByLink"; read `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectClass`, `winlog.event_data.AttributeValue`, and `winlog.event_data.OperationType` for dMSA, superseded account DN, and change type.
+  - Implication: escalate when the link targets a privileged, sync, backup, or widely trusted service account, or the modified object is unexpected; lower suspicion only when object, link, and change type fit one low-impact migration pair.
+- Did the controller operation look like bounded dMSA migration or direct link write?
+  - Why: real migration should not be a lone sensitive attribute write; BadSuccessor risk rises when the link is isolated or paired with unrelated high-impact changes.
+  - Focus: review same-controller 5136 changes by `winlog.event_data.OpCorrelationID`; compare `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.OperationType`, and `winlog.event_data.AttributeValue`. !{investigate{"description":"","label":"Directory changes for the same operation on this controller","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.OpCorrelationID","queryType":"phrase","value":"{{winlog.event_data.OpCorrelationID}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if the operation ID is incomplete, query 5136 on `host.id` plus `winlog.event_data.SubjectLogonId` for same-session dMSA or privileged-object changes.
+  - Implication: escalate on standalone link write, unexpected value replacement, or unrelated ACL, delegation, SPN, or service-account changes; lower suspicion when same-operation or same-session changes stay bounded to one expected migration pair.
+- Who wrote the link, and does the identity fit dMSA management?
+  - Focus: use `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, `winlog.event_data.SubjectLogonId`, and `winlog.computer_name` to identify writer, controller session, and service vs human.
+  - Implication: escalate when the writer is an unfamiliar human, helpdesk account, or low-privilege service identity for dMSA management; keep unresolved when a recognized writer is not tied to the exact dMSA pair.
+- Did the writer session originate from an expected source and logon type?
+  - Focus: pivot from `winlog.event_data.SubjectLogonId` and `host.id` to authentication where `winlog.event_data.TargetLogonId` matches; review `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Authentication events for the writer session on this controller","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: search 4648 on `winlog.event_data.SubjectLogonId` for explicit-credential use; missing authentication records or `source.ip` are unresolved, not benign.
+  - Implication: escalate when the session starts from an unexpected host, uses unusual interactive/RDP logon, or shows explicit-credential behavior outside the writer's role; expected source and logon type support closure only after link target and operation cohere.
+- Did the linked dMSA or superseded account authenticate from unexpected systems after the change?
+  - Why: risk peaks when the new dMSA relationship is exercised from hosts that should not use the inherited service account.
+  - Focus: derive dMSA and superseded account names from `winlog.event_data.ObjectDN` and `winlog.event_data.AttributeValue`, then review authentication by `winlog.event_data.TargetUserName`, `source.ip`, and `winlog.logon.type`.
+  - Hint: missing authentication telemetry is unresolved, not benign; an unused link still needs disposition from link target, writer, and sequence.
+  - Implication: escalate when either account authenticates from a new host, admin workstation, or service path after the change; unchanged or absent use does not clear suspicion.
+- If still suspicious or unresolved, do recent writer or dMSA alerts show broader abuse?
+  - Focus: review recent alerts for modifying `user.id`, then modified `winlog.event_data.ObjectGUID`. !{investigate{"description":"","label":"Alerts associated with the source account","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}],[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: use object alerts for shadow credentials, delegation abuse, unusual service changes, or other AD tampering tied to the dMSA. !{investigate{"description":"","label":"Alerts associated with the modified dMSA object","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate and widen scope when either alert set shows privilege abuse, directory tampering, or suspicious authentication; keep scope local when both are quiet and local evidence is the only unresolved signal.
+- What disposition fits?
+  - Weigh link target, operation, writer/session, follow-on use, and related alerts: escalate on high-value link, incoherent operation, unexpected writer/session, new use, or AD abuse; close only when all evidence proves one exact migration; mixed/incomplete evidence -> preserve directory-change and session records, then escalate.
 
 
 *False positive analysis*
 
 
-- Migration of legacy service accounts using delegated managed service account.
+- Planned dMSA migration by identity/service-account admins may set "msDS-ManagedAccountPrecededByLink". Confirm `winlog.event_data.ObjectDN`, planned `winlog.event_data.AttributeValue`, paired `winlog.event_data.OpCorrelationID`, `winlog.event_data.SubjectUserSid`, recovered `source.ip`, and `winlog.logon.type` match migration account/host path. Telemetry-only closure requires anchors proving one bounded migration; otherwise require records, tickets, or identity-admin confirmation for the exact dMSA pair and writer. Do not close from recurrence or role assumptions.
+- Lab validation or staged service-account modernization may trigger. Confirm `winlog.event_data.ObjectDN` and `winlog.event_data.AttributeValue` stay in the authorized test/staging OU, session avoids unrelated privileged objects, and follow-on `winlog.event_data.TargetUserName` or `source.ip` is limited to test hosts. Telemetry-only closure requires test OU, writer, bounded change set, and follow-on hosts proving lab scope; otherwise require test records or lab owner confirmation.
+- Before exception, confirm the exact workflow: `winlog.event_data.SubjectUserSid`, `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeValue`, bounded `winlog.event_data.OpCorrelationID`, and recovered controller or source path. Use exceptions only when that verified workflow should repeat; avoid exceptions on the attribute, 5136, or all dMSA changes.
 
 
 *Response and remediation*
 
 
-- Immediately disable the winlog.event_data.SubjectUserName account and revert all changes performed by that account.
-- Identify and isolate the source machines from where the SubjectUserName is authenticating.
-- Reset passwords for all accounts that were potentially affected or had their permissions altered, focusing on privileged accounts to prevent adversaries from regaining access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach, including identifying any other compromised systems or accounts.
-- Review and update access control policies and security configurations to prevent similar attacks, ensuring that only authorized personnel have the ability to modify critical Active Directory objects or create OU child objects.
+- If confirmed benign, reverse containment and record: writer SID, dMSA DN, superseded account DN, bounded sequence, recovered source path, and external confirmation for the change. Create an exception only when that workflow should repeat.
+- If suspicious but unconfirmed, export the triggering 5136 record, same-operation change sequence, writer-session auth records, explicit-credential evidence, and related alerts before destructive changes. Apply reversible containment first: restrict the recovered source host from domain controllers or monitor the writer, modified dMSA, and superseded account. Disable the writer or isolate the source host only if additional privileged changes, unexpected follow-on authentication, or related alerts appear.
+- If confirmed malicious, preserve directory-change and session evidence first, then use endpoint response to isolate the recovered source host and disable/reset the malicious dMSA, compromised writer, and affected superseded service account. If endpoint response is unavailable on the source system, escalate with preserved `source.ip`, `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectLogonId`, `winlog.event_data.ObjectGUID`, and related 5136, 4624, or 4648 evidence to responders. Review hosts/services that used the same superseded account or new dMSA before cleanup, verify rollback replication across domain controllers, and only then remove the unauthorized `winlog.event_data.AttributeValue` link, roll back related migration/SPN/delegation changes in the same `winlog.event_data.OpCorrelationID` sequence, and rotate affected secrets or restore service bindings.
+- Post-incident hardening: restrict dMSA creation/migration rights, verify domain-controller retention for 5136, 4624, and 4648, and record the migration workflow or BadSuccessor evidence for reuse.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Audit Directory Service Changes must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-directory-service-changes
+
 
 ==== Rule query
 
diff --git a/docs/detections/prebuilt-rules/rule-details/dmsa-account-creation-by-an-unusual-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/dmsa-account-creation-by-an-unusual-user.asciidoc
index b37b1fc65f..c8f21b16fd 100644
--- a/docs/detections/prebuilt-rules/rule-details/dmsa-account-creation-by-an-unusual-user.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/dmsa-account-creation-by-an-unusual-user.asciidoc
@@ -1,7 +1,7 @@
 [[dmsa-account-creation-by-an-unusual-user]]
 === dMSA Account Creation by an Unusual User
 
-Detects the creation of a delegated Managed Service Account by an unusual subject account. Attackers can abuse the dMSA account migration feature to elevate privileges abusing weak persmission allowing users child objects rights or msDS-DelegatedManagedServiceAccount rights.
+Detects creation of a delegated Managed Service Account by an unusual subject account. Attackers can abuse weak child-object or msDS-DelegatedManagedServiceAccount rights during account migration to elevate privileges.
 
 *Rule type*: new_terms
 
@@ -36,7 +36,7 @@ Detects the creation of a delegated Managed Service Account by an unusual subjec
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 4
+*Version*: 5
 
 *Rule authors*: 
 
@@ -59,26 +59,61 @@ Detects the creation of a delegated Managed Service Account by an unusual subjec
 
 *Possible investigation steps*
 
-- Examine the winlog.event_data.SubjectUserName field and verify if he is allowed and used to create dMSA accounts.
-- Examine all Active Directory modifications performed by the winlog.event_data.SubjectUserName.
-- Investigate the history of the identified user account to determine if there are any other suspicious activities or patterns of behavior.
-- Collaborate with the IT or security team to determine if the changes were authorized or if further action is needed to secure the environment.
+
+- What dMSA object did the alert show, and where was it created?
+  - Focus: use `winlog.event_data.ObjectClass`, `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.SubjectUserName`, and `winlog.computer_name` to identify the new msDS-DelegatedManagedServiceAccount, new-to-this-rule writer, and controller.
+  - Implication: escalate when the object is in a privileged service, sync, backup, DC, or identity-infrastructure path, or when name or writer lacks a narrow service-account purpose; lower only when DN, writer, and controller match one exact planned dMSA rollout or lab path.
+- Did the same dMSA receive migration or privilege-enabling attributes?
+  - Why: BadSuccessor-style abuse elevates creation with `5136` changes such as msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState, SPNs, delegation attributes, or gMSA membership.
+  - Focus: review same-object `5136` and `5137` records on this controller with `winlog.event_data.ObjectGUID`, comparing `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.AttributeValue`, and `winlog.event_data.ObjectDN`. !{investigate{"description":"","label":"Directory changes for the same dMSA object on this controller","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5137","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if same-controller results have gaps, repeat the `winlog.event_data.ObjectGUID` search across DC Windows Security logs before treating missing follow-on changes as lower risk.
+  - Implication: escalate when values link the dMSA to a privileged predecessor, advance migration state, or add SPN/delegation material; lower suspicion only when attributes form one bounded migration to the intended legacy service account.
+- Who created the dMSA, and what session reached the domain controller?
+  - Focus: identify writer and session with `winlog.event_data.SubjectUserSid` and `winlog.event_data.SubjectLogonId`, then recover `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Authentication events for the writer session on this controller","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: this pivot uses `winlog.event_data.TargetLogonId` for `4624` or `4634`; search `4648` separately with `winlog.event_data.SubjectLogonId` when explicit-credential use matters. Missing authentication telemetry is unresolved, not benign.
+  - Implication: escalate for an unexpected human, helpdesk account, low-privilege service identity, unusual source, interactive/RDP session, or explicit-credential path; lower suspicion only when actor and source match the narrow identity-management path for this object.
+- Did the same session touch other directory objects?
+  - Focus: compare surrounding `5137` and `5136` records on the same `host.id` for `winlog.event_data.SubjectLogonId`, reading `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectClass`, and `winlog.event_data.AttributeLDAPDisplayName`.
+  - Implication: escalate when the session creates multiple dMSAs, edits ACLs, changes delegation, or touches unrelated privileged users, computers, groups, or service accounts; lower when every change stays tied to one bounded dMSA rollout.
+- Did the new dMSA get used from systems that should not touch it?
+  - Focus: derive the dMSA from the CN in `winlog.event_data.ObjectDN`, confirm it in `winlog.event_data.TargetUserName`, then review `4624` records for `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`; search `4648` separately for explicit credential use.
+  - Hint: absent dMSA authentication is a timing or visibility gap, not proof creation is harmless.
+  - Implication: escalate when the dMSA authenticates from unexpected servers, workstations, jump hosts, or non-service logon types; lower suspicion only when use stays inside the exact service host set for the confirmed rollout.
+- If local evidence is suspicious or incomplete, do related Windows Security events show broader AD abuse?
+  - Focus: review events for writer `user.id`, then compare records referencing the new `winlog.event_data.ObjectGUID`. !{investigate{"description":"","label":"Windows Security events associated with the modifying account","providers":[[{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}],[{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: use the object-event view for shadow credentials, delegation abuse, unusual service changes, or other AD tampering tied to the same dMSA. !{investigate{"description":"","label":"Windows Security events associated with the new dMSA object","providers":[[{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate and expand scope when either entity is tied to privilege abuse, directory tampering, or suspicious authentication; keep scope to this object when related events are quiet, but do not close solely because no other event exists.
+- Escalate for sensitive placement, privileged migration links, unexpected writer/session context, broader directory edits, unexpected dMSA authentication, or related AD-abuse events; close only when telemetry and outside confirmation prove one exact planned migration or lab activity; if mixed or incomplete, preserve directory-change and session evidence and escalate.
 
 
 *False positive analysis*
 
 
-- Migration of legacy service accounts using delegated managed service account.
+- Planned dMSA rollout or service-account migration can legitimately create msDS-DelegatedManagedServiceAccount objects. Confirm expected `winlog.event_data.ObjectDN`, same-object `5136` attributes limited to the intended legacy service account, and `winlog.event_data.SubjectUserSid`, recovered `source.ip`, and `winlog.logon.type` matching the narrow migration account and host path. If change records, migration tickets, or owner confirmation are unavailable, leave unresolved unless telemetry proves the exact authorized workflow.
+- Lab validation or staged service-account modernization can also trigger this rule. Confirm `winlog.event_data.ObjectDN` stays in the test/staging OU, the same `winlog.event_data.SubjectLogonId` avoids unrelated privileged objects, and any `winlog.event_data.TargetUserName`, `source.ip`, or `winlog.logon.type` activity stays limited to designated test systems. If test scope lacks outside confirmation, treat the alert as unresolved.
+- Before creating an exception, validate exact writer `winlog.event_data.SubjectUserSid`, dMSA path pattern, bounded same-object `5136` attributes, controller path, and recovered source. Use a temporary or tightly scoped exception for one-time migrations, and avoid exceptions on event `5137`, all msDS-DelegatedManagedServiceAccount objects, or all dMSA creation activity.
 
 
 *Response and remediation*
 
 
-- Immediately disable the winlog.event_data.SubjectUserName account and revert all changes performed by that account.
-- Identify and isolate the source machines from where the SubjectUserName is authenticating.
-- Reset passwords for all accounts that were potentially affected or had their permissions altered, focusing on privileged accounts to prevent adversaries from regaining access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach, including identifying any other compromised systems or accounts.
-- Review and update access control policies and security configurations to prevent similar attacks, ensuring that only authorized personnel have the ability to modify critical Active Directory objects or create OU child objects.
+- If confirmed benign, reverse any temporary containment and document the evidence that proved the authorized workflow: `winlog.event_data.SubjectUserSid`, `winlog.event_data.ObjectDN`, same-object `5136` sequence, recovered `source.ip`, `winlog.logon.type`, and exact rollout or lab scope.
+- If suspicious but unconfirmed, preserve a case export with the triggering `5137`, related same-object `5136` records, recovered `4624` or `4648` records, and key object/session identifiers before containment. Apply reversible containment first, such as temporary DC access restrictions for the recovered source or heightened monitoring on the writer and dMSA. Disable the writer or isolate the source host only if privileged follow-on changes, unexpected authentication, or related events appear.
+- If confirmed malicious, preserve the same directory-change and session evidence first, then remove the unauthorized dMSA and roll back related msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState, SPN, delegation, or membership changes found in the same-object sequence. Isolate the recovered source host when endpoint response is available and host criticality permits, then disable or reset the compromised writer and any linked service accounts.
+- Before deleting objects or closing the case, review hosts and services that used the new dMSA, verify rollback replication across domain controllers, then rotate affected secrets or restore service bindings.
+- Post-incident hardening: restrict who can create dMSAs or start service-account migration, review CreateChild and delegated managed service account rights on service-account OUs, retain `5136`, `5137`, `4624`, and `4648` coverage on domain controllers, and record the confirmed workflow or BadSuccessor evidence pattern for future triage.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Audit Directory Service Changes must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-directory-service-changes
+
 
 ==== Rule query
 
diff --git a/docs/detections/prebuilt-rules/rule-details/dns-request-for-ip-lookup-service-via-unsigned-binary.asciidoc b/docs/detections/prebuilt-rules/rule-details/dns-request-for-ip-lookup-service-via-unsigned-binary.asciidoc
index 29e888f70f..98ae8b114c 100644
--- a/docs/detections/prebuilt-rules/rule-details/dns-request-for-ip-lookup-service-via-unsigned-binary.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/dns-request-for-ip-lookup-service-via-unsigned-binary.asciidoc
@@ -30,7 +30,7 @@ Detects when a DNS request is made for an IP lookup service to determine the ext
 * Data Source: Elastic Defend
 * Resources: Investigation Guide
 
-*Version*: 1
+*Version*: 2
 
 *Rule authors*: 
 
@@ -87,7 +87,7 @@ This detects an unsigned or untrusted process on macOS performing DNS lookups fo
 
 [source, js]
 ----------------------------------
-dns where host.os.type == "macos" and event.action == "lookup_result" and 
+network where host.os.type == "macos" and event.action == "lookup_result" and 
   (process.code_signature.trusted == false or process.code_signature.exists == false) and
   dns.question.name like~ ("*ip-api.com*", "*ipwho.is*", "*checkip.dyndns.org*", "*api.ipify.org*",
                            "*api.npoint.io*", "*whatismyip.akamai.com*", "*bot.whatismyipaddress.com*",
diff --git a/docs/detections/prebuilt-rules/rule-details/eks-authentication-configuration-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/eks-authentication-configuration-modified.asciidoc
new file mode 100644
index 0000000000..79d625139b
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/eks-authentication-configuration-modified.asciidoc
@@ -0,0 +1,120 @@
+[[eks-authentication-configuration-modified]]
+=== EKS Authentication Configuration Modified
+
+Detects modifications to the aws-auth ConfigMap in Amazon EKS clusters. The aws-auth ConfigMap maps AWS IAM roles and users to Kubernetes RBAC groups, an attacker who modifies it can grant any IAM role cluster-admin access by adding a mapping to the system:masters group. This is a well-documented persistence technique that survives pod restarts, node replacements, and RBAC changes because the authentication mapping exists outside of normal Kubernetes Role objects. Modifications to aws-auth are rare in normal operations, the ConfigMap is typically set during cluster provisioning and updated only during node group or access configuration changes.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.aws.amazon.com/eks/latest/userguide/auth-configmap.html
+* https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Privilege Escalation
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating EKS Authentication Configuration Modified*
+
+
+Confirm who changed the mapping (user.name, groups, source.ip, user_agent.original) and whether the change aligns with
+approved cluster or node-group operations. Compare the new aws-auth mapRoles/mapUsers content to the prior revision if
+request/response capture is available in audit.
+
+
+*Possible investigation steps*
+
+
+- Identify any new IAM role ARNs or users bound to system:masters or other privileged Kubernetes groups.
+- Correlate the timestamp with AWS CloudTrail for related EKS or IAM API activity and with GitOps or pipeline commits.
+- Review subsequent API activity from newly mapped IAM principals for secret access, RBAC changes, or workload deployment.
+- If Access Entries are enabled, also review CloudTrail for eks:CreateAccessEntry, eks:AssociateAccessPolicy, and similar
+  API calls around the same window.
+
+
+*Response and remediation*
+
+
+- If unauthorized, revert aws-auth from a known-good backup, remove rogue map entries, and rotate or restrict IAM that
+  could have performed the change.
+- Audit IAM policies that allow eks:UpdateClusterConfig or broad ConfigMap write access to kube-system.
+- Escalate per incident policy when system:masters mappings appear from unexpected IAM identities.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"kubernetes.audit_logs" and 
+kubernetes.audit.objectRef.resource:"configmaps" and 
+kubernetes.audit.objectRef.name:"aws-auth" and 
+kubernetes.audit.verb:("update" or "patch" or "delete") and 
+kubernetes.audit.objectRef.namespace:"kube-system" and 
+kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and
+not user.name:"eks:kms-storage-migrator"
+
+----------------------------------
+
+*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 Container Cluster Roles
+** ID: T1098.006
+** Reference URL: https://attack.mitre.org/techniques/T1098/006/
+* 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/
diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc
new file mode 100644
index 0000000000..b9db24eaef
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc
@@ -0,0 +1,133 @@
+[[entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource]]
+=== Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource
+
+Detects successful Microsoft Entra ID sign-ins where the client application is the Microsoft Authentication Broker (MAB) and the requested resource identifier is outside a short list of commonly observed first-party targets. Attackers abuse the broker in phishing and token broker flows to obtain tokens for unexpected APIs or enterprise applications. The exclusion list covers legacy Azure Active Directory, Microsoft Graph, Device Registration Service, Microsoft Intune Enrollment, extend or tune exclusions for your tenant after baselining broker traffic.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-azure.signinlogs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://learn.microsoft.com/en-us/troubleshoot/azure/entra/entra-id/governance/verify-first-party-apps-sign-in
+* https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs
+* https://any.run/malware-trends/tycoon/
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Sign-in Logs
+* Use Case: Threat Detection
+* Tactic: Initial Access
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource*
+
+
+Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.resource_id`,
+`azure.signinlogs.properties.resource_display_name`, `azure.signinlogs.properties.session_id`, `source.ip`, and
+`user_agent.original`.
+
+Determine whether the resource is a known line-of-business application, partner integration, or Microsoft service not
+represented in the rule exclusion list.
+
+
+*Possible investigation steps*
+
+
+- Resolve `resource_id` in Entra ID enterprise applications and compare with change records or app governance inventory.
+- Correlate with `azure.signinlogs` and `azure.graphactivitylogs` for follow-on API calls from the same session.
+- Review conditional access results and risk detections for the same user and time window.
+
+
+*Response and remediation*
+
+
+- If unauthorized, revoke refresh tokens for the user, review consent and app permissions, and reset credentials per policy.
+- Escalate per incident procedures when the resource corresponds to sensitive APIs or high-privilege applications.
+
+
+==== Setup
+
+
+Microsoft Entra ID sign-in logs (`logs-azure.signinlogs-*`) must include `azure.signinlogs.properties.app_id` and
+`azure.signinlogs.properties.resource_id`. Tune the exclusion list for first-party resource identifiers your tenant
+expects from the Microsoft Authentication Broker.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"azure.signinlogs" and event.category:"authentication" and event.action:"Sign-in activity" and
+event.outcome:success and azure.signinlogs.properties.app_id:"29d9ed98-a469-4536-ade2-f981bc1d605e" and
+azure.signinlogs.properties.resource_id:(* and not 
+    ("00000002-0000-0000-c000-000000000000" or
+    "90a2e5d2-fd7a-4a2e-bc90-3dc50ae8e3ee" or
+    "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9" or
+    "d4ebce55-015a-49b5-a083-c84d1797ae8c" or
+    "00000003-0000-0000-c000-000000000000" or 
+    "0a5f63c0-b750-4f38-a71c-4fc0d58b89e2")
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* Sub-technique:
+** Name: Cloud Accounts
+** ID: T1078.004
+** Reference URL: https://attack.mitre.org/techniques/T1078/004/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Use Alternate Authentication Material
+** ID: T1550
+** Reference URL: https://attack.mitre.org/techniques/T1550/
+* Sub-technique:
+** Name: Application Access Token
+** ID: T1550.001
+** Reference URL: https://attack.mitre.org/techniques/T1550/001/
diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-oauth-device-code-phishing-via-aitm.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-oauth-device-code-phishing-via-aitm.asciidoc
new file mode 100644
index 0000000000..58a0b8aa0a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/entra-id-oauth-device-code-phishing-via-aitm.asciidoc
@@ -0,0 +1,133 @@
+[[entra-id-oauth-device-code-phishing-via-aitm]]
+=== Entra ID OAuth Device Code Phishing via AiTM
+
+Detects successful Microsoft Entra ID sign-ins that use the OAuth device code authentication protocol with the Microsoft Authentication Broker client requesting first-party Office API resources (Exchange Online, Microsoft Graph, or SharePoint) while flagged as interactive. This pattern is associated with adversary-in-the-middle (AiTM) phishing kits such as Tycoon 2FA, where victims complete device code flows that ultimately broker tokens for mail and collaboration APIs.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-azure.signinlogs-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://any.run/malware-trends/tycoon/
+* https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows
+* https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Sign-in Logs
+* Use Case: Threat Detection
+* Threat: Tycoon2FA
+* Tactic: Initial Access
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Entra ID OAuth Device Code Phishing via AiTM*
+
+
+Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.session_id`, `source.ip`,
+`user_agent.original`, and `azure.signinlogs.properties.resource_display_name` for context around the device code
+completion.
+
+Confirm whether the user knowingly entered a device code (for example on a shared or headless device) and whether
+broker-mediated access to Exchange, Graph, or Yammer is expected for that account.
+
+
+*Possible investigation steps*
+
+
+- Interview the user about recent links, QR codes, or prompts to approve a device code.
+- Correlate with `azure.signinlogs` and Microsoft 365 audit logs for mailbox, Teams, or file access from the same
+  session or IP shortly after the event.
+- Review conditional access and MFA satisfaction details for the same `session_id`.
+
+
+*Response and remediation*
+
+
+- If malicious, revoke refresh tokens for the user, reset credentials per policy, and review application consent.
+- Block or monitor the source IP and escalate per incident procedures.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"azure.signinlogs" and event.category:"authentication" and event.action:"Sign-in activity" and
+event.outcome:success and azure.signinlogs.properties.app_id:"29d9ed98-a469-4536-ade2-f981bc1d605e" and
+azure.signinlogs.properties.authentication_protocol:deviceCode and
+azure.signinlogs.properties.resource_id:(
+    "00000002-0000-0ff1-ce00-000000000000" or
+    "00000003-0000-0ff1-ce00-000000000000" or
+    "00000005-0000-0ff1-ce00-000000000000"
+) and azure.signinlogs.properties.is_interactive:true
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Phishing
+** ID: T1566
+** Reference URL: https://attack.mitre.org/techniques/T1566/
+* Sub-technique:
+** Name: Spearphishing Link
+** ID: T1566.002
+** Reference URL: https://attack.mitre.org/techniques/T1566/002/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* Sub-technique:
+** Name: Cloud Accounts
+** ID: T1078.004
+** Reference URL: https://attack.mitre.org/techniques/T1078/004/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Use Alternate Authentication Material
+** ID: T1550
+** Reference URL: https://attack.mitre.org/techniques/T1550/
+* Sub-technique:
+** Name: Application Access Token
+** ID: T1550.001
+** Reference URL: https://attack.mitre.org/techniques/T1550/001/
diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa.asciidoc
new file mode 100644
index 0000000000..9c40512bee
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa.asciidoc
@@ -0,0 +1,121 @@
+[[entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa]]
+=== Entra ID Potential AiTM Sign-In via OfficeHome (Tycoon2FA)
+
+Detects Microsoft Entra ID sign-ins consistent with Tycoon2FA phishing-as-a-service (PhaaS) adversary-in-the-middle (AiTM) activity: the Microsoft Authentication Broker requesting tokens for Microsoft Graph or Exchange Online, or the Office web client application authenticating to itself, combined with Node.js-style user agents (node, axios, undici). Tycoon 2FA bypasses MFA by relaying authentication and capturing session material, often targeting Microsoft 365 and Gmail. Baseline legitimate automation and developer tooling before tuning.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-azure.signinlogs-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://any.run/malware-trends/tycoon/
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Sign-in Logs
+* Use Case: Threat Detection
+* Threat: Tycoon2FA
+* Tactic: Initial Access
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Entra ID Potential AiTM Sign-In via OfficeHome (Tycoon2FA)*
+
+
+Review user.name, azure.signinlogs.properties.user_principal_name, azure.signinlogs.properties.app_id,
+azure.signinlogs.properties.resource_id, user_agent.original, source.ip, source.geo fields, and
+azure.signinlogs.properties.session_id.
+
+Confirm whether the user intentionally signed in and whether Node.js-style user agents (node, axios, undici) are
+expected for Microsoft Authentication Broker or Office web client flows in your environment.
+
+
+*Possible investigation steps*
+
+
+- Correlate the session with Microsoft Graph activity logs and mailbox audit for follow-on data access.
+- Review conditional access outcomes and MFA detail for the same session.
+- Hunt for other sign-ins from the same source IP with unusual user agents or rapid OAuth patterns.
+
+
+*Response and remediation*
+
+
+- If malicious, revoke refresh tokens for the user, reset credentials per policy, and review application consent.
+- Block or monitor the source IP and escalate per incident procedures.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"azure.signinlogs" and event.category:"authentication" and
+event.action:"Sign-in activity" and
+(
+    (
+        azure.signinlogs.properties.app_id:"29d9ed98-a469-4536-ade2-f981bc1d605e" and
+        azure.signinlogs.properties.resource_id:(
+            "00000002-0000-0ff1-ce00-000000000000" or "00000003-0000-0000-c000-000000000000"
+        )
+    ) or
+    (
+        azure.signinlogs.properties.app_id:"4765445b-32c6-49b0-83e6-1d93765276ca" and
+        azure.signinlogs.properties.resource_id:"4765445b-32c6-49b0-83e6-1d93765276ca"
+    )
+) and user_agent.original:(node or axios* or undici)
+
+----------------------------------
+
+*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/
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Steal Web Session Cookie
+** ID: T1539
+** Reference URL: https://attack.mitre.org/techniques/T1539/
diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-register-device-with-unusual-user-agent-azure-ad-join.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-register-device-with-unusual-user-agent-azure-ad-join.asciidoc
new file mode 100644
index 0000000000..ebbeb9f630
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/entra-id-register-device-with-unusual-user-agent-azure-ad-join.asciidoc
@@ -0,0 +1,106 @@
+[[entra-id-register-device-with-unusual-user-agent-azure-ad-join]]
+=== Entra ID Register Device with Unusual User Agent (Azure AD Join)
+
+Detects successful Microsoft Entra ID audit events for Register device where additional details indicate an Azure AD join and the recorded user agent is not one of the common native registration clients (Dsreg, DeviceRegistrationClient, or Dalvik-based Android enrollment). Legitimate Windows and standard mobile enrollment flows often present predictable user-agent strings; unexpected clients may reflect scripted registration, third-party tooling, or adversary-driven device registration used for persistence or token abuse. Baseline approved provisioning tools and MDM integrations before tuning.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-azure.auditlogs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://learn.microsoft.com/en-us/entra/identity/devices/concept-directory-join
+* https://github.com/dirkjanm/ROADtools
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Audit Logs
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Entra ID Register Device with Unusual User Agent (Azure AD Join)*
+
+
+Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName`, source IP fields on the audit event,
+`azure.auditlogs.properties.target_resources.0.display_name` for the device name, and
+`azure.correlation_id` for related audit entries.
+
+Compare `azure.auditlogs.properties.userAgent` to your organization's standard Autopilot, Intune, and Windows enrollment
+clients.
+
+
+*Possible investigation steps*
+
+
+- Confirm whether the user intentionally joined a device and whether the user agent matches a known provisioning package.
+- Pivot to `azure.signinlogs` for the same principal and timeframe for risky sign-ins or token broker activity.
+- Search for other `Register device` events from the same IP or user agent across the tenant.
+
+
+*Response and remediation*
+
+
+- If malicious, remove the device in Entra ID, revoke refresh and primary refresh tokens for the user, and reset credentials per policy.
+- Tighten device registration and join controls via Conditional Access and device compliance policies.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"azure.auditlogs" and event.action:"Register device" and
+event.outcome:(success or Success) and
+azure.auditlogs.properties.userAgent:(* and not (Dsreg* or DeviceRegistrationClient or Dalvik*)) and
+azure.auditlogs.properties.additional_details.value:"Azure AD join"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Sub-technique:
+** Name: Device Registration
+** ID: T1098.005
+** Reference URL: https://attack.mitre.org/techniques/T1098/005/
diff --git a/docs/detections/prebuilt-rules/rule-details/execution-of-file-written-or-modified-by-microsoft-office.asciidoc b/docs/detections/prebuilt-rules/rule-details/execution-of-file-written-or-modified-by-microsoft-office.asciidoc
index 695d0ba79d..b25441ff9b 100644
--- a/docs/detections/prebuilt-rules/rule-details/execution-of-file-written-or-modified-by-microsoft-office.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/execution-of-file-written-or-modified-by-microsoft-office.asciidoc
@@ -33,7 +33,7 @@ Identifies an executable created by a Microsoft Office application and subsequen
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
 
-*Version*: 114
+*Version*: 115
 
 *Rule authors*: 
 
@@ -53,54 +53,72 @@ Identifies an executable created by a Microsoft Office application and subsequen
 *Investigating Execution of File Written or Modified by Microsoft Office*
 
 
-Microsoft Office, a widely used suite of productivity applications, is frequently targeted by attackers due to its popularity in corporate environments. Attackers exploit its extensive capabilities, like macro scripts in Word and Excel, to gain initial access to systems. They often use Office documents as delivery mechanisms for malware or phishing attempts, taking advantage of their trusted status in professional settings.
 
-This rule searches for executable files written by MS Office applications executed in sequence. This is most likely the result of the execution of malicious documents or exploitation for initial access or privilege escalation. This rule can also detect suspicious processes masquerading as the MS Office applications.
+*Possible investigation steps*
 
 
-*Possible investigation steps*
+- Which source events matched the Office write-to-execute sequence?
+  - Why: this sequence can merge fields from different file and process events, so source events are the evidence for writer and executed-process identity.
+  - Focus: open Investigate in Timeline for the alert window on the same host; compare written `file.path` with executed `process.executable`, then record source `process.name`, `process.entity_id`, and stable `user.id`.
+  - Implication: escalate when Office creates an executable that later starts from the same path; lower suspicion when the recovered sequence resolves to a recognized signed add-in or helper updater in a controlled product tree. Signed Microsoft NewOutlookInstaller.exe and Citrix ShareFileForOutlook helpers are excluded, so a generic updater label is not closure.
+
+- Is the Office writer the expected Office component and parent context?
+  - Focus: writer `process.executable`, signer/trust, `process.parent.executable`, and `process.parent.command_line`.
+  - Implication: escalate when WINWORD.EXE, EXCEL.EXE, OUTLOOK.EXE, POWERPNT.EXE, MSPUB.EXE, MSACCESS.EXE, eqnedt32.exe, or fltldr.exe is renamed, untrusted, user-writable, or launched by an unusual parent; lower suspicion when writer path, signer, and parent chain match the user's recognized Office integration. Writer identity never clears the executed file by itself.
+
+- Does the written executable look staged for payload delivery?
+  - Focus: `file.path`, original path/extension, `file.Ext.header_bytes`, `file.Ext.windows.zone_identifier`, and same-host file activity on the written path. !{investigate{"description":"","label":"File events for the written executable path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-2h","relativeTo":"now"}}
+  - Implication: escalate for Temp, Downloads, AppData, mail cache, startup, unrelated product paths, Internet Zone evidence, or executable content after rename; lower suspicion when the artifact stays in a recognized add-in or update tree and path history fits that workflow.
 
+- Does the executed file's identity and command line fit the same workflow?
+  - Focus: executed `process.executable`, `process.hash.sha256`, signer, `process.command_line`, and `process.Ext.relative_file_creation_time`.
+  - Hint: use prior endpoint process starts or related alerts for `process.hash.sha256` only after identity and command line fit the suspected workflow. !{investigate{"description":"","label":"Alerts associated with the executed file hash","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate when the executable is newly created, unsigned, user-writable, mismatched to signer or path, or launched with script, LOLBin, unpacking, or self-extracting arguments; lower suspicion only when signer, hash history, path, age, and arguments all fit the same recognized helper workflow.
 
-- 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.
-- Retrieve MS Office documents received and opened by the user that could cause this behavior. Common locations include, but are not limited to, the Downloads and Document folders and the folder configured at the email client.
-- Determine if the collected files are malicious:
-  - Use a private sandboxed malware analysis system to perform analysis.
-    - Observe and collect information about the following activities:
-      - Attempts to contact external domains and addresses.
-      - 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.
+- What document, email, archive, or integration source caused Office to write the executable?
+  - Focus: file events from writer `process.entity_id`; review `file.path`, `file.origin_url`, `file.origin_referrer_url`, and `file.Ext.windows.zone_identifier`.
+  - Hint: if records are incomplete or the entity pivot returns none, use the same host, writer `process.pid`, and tight write-time window.
+  - Implication: escalate when the write follows a downloaded document, email attachment, archive extraction, or web referrer outside the same recognized workflow; lower suspicion when provenance points to a recognized deployment package or Office integration source. Missing provenance is inconclusive, not benign.
+
+- Did the executed file produce malicious follow-on process or file activity?
+  - Focus: process and file events scoped to executed `process.entity_id`: child `process.parent.entity_id`, child `process.command_line`, and new `file.path` values.
+  - Hint: if records are incomplete or the entity pivot returns none, use the same host, executed `process.pid`, and post-start window.
+  - Implication: escalate when the payload launches script interpreters, LOLBins, unpackers, or additional binaries, or stages files outside the recognized product tree; lower urgency when follow-on activity stays limited to expected local install or update actions. Preserve Office-written DLLs, scripts, or shortcut launchers in the same scope as adjacent payload variants.
+
+- If local findings remain suspicious or unresolved, do related alerts show the same delivery chain or spread?
+  - Focus: related alerts for `host.id`, then pivot on recovered stable `user.id`; prioritize document delivery, script execution, persistence, and outbound connection alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when related alerts connect the same host or user to delivery, scripting, persistence, or beaconing; keep scope local when the sequence is isolated and local evidence supports one recognized workflow.
+
+- Escalate when sequence, artifact, identity, delivery, behavior, or related-alert evidence supports suspicious Office write-to-execute activity; close only when all categories align with one recognized add-in, updater, or integration workflow and no contradictory artifacts remain; if evidence is mixed or incomplete, preserve artifacts and escalate.
 
 
 *False positive analysis*
 
 
-- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+- Office add-in, repair, updater, document-management, e-signature, DLP, or collaboration integrations can write and launch helper executables. Confirm that writer identity, written path, executed hash or signer, parent context, provenance, command line, and follow-on activity all point to the same product or integration workflow. If records are unavailable, require telemetry-only recurrence of the same writer, path tree, signer/hash pattern, and `host.id` or `user.id` cohort across prior alerts.
+- Before creating an exception, validate that the same Office writer, path tree, executed signer or `process.hash.sha256`, provenance pattern, and `host.id`/`user.id` cohort recur across prior alerts from this rule. Build the exception from that minimum workflow pattern; avoid exceptions on Office process names, `process.name`, or `file.extension` alone.
 
 
 *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.
-- 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 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.
-  - If the malicious file was delivered via phishing:
-    - Block the email sender from sending future emails.
-    - Block the malicious web pages.
-    - Remove emails from the sender from mailboxes.
-    - Consider improvements to the security awareness program.
-- 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).
+- If confirmed benign, reverse temporary containment and document the writer identity, written path tree, executed hash and signer, parent/delivery context, and recurrence evidence. Create an exception only for the same stable workflow pattern.
+- If suspicious but unconfirmed, preserve Timeline source events, copies of the written executable and source document/archive, process tree details, recovered entity IDs, command line, hash, path, and provenance URLs before containment. Apply reversible containment first: quarantine the lure or executable, block the confirmed hash/path temporarily where controls support it, or increase monitoring on the affected `host.id` and `user.id`. Isolate the host only if follow-on process/file evidence shows malicious staging or execution and the host can tolerate interruption.
+- If confirmed malicious, isolate the host and terminate the executed payload after preserving the source events, process tree, written executable, lure document or archive, hash, signer, and provenance evidence. Block the confirmed hash or path where controls support it, then remove the malicious executable, lure, archive, and staged files identified during the investigation.
+- Review related hosts and users for the same written path pattern, executed hash, signer, and provenance evidence before deleting artifacts. Then remediate the delivery path, such as the phishing message, archive, or malicious Office document, that led to the write-execute sequence.
+- Post-incident hardening: restrict Office-driven writes and launches of executable content in user-writable paths, retain endpoint file-provenance and process-start telemetry, and record confirmed adjacent variants, such as Office-written DLLs, scripts, or shortcut launchers, in the case history 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
 
 
 ==== Rule query
@@ -110,14 +128,10 @@ This rule searches for executable files written by MS Office applications execut
 ----------------------------------
 sequence with maxspan=2h
   [file where host.os.type == "windows" and event.type != "deletion" and file.extension : "exe" and
-     (process.name : "WINWORD.EXE" or
-      process.name : "EXCEL.EXE" or
-      process.name : "OUTLOOK.EXE" or
-      process.name : "POWERPNT.EXE" or
-      process.name : "eqnedt32.exe" or
-      process.name : "fltldr.exe" or
-      process.name : "MSPUB.EXE" or
-      process.name : "MSACCESS.EXE")
+    process.name : (
+      "WINWORD.EXE", "EXCEL.EXE", "OUTLOOK.EXE", "POWERPNT.EXE",
+      "eqnedt32.exe", "fltldr.exe", "MSPUB.EXE", "MSACCESS.EXE"
+    )
   ] by host.id, file.path
   [process where host.os.type == "windows" and event.type == "start" and 
    not (process.name : "NewOutlookInstaller.exe" and process.code_signature.subject_name : "Microsoft Corporation" and process.code_signature.trusted == true) and 
diff --git a/docs/detections/prebuilt-rules/rule-details/execution-via-tsclient-mountpoint.asciidoc b/docs/detections/prebuilt-rules/rule-details/execution-via-tsclient-mountpoint.asciidoc
index 5f6d17dab2..d83c899146 100644
--- a/docs/detections/prebuilt-rules/rule-details/execution-via-tsclient-mountpoint.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/execution-via-tsclient-mountpoint.asciidoc
@@ -29,7 +29,7 @@ Identifies execution from the Remote Desktop Protocol (RDP) shared mountpoint ts
 
 *References*: 
 
-* https://posts.specterops.io/revisiting-remote-desktop-lateral-movement-8fb905cb46c3
+* https://specterops.io/blog/2020/01/22/revisiting-remote-desktop-lateral-movement/
 * https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language
 
 *Tags*: 
@@ -47,7 +47,7 @@ Identifies execution from the Remote Desktop Protocol (RDP) shared mountpoint ts
 * Data Source: Crowdstrike
 * Resources: Investigation Guide
 
-*Version*: 319
+*Version*: 320
 
 *Rule authors*: 
 
@@ -63,47 +63,77 @@ Identifies execution from the Remote Desktop Protocol (RDP) shared mountpoint ts
 *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 Execution via TSClient Mountpoint*
 
 
-The TSClient mountpoint is a feature of the Remote Desktop Protocol (RDP) that allows users to access local drives from a remote session. Adversaries can exploit this by executing malicious files from the shared mountpoint, facilitating lateral movement within a network. The detection rule identifies such activities by monitoring for process executions originating from the TSClient path, signaling potential unauthorized access attempts.
-
 
 *Possible investigation steps*
 
 
-- Review the alert details to confirm the process execution path matches the pattern "\\Device\\Mup\\tsclient\\*.exe" and verify the host operating system is Windows.
-- Identify the user account associated with the RDP session and check for any unusual or unauthorized access patterns, such as logins from unexpected locations or at odd times.
-- Examine the executed process's hash and compare it against known malicious hashes in threat intelligence databases to determine if the file is potentially harmful.
-- Investigate the source system from which the RDP session originated to identify any signs of compromise or unauthorized access that could indicate lateral movement.
-- Check for any additional suspicious activities on the target host, such as unexpected network connections or file modifications, that may correlate with the execution event.
-- Review the security logs from data sources like Microsoft Defender XDR or Sysmon for any related alerts or anomalies that could provide further context on the incident.
+- What exact TSClient launch did the alert capture?
+  - Focus: `process.executable`, `process.command_line`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`.
+  - Implication: escalate when the redirected-drive executable is unsigned, untrusted, renamed, script-capable, or launched with command intent outside a recognized RDP support or deployment workflow; lower concern only when a vendor-signed installer or utility from the RDP client drive matches that exact session purpose.
+- What launcher and Windows session produced the TSClient process?
+  - Focus: `process.parent.name`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, `user.id`.
+  - Implication: escalate when the parent is "cmd.exe", "powershell.exe", "taskmgr.exe", or another remote-session launcher, when the session is remote-interactive for an unusual user, or when children show another TSClient-launched payload; lower concern when parent and session match a recognized support launcher or deployment tool.
+- Which RDP source created the session, when authentication telemetry is available?
+  - Focus: bridge `process.Ext.authentication_id` to same-host authentication events through `winlog.event_data.TargetLogonId`; read `source.ip`, `winlog.logon.type`, `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Authentication events for the linked session","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{process.Ext.authentication_id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate when the recovered source or authentication package conflicts with recognized jump hosts, support workstations, or deployment sources. Missing authentication telemetry is unresolved, not benign.
+- Did the TSClient process spawn shells, tools, or persistence helpers on the target?
+  - Focus: child starts from `process.entity_id` on `host.id`, especially `process.executable`, `process.command_line`, `process.parent.entity_id`. !{investigate{"description":"","label":"Child processes spawned by the TSClient launch","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `process.entity_id` is absent, recover descendants with `host.id` + `process.pid` + a tight alert-time window and confirm the parent command line before interpreting results.
+  - Implication: escalate when descendants include shells, script hosts, remote-access tools, credential utilities, or persistence helpers; an isolated installer-like launch lowers urgency only if session and identity evidence also align.
+- If local evidence remains suspicious or incomplete, do related alerts show the same user or host attempting RDP or remote execution elsewhere?
+  - Focus: same-user `user.id` and same-host `host.id` alerts sharing RDP, credential, remote-service, or execution patterns.
+  - Hint: user alert pivot. !{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: host alert pivot. !{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 only when related alerts reuse the same user, host, session pattern, or command family; unrelated alert noise does not change disposition.
+- Escalate when suspicious identity, lineage, source, descendants, or related alerts support unauthorized redirected-drive execution; close only when process identity, parent/session, source when available, and descendants all match one recognized RDP support or deployment activity; preserve artifacts and escalate when authentication visibility is missing or evidence remains mixed.
 
 
 *False positive analysis*
 
 
-- Legitimate software updates or installations may trigger the rule if they are executed from a local drive mapped through TSClient. To manage this, create exceptions for known update processes or installation paths that are frequently used in your environment.
-- IT administrative tasks performed via RDP sessions can also cause false positives. Identify and exclude specific administrative tools or scripts that are regularly executed from TSClient paths by trusted personnel.
-- Automated backup or synchronization software that accesses local drives through RDP might be flagged. Review and whitelist these processes if they are part of routine operations.
-- Development or testing activities involving remote execution of scripts or applications from TSClient can be mistaken for threats. Establish a list of approved development tools and paths to exclude from monitoring.
-- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking genuine threats.
+- RDP helpdesk, break-fix, or software deployment workflows can legitimately run installers or utilities from a client drive redirected into the target session. Confirm all evidence converges on one exact activity: identity and intent (`process.executable`, `process.command_line`, signature), launch/session (`process.parent.name`, `user.id`, `host.id`, recovered `source.ip` when available), and outcome (no suspicious descendants or related alerts). Contradictory evidence keeps the case open.
+- Use recurrence only to support a narrow exception candidate, not to close the current case by itself. Require the same stable executable path or signer, parent/session pattern, `user.id`, `host.id`, recovered source when available, and descendant-clean outcome across prior alerts from this rule; keep the case open when current telemetry is incomplete or contradictory.
+- Before creating an exception, anchor it on the minimum confirmed pattern: specific `process.executable`, stable `process.command_line` or signer, `process.parent.name`, `user.id`, `host.id`, and recovered `source.ip` only when it was part of the confirmation. Avoid exceptions on the TSClient path wildcard or `process.name` alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected host from the network to prevent further lateral movement and potential data exfiltration.
-- Terminate any suspicious processes running from the TSClient path to halt any ongoing malicious activity.
-- Conduct a thorough scan of the affected host using endpoint detection and response (EDR) tools to identify and remove any malicious files or artifacts.
-- Review and analyze RDP logs and session details to identify unauthorized access attempts and determine the source of the intrusion.
-- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access.
-- Implement network segmentation to limit RDP access to only necessary systems and users, reducing the attack surface for similar threats.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts.
+- Preserve evidence before changing state: case export of the alert, process tree, command line, binary hash or sample when available, child-process events, and authentication-bridge records.
+- If confirmed benign after preservation, reverse temporary containment and document the exact process identity, parent/session context, `user.id`, `host.id`, and recovered `source.ip` that established the redirected-drive workflow. Create an exception only after the same narrowly scoped pattern is stable across prior alerts.
+- If suspicious but unconfirmed after preservation, use reversible containment only: terminate the active RDP session, restrict new RDP connections from the recovered source when available, disable drive redirection for the affected access path, or heighten monitoring on the affected `host.id`. Do not isolate the host, terminate processes, or suspend accounts unless follow-on execution or related alerts confirm broader abuse.
+- If confirmed malicious, isolate the target host when feasible, terminate the TSClient-launched process and malicious descendants after evidence capture, and disable or suspend the account or RDP access path used for the session.
+- Scope before cleanup by reviewing other hosts and users tied to the same recovered source, `user.id`, distinctive `process.command_line`, signer, or hash.
+- Eradicate only the staged payloads, persistence artifacts, or tooling identified during the investigation, then review whether credentials exposed in the RDP session need reset or reissue.
+- Post-incident hardening: limit RDP drive redirection, restrict RDP access to managed jump hosts, retain endpoint process and Windows Security telemetry for session bridging, and document any TSClient execution patterns that should become narrow exceptions.
+
+==== 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
 
diff --git a/docs/detections/prebuilt-rules/rule-details/file-creation-in-world-writable-directory-by-unusual-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/file-creation-in-world-writable-directory-by-unusual-process.asciidoc
index 857887780a..f370c69cbc 100644
--- a/docs/detections/prebuilt-rules/rule-details/file-creation-in-world-writable-directory-by-unusual-process.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/file-creation-in-world-writable-directory-by-unusual-process.asciidoc
@@ -36,7 +36,7 @@ This rule detects the creation of files in world-writable directories by an unus
 * Data Source: SentinelOne
 * Resources: Investigation Guide
 
-*Version*: 1
+*Version*: 2
 
 *Rule authors*: 
 
@@ -129,12 +129,9 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/
 [source, js]
 ----------------------------------
 host.os.type:linux and event.category:file and event.type:creation and (
-  process.name:(
-    "cp" or "mv" or "chmod" or "chown" or "chattr" or "chgrp" or "curl" or "wget" or "timeout" or
-    "env" or "node" or "deno" or "nodejs" or .* or python* or perl* or ruby* or php* or lua*
-  ) or
+  process.name:("cp" or "mv") or
   process.executable:(
-    ./* or /tmp/* or /var/tmp/* or /dev/shm/* or /run/* or /var/run/* or /boot/* or /sys/* or
+    ./* or /tmp/* or /var/tmp/* or /dev/shm/* or /run/user/* or /var/run/user/* or /boot/* or /sys/* or
     /lost+found/* or /proc/* or /var/mail/* or /var/www/*
   )
 ) and
@@ -144,9 +141,16 @@ not (
     /var/tmp/dracut.* or /var/tmp/mkinitramfs_* or /tmp/.*-00000000.so or /run/udev/rules.d/* or
     /tmp/new_root/* or /tmp/newroot/* or /run/user/*/.bubblewrap/newroot/* or /tmp/tmp.*/docker-scout_* or
     /var/tmp/portage/* or /tmp/yarn--* or /run/k3s/containerd/* or /var/tmp/pamac-build-* or
-    /tmp/mkinitcpio* or /run/user/*/netns/netns-*
+    /tmp/mkinitcpio* or /run/user/*/netns/netns-* or /tmp/apt-key* or /tmp/tmp.*/pubring.orig.gpg or
+    /tmp/CVU_19_* or /tmp/ut-backup-files.* or /tmp/tmp.*/terraform/*
   ) or
-  file.extension:("json" or "txt")
+  file.extension:("json" or "txt") or
+  process.executable:(
+    /tmp/par-* or /tmp/snap.rootfs_* or /tmp/CVU_*/exectask or /tmp/.mount_*/usr/bin/QGroundControl or
+    ./snap/snapd/*/usr/lib/snapd/snap-update-ns or "./usr/lib/snapd/snap-update-ns" or
+    "/tmp/newroot/snap/snapd/current/usr/bin/snap" or /tmp/newroot/snap/snapd/*/usr/lib/snapd/snap-confine or
+    "./usr/bin/podman" or "/tmp/newroot/usr/lib/systemd/systemd"
+  )
 )
 
 ----------------------------------
diff --git a/docs/detections/prebuilt-rules/rule-details/finder-sync-plugin-registered-and-enabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/finder-sync-plugin-registered-and-enabled.asciidoc
index 059278bf06..1745dc9369 100644
--- a/docs/detections/prebuilt-rules/rule-details/finder-sync-plugin-registered-and-enabled.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/finder-sync-plugin-registered-and-enabled.asciidoc
@@ -32,7 +32,7 @@ Finder Sync plugins enable users to extend Finder’s functionality by modifying
 * Data Source: Elastic Defend
 * Resources: Investigation Guide
 
-*Version*: 211
+*Version*: 212
 
 *Rule authors*: 
 
@@ -134,7 +134,7 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/
 ----------------------------------
 process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "pluginkit" and
   process.args == "-e" and process.args like~ "use" and process.args == "-i" and
-  (process.name like~ ("python*", "node", "osascript", "bash", "sh", "zsh") or (process.parent.code_signature.exists == false or process.parent.code_signature.trusted == false))
+  (process.parent.name like~ ("python*", "node", "osascript", "bash", "sh", "zsh") or (process.parent.code_signature.exists == false or process.parent.code_signature.trusted == false))
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/first-time-fortigate-administrator-login.asciidoc b/docs/detections/prebuilt-rules/rule-details/first-time-fortigate-administrator-login.asciidoc
index 8a38411341..7cb5c1b814 100644
--- a/docs/detections/prebuilt-rules/rule-details/first-time-fortigate-administrator-login.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/first-time-fortigate-administrator-login.asciidoc
@@ -32,7 +32,7 @@ This rule detects the first observed successful login of a user with the Adminis
 * Data Source: Fortinet
 * Data Source: Fortinet FortiGate
 
-*Version*: 3
+*Version*: 5
 
 *Rule authors*: 
 
@@ -71,6 +71,7 @@ Because administrator access provides full control over network security devices
 - **Review login context**
   - Examine associated FortiGate log messages for details such as login method, interface, or authentication source.
   - Check for additional administrative actions following the login (policy changes, user creation, configuration exports).
+  - Review  `fortinet.firewall.profile` to identify the FortiGate Admin Profile the identity logged in under.
 
 - **Correlate with recent changes**
   - Verify whether there were recent change requests, onboarding activities, or maintenance windows that explain the login.
@@ -110,9 +111,9 @@ FROM logs-fortinet_fortigate.*, filebeat-* metadata _id
         event.category == "authentication" and event.action == "login" and
         event.outcome == "success" and source.user.roles == "Administrator" and source.user.name is not null
 | stats Esql.logon_count = count(*),
-        Esql.first_time_seen = MIN(@timestamp),
-        Esql.source_ip_values = VALUES(source.ip),
-        Esql.message_values = VALUES(message) by source.user.name
+       Esql.first_time_seen = MIN(@timestamp),
+       Esql.source_ip_values = VALUES(source.ip),
+       Esql.message_values = VALUES(message) by source.user.name, fortinet.firewall.profile
 
 // first time seen is within 6m of the rule execution time and for the last 5d of events history
 | eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now())
@@ -121,7 +122,14 @@ FROM logs-fortinet_fortigate.*, filebeat-* metadata _id
 // move dynamic fields to ECS equivalent for rule exceptions
 | eval source.ip = MV_FIRST(Esql.source_ip_values)
 
-| keep source.ip, source.user.name, Esql.*
+| keep source.ip,
+       source.user.name,
+       fortinet.firewall.profile,
+       Esql.logon_count,
+       Esql.first_time_seen,
+       Esql.source_ip_values,
+       Esql.message_values,
+       Esql.recent
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/github-private-repository-turned-public.asciidoc b/docs/detections/prebuilt-rules/rule-details/github-private-repository-turned-public.asciidoc
index bfc74dcd2f..af2c7ae078 100644
--- a/docs/detections/prebuilt-rules/rule-details/github-private-repository-turned-public.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/github-private-repository-turned-public.asciidoc
@@ -30,7 +30,7 @@ Detects when a private GitHub repository is changed to public visibility. Advers
 * Data Source: Github
 * Resources: Investigation Guide
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -88,7 +88,7 @@ This rule flags when a previously private repository is made public, a high-risk
 [source, js]
 ----------------------------------
 configuration where data_stream.dataset == "github.audit" and github.operation_type == "modify" and github.category == "repo" and
-event.action == "repo.access" and github.previous_visibility == "private" and github.visibility == "public"
+event.action == "repo.access" and github.visibility == "public"
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-device-registration-after-oauth-from-suspicious-asn.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-device-registration-after-oauth-from-suspicious-asn.asciidoc
new file mode 100644
index 0000000000..cd2726f084
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-device-registration-after-oauth-from-suspicious-asn.asciidoc
@@ -0,0 +1,133 @@
+[[google-workspace-device-registration-after-oauth-from-suspicious-asn]]
+=== Google Workspace Device Registration After OAuth from Suspicious ASN
+
+Detects when a Google Workspace account completes OAuth authorization for a specific Google OAuth client from a high-risk autonomous system number (ASN), followed within 30 seconds by a device registration event with account state REGISTERED. This sequence can indicate device enrollment or join flows initiated from attacker-controlled or residential-proxy infrastructure after a user authorizes a sensitive client.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-google_workspace*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one
+* https://support.google.com/a/answer/7061566
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: Google Workspace
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Initial Access
+* Threat: Tycoon2FA
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Google Workspace Device Registration After OAuth from Suspicious ASN*
+
+
+Review `user.name`, `user.email`, `source.ip`, `source.as.organization.name`, `google_workspace.token.client.id`,
+`google_workspace.token.app_name`, and device fields on the second event (for example device display name or ID if
+present in your schema).
+
+Confirm whether the user intentionally registered a device and whether the OAuth client and ASN are expected for your
+mobile device management or enrollment program.
+
+
+*Possible investigation steps*
+
+
+- Correlate both events on `user.name` and timestamps to confirm the sequence is a single enrollment story.
+- Revoke or audit OAuth grants for the client if the authorization was not expected.
+- Search for additional `google_workspace.device` registrations from the same ASN in the same period.
+
+
+*Response and remediation*
+
+
+- If malicious, remove the unauthorized device from the Google Admin console, reset the user password, and revoke
+  active sessions and tokens per incident policy.
+- Restrict device registration and review OAuth app access policies.
+
+
+
+
+*Event lag*
+
+
+Google Workspace audit data can lag minutes to days behind real time. If sequences are missed, increase `from` and
+lower the integration poll interval per Google and Elastic documentation.
+
+==== Setup
+
+
+The Google Workspace Fleet integration or Filebeat Google Workspace module must ingest `google_workspace.token` and
+`google_workspace.device` audit streams.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by user.name with maxspan=30s
+  [iam where data_stream.dataset == "google_workspace.token" and event.action == "authorize" and
+      google_workspace.token.client.id == "77185425430.apps.googleusercontent.com" and
+      source.as.number in (9009, 45102, 215540, 29802, 62240, 204957, 395092)]
+  [any where data_stream.dataset == "google_workspace.device" and google_workspace.device.account_state == "REGISTERED"]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Sub-technique:
+** Name: Device Registration
+** ID: T1098.005
+** Reference URL: https://attack.mitre.org/techniques/T1098/005/
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Phishing
+** ID: T1566
+** Reference URL: https://attack.mitre.org/techniques/T1566/
+* Sub-technique:
+** Name: Spearphishing Link
+** ID: T1566.002
+** Reference URL: https://attack.mitre.org/techniques/T1566/002/
diff --git a/docs/detections/prebuilt-rules/rule-details/group-policy-abuse-for-privilege-addition.asciidoc b/docs/detections/prebuilt-rules/rule-details/group-policy-abuse-for-privilege-addition.asciidoc
index 2e50567de8..714c55bd87 100644
--- a/docs/detections/prebuilt-rules/rule-details/group-policy-abuse-for-privilege-addition.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/group-policy-abuse-for-privilege-addition.asciidoc
@@ -24,7 +24,7 @@ Detects the first occurrence of a modification to Group Policy Object Attributes
 *References*: 
 
 * https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0025_windows_audit_directory_service_changes.md
-* https://labs.f-secure.com/tools/sharpgpoabuse
+* https://labs.withsecure.com/tools/sharpgpoabuse
 
 *Tags*: 
 
@@ -37,7 +37,7 @@ Detects the first occurrence of a modification to Group Policy Object Attributes
 * Use Case: Active Directory Monitoring
 * Data Source: Windows Security Event Logs
 
-*Version*: 214
+*Version*: 215
 
 *Rule authors*: 
 
@@ -57,21 +57,45 @@ Detects the first occurrence of a modification to Group Policy Object Attributes
 *Investigating Group Policy Abuse for Privilege Addition*
 
 
-Group Policy Objects (GPOs) can be used to add rights and/or modify Group Membership on GPOs by changing the contents of an INF file named GptTmpl.inf, which is responsible for storing every setting under the Security Settings container in the GPO. This file is unique for each GPO, and only exists if the GPO contains security settings. Example Path: "\\DC.com\SysVol\DC.com\Policies\{PolicyGUID}\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf"
-
-
 *Possible investigation steps*
 
 
-- This attack abuses a legitimate mechanism of Active Directory, so it is important to determine whether the activity is legitimate and the administrator is authorized to perform this operation.
-- Retrieve the contents of the `GptTmpl.inf` file, and under the `Privilege Rights` section, look for potentially dangerous high privileges, for example: SeTakeOwnershipPrivilege, SeEnableDelegationPrivilege, etc.
-- Inspect the user security identifiers (SIDs) associated with these privileges, and if they should have these privileges.
+- What GPO extension change was preserved?
+  - Focus: `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.AttributeValue`, `winlog.event_data.OperationType`, `winlog.event_data.ObjectDN`, and `winlog.event_data.ObjectGUID` confirm the 5136 "gPCMachineExtensionNames" GPO change.
+  - Implication: escalate when the value enables Security CSE GUID "827D319E-6EAC-11D2-A4EA-00C04F79F83A" plus Computer Restricted Groups GUID "803E14A0-B4FB-11D0-A0D0-00A0C90F574B" on an unexpected GPO; lower concern only when artifacts/scope confirm a recognized hardening refresh.
+- Who changed the GPO, and from where?
+  - Focus: identify the writer: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectLogonId`, and `winlog.computer_name`.
+  - Hint: on `winlog.computer_name`, find "4624" where `winlog.event_data.TargetLogonId` equals the 5136 `winlog.event_data.SubjectLogonId`; search "4648" on `winlog.event_data.SubjectLogonId` for explicit credentials, then check `source.ip`, `winlog.logon.type`, `winlog.event_data.TargetUserName`, and `winlog.event_data.TargetServerName`. Missing logon telemetry is unresolved, not benign.
+    - !{investigate{"description":"","label":"Linked logon for the GPO writer","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Explicit-credential events for the GPO writer","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Implication: escalate when the writer is outside GPO admin cohort, uses an unusual source or direct domain-controller session, or shows alternate-credential use; lower concern when account/session match a recognized GPO administration path.
+- Do surrounding directory changes show a coordinated GPO update?
+  - Why: "5136" can record related object modifications; `winlog.event_data.OpCorrelationID` separates one GPO edit from directory noise.
+  - Focus: reconstruct surrounding "5136" records from the same domain controller with `winlog.event_data.OpCorrelationID`, `winlog.event_data.SubjectLogonId`, `winlog.event_data.ObjectGUID`, changed attribute, and operation type.
+  - Hint: prefer one `winlog.event_data.OpCorrelationID`; if absent, use the same `winlog.event_data.SubjectLogonId` plus tight `@timestamp` and `winlog.record_id` ordering. !{investigate{"description":"","label":"5136 events in this GPO change operation","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.OpCorrelationID","queryType":"phrase","value":"{{winlog.event_data.OpCorrelationID}}","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the operation touches other sensitive GPO attributes or combines this privilege path with GPO execution or persistence; lower concern when the 5136 set stays narrow and artifact/scope checks confirm one recognized security-template task.
+- What grants and recipients does the SYSVOL template define?
+  - Why: the alert proves machine security extensions were enabled; rights or local group membership live in "GptTmpl.inf" under the SYSVOL policy folder.
+  - Focus: use the policy GUID from the CN portion of `winlog.event_data.ObjectDN` with `winlog.event_data.DSName` to inspect "Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf"; map SIDs/groups to admin tier, service-account role, and whether `winlog.event_data.SubjectUserSid` benefits. Treat `winlog.event_data.ObjectGUID` as the AD object pivot, not the SYSVOL folder name, unless it matches the CN.
+  - Hint: if SYSVOL is unavailable, preserve `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.DSName`, and expected policy path; suspicious writer/session or companion 5136 evidence makes the missing grant an evidence gap.
+  - Implication: escalate when "[Privilege Rights]" grants high-impact rights ("SeDebugPrivilege", "SeTakeOwnershipPrivilege", "SeEnableDelegationPrivilege", or "SeImpersonatePrivilege"), when "[Group Membership]" adds broad/unexpected identities to local Administrators ("S-1-5-32-544"), or when the writer benefits; lower concern when entries and recipients match the recognized baseline for that GPO.
+- Which computers consume the changed GPO?
+  - Why: GPO privilege abuse scales with link scope, security filtering, WMI filters, and reach to admin workstations, servers, or domain controllers.
+  - Focus: use `winlog.event_data.ObjectDN` and the recovered policy-folder GUID to review GPO links, security filtering, WMI filters, and roles.
+  - Hint: if scope data is unavailable, preserve `winlog.event_data.ObjectDN` and `winlog.event_data.ObjectGUID`; do not assume narrow scope, and escalate if writer/session, companion-change, or grant evidence is suspicious.
+  - Implication: prioritize escalation when the GPO reaches domain controllers, admin workstations, servers, or broad workstations; lower urgency only when scope matches the recognized maintenance/test population established by the grant evidence.
+- If evidence remains suspicious or unresolved, do related events show broader abuse?
+  - Focus: after confirming `user.id` is the writer, review recent modifying-account activity. !{investigate{"description":"","label":"Recent events associated with the source account","providers":[[{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: compare with activity scoped to the same `winlog.event_data.ObjectGUID`. !{investigate{"description":"","label":"Events associated with the modified GPO","providers":[[{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate scope when the writer or same GPO appears in other GPO abuse, credential access, privilege escalation, or lateral movement; quiet history only narrows scope and cannot close unresolved grant or blast-radius questions.
+- Escalate for unexpected writer/session, companion change, high-impact grant, sensitive scope, or related abuse; close only when the same GPO, writer/session, recovered grants, and scope prove one recognized hardening or restricted-groups workflow; if evidence stays mixed or incomplete, preserve GPO artifacts and escalate.
 
 
 *False positive analysis*
 
 
-- Inspect whether the user that has done the modifications should be allowed to. The user name can be found in the `winlog.event_data.SubjectUserName` field.
+- Authorized GPO hardening, restricted-groups maintenance, red-team, or detection-validation can update "gPCMachineExtensionNames" and "GptTmpl.inf". Confirm only when writer/session, GPO object, `winlog.event_data.OpCorrelationID`, recovered template entries, and linked scope match the admin tier, change window, template, or test plan. Quiet history supports but cannot replace that proof; if any anchor diverges, do not close as benign.
+- For exceptions, validate one authorized workflow matching writer SID, GPO object, grant pattern, and linked OU/host scope. Build the exception from that pattern, not broad `event.code`, "gPCMachineExtensionNames", or GPO modification activity.
 
 
 *Related rules*
@@ -84,10 +108,11 @@ Group Policy Objects (GPOs) can be used to add rights and/or modify Group Member
 *Response and remediation*
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- The investigation and containment must be performed in every computer controlled by the GPO, where necessary.
-- Remove the script from the GPO.
-- Check if other GPOs have suspicious scripts attached.
+- If confirmed benign, reverse temporary containment and document writer SID, GPO object, logon/correlation IDs, recovered "GptTmpl.inf", and OU/host scope matching the workflow. Keep exceptions narrow and tied to that stable pattern.
+- If suspicious but unconfirmed, preserve the "5136" event, object and writer/session IDs, `winlog.event_data.OpCorrelationID`, `winlog.computer_name`, exported "GptTmpl.inf", available SYSVOL metadata, linked "4624"/"4648" events, and related activity before containment. Use reversible controls first: restrict affected-GPO edits, limit the writer's GPO admin path, or monitor linked systems during scoping. Disable accounts or roll back GPOs only if follow-on abuse or malicious grants are confirmed.
+- If confirmed malicious, preserve evidence first, remove unauthorized "[Privilege Rights]" or "[Group Membership]" entries, roll the GPO back to known-good state, and verify exported SYSVOL metadata before forcing policy refresh. Use identity/endpoint response to contain the writer account and admin workstation identified by `source.ip` or `winlog.logon.type`; if unavailable, escalate with writer/session, GPO, correlation, and SYSVOL artifacts.
+- Review linked OUs and affected computers before deleting artifacts or forcing "gpupdate"; complete scoping before evidence changes.
+- Harden: restrict GPO edit rights to dedicated admin tiers, retain "5136" auditing, keep security-template baselines, and document abuse variants or visibility gaps for detection engineering.
 
 
 ==== Setup
@@ -97,19 +122,8 @@ Group Policy Objects (GPOs) can be used to add rights and/or modify Group Member
 *Setup*
 
 
-The 'Audit Directory Service Changes' audit policy must be configured (Success Failure).
-Steps to implement the logging policy with Advanced Audit Configuration:
-
-```
-Computer Configuration >
-Policies >
-Windows Settings >
-Security Settings >
-Advanced Audit Policies Configuration >
-Audit Policies >
-DS Access >
-Audit Directory Service Changes (Success,Failure)
-```
+Audit Directory Service Changes must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-directory-service-changes
 
 
 ==== Rule query
diff --git a/docs/detections/prebuilt-rules/rule-details/inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc b/docs/detections/prebuilt-rules/rule-details/inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc
index 2cf42e3c54..4ed1681ec5 100644
--- a/docs/detections/prebuilt-rules/rule-details/inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc
@@ -33,7 +33,7 @@ Identifies Elasticsearch nodes that do not have Transport Layer Security (TLS),
 * Domain: Endpoint
 * Resources: Investigation Guide
 
-*Version*: 107
+*Version*: 108
 
 *Rule authors*: 
 
@@ -101,7 +101,7 @@ This rule requires the addition of port `9200` and `send_all_headers` to the `HT
 [source, js]
 ----------------------------------
 (data_stream.dataset: network_traffic.http OR (event.category: network_traffic AND network.protocol: http)) AND
-    status:OK AND destination.port:9200 AND network.direction:inbound AND NOT http.response.headers.content-type:"image/x-icon" AND NOT
+     http.response.status_code:200 AND destination.port:9200 AND network.direction:inbound AND NOT http.response.headers.content-type:"image/x-icon" AND NOT
     _exists_:http.request.headers.authorization
 
 ----------------------------------
diff --git a/docs/detections/prebuilt-rules/rule-details/incoming-dcom-lateral-movement-via-mshta.asciidoc b/docs/detections/prebuilt-rules/rule-details/incoming-dcom-lateral-movement-via-mshta.asciidoc
index 298c03a340..67d36acafc 100644
--- a/docs/detections/prebuilt-rules/rule-details/incoming-dcom-lateral-movement-via-mshta.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/incoming-dcom-lateral-movement-via-mshta.asciidoc
@@ -24,7 +24,7 @@ Identifies the use of Distributed Component Object Model (DCOM) to execute comma
 
 *References*: 
 
-* https://codewhitesec.blogspot.com/2018/07/lethalhta.html
+* https://code-white.com/blog/2018-07-lethalhta/
 
 *Tags*: 
 
@@ -36,7 +36,7 @@ Identifies the use of Distributed Component Object Model (DCOM) to execute comma
 * Data Source: Sysmon
 * Resources: Investigation Guide
 
-*Version*: 211
+*Version*: 212
 
 *Rule authors*: 
 
@@ -52,47 +52,91 @@ Identifies the use of Distributed Component Object Model (DCOM) to execute comma
 *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 Incoming DCOM Lateral Movement via MSHTA*
 
 
-DCOM allows software components to communicate over a network, enabling remote execution of applications like MSHTA, which runs HTML applications. Adversaries exploit this by executing commands remotely, bypassing traditional security measures. The detection rule identifies suspicious MSHTA activity by monitoring process starts and network traffic, focusing on unusual port usage and remote IP addresses, indicating potential lateral movement attempts.
 
+*Investigation steps*
+
+
+- Do recovered source events show remote COM activation of mshta on this host?
+  - Focus: alert `host.id` and `process.entity_id`; recover `process.command_line` plus matching network `source.ip`, `source.port`, `destination.port`, and `network.direction`.
+  - Implication: escalate when the COM-server process receives incoming non-loopback RPC-style TCP from an unconfirmed source; lower only when telemetry and exact confirmation tie source, target, and COM-server launch to recurring distribution or helpdesk activity. Missing source events leave the alert unresolved.
+
+- Is mshta the expected Windows COM server, not a staged or masqueraded copy?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.parent.executable`.
+  - Implication: escalate when mshta runs from a user-writable or non-Windows path, has an unexpected signer, or lacks a service/DCOM-style parent such as "svchost.exe"; Microsoft identity lowers only masquerade risk because source and retrieval still decide the case.
+
+- Do source, account, and logon context support the same confirmed workflow?
+  - Focus: recovered `source.ip`, target-side `user.id`, and session bridge `process.Ext.authentication_id`, `winlog.event_data.TargetLogonId`, and `winlog.event_data.AuthenticationPackageName`.
+  - Implication: escalate when source, account, session type, or auth package conflict with the source-event workflow; lower only when telemetry and exact confirmation identify a legitimate source-to-host relationship. Missing Windows Security telemetry leaves origin and auth method unresolved, not benign.
+
+- Does same-process DNS/connection data show remote script retrieval?
+  - Why: HTA COM can load remote script content into "mshta.exe"; same-process retrieval is direct corroboration.
+  - Focus: same-process DNS `dns.question.name` and `dns.resolved_ip`, then connection `destination.ip` and `destination.port`. !{investigate{"description":"","label":"Network events for the mshta process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: map `dns.question.name` to `dns.resolved_ip` before tying later `destination.ip` to retrieval.
+  - Implication: escalate when mshta resolves or connects to public, rare, or mismatched content hosts; lower only when the destination maps to the same recognized internal or vendor workflow as the source. Missing DNS or connection telemetry leaves retrieval unresolved, not benign.
 
-*Possible investigation steps*
+- Do file artifacts show cached HTA content or staged payloads?
+  - Focus: same-host file events tied to `host.id` and mshta or follow-on `process.entity_id`, especially `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and `file.Ext.original.path`. !{investigate{"description":"","label":"File events for the mshta process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Range: start with the alert window; expand after the first suspicious write to confirm later execution.
+  - Implication: escalate when the chain writes HTA/script/payload content to temp, downloads, ADS-like, systemprofile "INetCache", or extensionless paths, or when the artifact later executes; lower when artifacts stay in one recurring deployment path. Missing file telemetry is unresolved, not benign.
 
+- Does mshta stay in-process or hand off execution?
+  - Why: LethalHTA can run JScript/VBScript, DotNetToJScript, CLR, or beacon code inside "mshta.exe"; absence of child processes does not clear the alert.
+  - Focus: child process starts from recovered mshta `process.entity_id`. !{investigate{"description":"","label":"Child process starts from the mshta process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Library: same-process `dll.path`, `dll.code_signature.subject_name`, `dll.code_signature.trusted`, and `dll.Ext.relative_file_creation_time`. !{investigate{"description":"","label":"Library events for the mshta process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when mshta spawns shells, downloaders, proxy-execution utilities, or loads recent/untrusted libraries from writable or nonstandard paths; narrow only when no follow-on execution appears and earlier source, session, and retrieval fit one recognized workflow. Missing library telemetry leaves in-process payload review unresolved, not benign.
 
-- Review the process start event for mshta.exe on the affected host to gather details such as the process entity ID, command-line arguments, and parent process information to understand how mshta.exe was executed.
-- Analyze the network traffic associated with the mshta.exe process, focusing on the source and destination IP addresses and ports, to identify any unusual or unauthorized remote connections.
-- Check the source IP address involved in the network event to determine if it is known or associated with any previous suspicious activity or if it belongs to an internal or external network.
-- Investigate the timeline of events on the host to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern or lateral movement attempts.
-- Correlate the findings with other security logs and alerts from the same host or network segment to identify any additional indicators of compromise or related malicious activities.
-- Assess the risk and impact of the detected activity by considering the host's role within the network and any sensitive data or systems it may have access to.
+- Do related alerts change scope?
+  - Focus: related lateral-movement, proxy-execution, or follow-on delivery alerts for `host.id` in the prior 48h. !{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"}}
+  - Hint: use the host-scoped transform first; search recovered `source.ip`, `dns.question.name`, or `destination.ip` across other targets only if local evidence remains suspicious or unresolved.
+  - Implication: escalate scope when the host shows adjacent lateral-movement, proxy-execution, or follow-on delivery alerts, or when the source touches additional targets; keep the case local when the alert is isolated and earlier evidence fits one stable workflow.
+
+- Escalate unauthorized DCOM HTA execution when source-event chain, source/session fit, retrieval, artifacts/libraries, child execution, or related-alert scope remain suspicious; close only when pivots bind one recognized host workflow without contradictory retrieval, artifact, or follow-on activity; if answers stay mixed or incomplete, preserve evidence and escalate.
 
 
 *False positive analysis*
 
 
-- Legitimate administrative tasks using MSHTA for remote management can trigger the rule. Identify and document these tasks, then create exceptions for known administrative IP addresses or specific user accounts.
-- Automated software updates or deployments that utilize MSHTA may appear as suspicious activity. Monitor and whitelist the IP addresses and ports associated with these updates to prevent false positives.
-- Internal network scanning tools or security assessments might mimic lateral movement behavior. Coordinate with IT and security teams to recognize these activities and exclude them from triggering alerts.
-- Custom applications that leverage MSHTA for inter-process communication could be flagged. Review these applications and exclude their known processes or network patterns from the detection rule.
-- Remote desktop or support tools that use MSHTA for legitimate purposes should be identified. Whitelist these tools by their process names or associated network traffic to reduce unnecessary alerts.
+- Management tooling (software distribution, enrollment, or helpdesk launchers) can legitimately activate the HTA COM object. Confirm `source.ip` is the management host, mshta identity and `process.parent.executable` match that tool, DNS/destination pattern serves it, and artifacts, children, or libraries do not contradict it. Telemetry that cannot prove legitimacy needs change, distribution, asset, or owner confirmation.
+- Do not close on partial context: known admin subnet, Microsoft-signed "mshta.exe", or familiar user alone. If any evidence dimension contradicts the expected workflow, or neither telemetry nor exact confirmation proves it, treat the alert as suspicious or unresolved.
+- Anchor exceptions on the minimum confirmed workflow: recognized `source.ip`, stable `process.parent.executable`, recovered `process.command_line`, specific benign `dns.question.name` or `destination.ip`, and relevant `host.id`. Avoid exceptions on `process.name` of "mshta.exe", incoming high ports, or `user.name` alone.
 
 
 *Response and remediation*
 
 
-- Isolate the affected host immediately from the network to prevent further lateral movement and potential data exfiltration.
-- Terminate the mshta.exe process on the affected host to stop any ongoing malicious activity.
-- Conduct a thorough examination of the affected host to identify any additional malicious files or processes, focusing on those initiated around the time of the alert.
-- Reset credentials for any accounts that were active on the affected host during the time of the alert to prevent unauthorized access.
-- Review and restrict DCOM permissions and configurations on the affected host and other critical systems to limit the potential for similar attacks.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems have been compromised.
-- Update detection mechanisms and threat intelligence feeds to enhance monitoring for similar DCOM-based lateral movement attempts in the future.
+- If confirmed benign, reverse temporary containment and document source, target host, mshta identity, parent context, destination pattern, and artifact evidence confirming the recognized workflow. Create an exception only for the exact pattern confirmed by telemetry and supporting records or owner confirmation.
+- If suspicious but unconfirmed, preserve Timeline source events, mshta identity and command line, remote source and high-port pair, DNS and destination evidence, cached/staged files, child processes, suspicious libraries, and relevant case exports before containment or cleanup.
+- Apply reversible containment first: restrict DCOM or web retrieval between the target and recovered source/destination, increase monitoring on `host.id` and `user.id`, or isolate the endpoint only when retrieval, child execution, or library evidence indicates active payload execution and the host role permits isolation.
+- If confirmed malicious, isolate the target endpoint and contain the recovered source system or account when in scope. Block malicious domains, destinations, and hashes; record process and artifact IDs before killing processes or deleting files.
+- Scope other hosts reached by the same recovered `source.ip`, `dns.question.name`, `destination.ip`, or `process.command_line` pattern before destructive eradication, credential removal, or broad DCOM changes.
+- Eradicate only identified HTA, HTML, script, DLL, cached content, or staged payloads, then remediate the DCOM exposure, application workflow, or credentials that enabled remote execution.
+- Post-incident hardening: restrict DCOM exposure to recognized management paths, keep Windows Firewall or equivalent RPC controls enabled for the host class, limit HTA use to recognized workflows, retain process/network/file/library telemetry, and record SMB/named-pipe delivery if found during scoping.
+
+
+==== 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]
+- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection]
+
 
 ==== Rule query
 
diff --git a/docs/detections/prebuilt-rules/rule-details/incoming-dcom-lateral-movement-with-mmc.asciidoc b/docs/detections/prebuilt-rules/rule-details/incoming-dcom-lateral-movement-with-mmc.asciidoc
index 84ad9856ff..7395ec9b71 100644
--- a/docs/detections/prebuilt-rules/rule-details/incoming-dcom-lateral-movement-with-mmc.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/incoming-dcom-lateral-movement-with-mmc.asciidoc
@@ -32,12 +32,11 @@ Identifies the use of Distributed Component Object Model (DCOM) to run commands
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Lateral Movement
-* Tactic: Defense Evasion
 * Data Source: Elastic Defend
 * Data Source: Sysmon
 * Resources: Investigation Guide
 
-*Version*: 212
+*Version*: 213
 
 *Rule authors*: 
 
@@ -53,46 +52,84 @@ Identifies the use of Distributed Component Object Model (DCOM) to run commands
 *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 Incoming DCOM Lateral Movement with MMC*
 
 
-Distributed Component Object Model (DCOM) enables software components to communicate over a network, often used in Windows environments for remote management. Adversaries exploit DCOM to execute commands remotely, leveraging applications like MMC20 to move laterally. The detection rule identifies suspicious activity by monitoring network traffic and process creation patterns, flagging potential misuse when MMC initiates remote commands, indicating possible lateral movement or defense evasion tactics.
-
 
 *Possible investigation steps*
 
 
-- Review the network traffic logs to identify the source IP address that initiated the connection to the host running mmc.exe. Verify if this IP address is known and expected within the network environment.
-- Examine the process creation logs to confirm the parent-child relationship between mmc.exe and any suspicious processes. Investigate the child processes for any unusual or unauthorized activities.
-- Check the source and destination ports (both should be >= 49152) involved in the network connection to determine if they align with typical application behavior or if they are indicative of potential misuse.
-- Investigate the timeline of events to see if there are any other related alerts or activities on the same host or originating from the same source IP address, which could provide additional context or indicate a broader attack pattern.
-- Correlate the findings with any existing threat intelligence or known attack patterns related to DCOM abuse and lateral movement to assess the potential risk and impact on the organization.
+- Which Timeline source events define the target MMC instance, spawned child, and remote source?
+  - Why: this asymmetric sequence links incoming "mmc.exe" network activity to a child process, and the alert may not preserve one reliable process identity.
+  - Focus: recover the target MMC network event and child process event, recording target MMC and child `process.entity_id`, `source.ip`, and child `process.command_line`.
+  - Implication: escalate if the chain does not resolve to one incoming MMC process spawning one child; lower suspicion only when it fits a recognized MMC administration source and child, then continue to command and network interpretation.
+- Does the network event fit remote DCOM or RPC traffic into MMC?
+  - Focus: the recovered "mmc.exe" network event: `source.ip`, `source.port`, `destination.port`, `network.direction`, and `network.transport`.
+  - Implication: DCOM-style remote execution is supported by incoming TCP from a non-loopback `source.ip` with both ports in the high RPC range; concern rises when the source is a peer workstation, unrelated server, or unknown management origin.
+- What did MMC execute through MMC20.Application COM automation?
+  - Focus: recovered child `process.executable` and `process.command_line`.
+  - Implication: escalate when MMC launches cmd.exe, PowerShell, script hosts, LOLBins, loaders, or download cradles; lower suspicion only when the exact child command is a recognized MMC snap-in helper or management binary and the source context also fits.
+- Is the child binary identity consistent with the behavior, without treating signer trust as clearance?
+  - Focus: child `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and entity context.
+  - Implication: mismatched PE metadata, user-writable paths, unexpected publishers, or quick follow-on LOLBin execution increases concern; a trusted signer confirms identity only and does not clear remote command execution.
+- Does the target-side user and session fit remote administration from the recovered source?
+  - Focus: child `user.id`, `user.name`, and `user.domain`, compared with the recovered source and target host.
+  - Implication: escalate when the user, service context, or session is unexpected for that target or cannot explain administrative access from the source; lower suspicion when source, identity, and session match a recognized admin or jump-host path.
+- Did the MMC-spawned child launch descendants after execution?
+  - Focus: same-host process events from the child, checking child-of-child `process.parent.entity_id`. !{investigate{"description":"","label":"Processes spawned by MMC on this host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.name","queryType":"phrase","value":"mmc.exe","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the child launches more execution chains; absent descendants keeps the case centered on the recovered remote command, not benign.
+- Did the child make DNS or connection activity?
+  - Focus: same-host network events, checking DNS `dns.question.name` and connection `destination.ip`. !{investigate{"description":"","label":"Network events for MMC on this host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"mmc.exe","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: separate DNS events from connection events and keep the pivot bounded to the alert window. Missing network telemetry is unresolved, not benign.
+  - Implication: escalate when the child resolves rare domains or connects to staging or command infrastructure.
+- Does the recovered source or child command appear on other hosts after local triage stays suspicious?
+  - Focus: same-host alerts for `host.id`. !{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"}}
+  - Hint: if the same account is suspicious, compare same-`user.id` alerts for lateral-movement or credential-access patterns across other hosts. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: broaden only after local evidence remains suspicious or unresolved; use `source.ip` for spread and a distinctive child `process.command_line` fragment for tool reuse.
+  - Implication: expand scope when the same source touches more targets, the same child command appears elsewhere, or same-host alerts show lateral movement or defense evasion; keep the case local when the pattern stays confined and the workflow is otherwise explained.
+
+- Escalate when source identity, incoming high-RPC network shape, child intent, identity/session, or descendant/DNS/destination evidence supports unauthorized MMC20.Application execution; close only when recovered evidence, with external confirmation when telemetry cannot prove intent, binds one exact recognized MMC administration workflow with no contradictory follow-on evidence; mixed or incomplete evidence means preserve and escalate.
 
 
 *False positive analysis*
 
 
-- Legitimate administrative tasks using MMC may trigger the rule. Regularly review and document routine administrative activities to differentiate them from suspicious behavior.
-- Automated scripts or management tools that use MMC for remote management can cause false positives. Identify and whitelist these tools by their process and network patterns.
-- Internal network scanning or monitoring tools might mimic the behavior detected by the rule. Exclude known IP addresses or ranges associated with these tools to reduce noise.
-- Scheduled tasks or maintenance operations that involve MMC could be misinterpreted as lateral movement. Ensure these tasks are logged and recognized as part of normal operations.
-- Software updates or patches that require MMC to execute remote commands might trigger alerts. Maintain an updated list of such activities and exclude them from triggering the rule.
+- Remote MMC, server-management automation, or vendor/internal tooling can legitimately trigger this rule when a management host uses DCOM to drive MMC snap-ins or support commands. Confirm the recovered `source.ip` is a recognized admin, jump, or tooling host; child `process.executable` and `process.command_line` show the exact console/helper action; `user.id` or `user.name` fits that path; child `process.hash.sha256` or `process.code_signature.subject_name` is stable when tooling is involved; and descendant, DNS, and connection evidence stays quiet. If inventory or change records are unavailable, telemetry-only closure still requires current evidence to prove the exact workflow; prior recurrence of the same `source.ip`, child command, and `host.id` pattern is corroboration, not closure by itself.
+- Before creating an exception, anchor it on the minimum confirmed workflow pattern: recognized `source.ip`, child `process.executable`, stable `process.command_line`, expected `user.id` or `user.name`, and the relevant `host.id` scope. Avoid exceptions on `process.parent.name` of "mmc.exe" or high RPC ports alone.
 
 
 *Response and remediation*
 
 
-- Isolate the affected host immediately from the network to prevent further lateral movement and contain the threat.
-- Terminate any suspicious processes associated with mmc.exe on the affected host to stop any ongoing malicious activity.
-- Conduct a thorough review of the affected host's event logs and network traffic to identify any additional indicators of compromise or other affected systems.
-- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access.
-- Apply patches and updates to the affected systems and any other vulnerable systems in the network to mitigate known vulnerabilities that could be exploited.
-- Implement network segmentation to limit the ability of threats to move laterally within the network in the future.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional actions are necessary.
+- If confirmed benign, record the recovered `source.ip`, child `process.executable`, child `process.command_line`, `user.id` or `user.name`, and target `host.id` that established the management workflow, then reverse any temporary containment. Create an exception only if the same pattern recurs consistently across prior alerts.
+- If suspicious but unconfirmed, preserve a case export of the Timeline source events, the target MMC and child process instance IDs, child command line, source socket, and DNS/destination indicators before containment or cleanup.
+- If suspicious but unconfirmed, apply reversible containment tied to the evidence, such as temporary DCOM/RPC restrictions from the recovered `source.ip` to the target `host.id`; isolate the host only when the child command or follow-on activity indicates payload execution and the host role can tolerate it.
+- If confirmed malicious, first preserve the target MMC instance, child command, recovered source, descendant processes, and malicious DNS or destination indicators. Then isolate the target host and contain the recovered source system if it is in response scope; terminate processes or delete artifacts only after preservation and scoping.
+- Review other hosts touched by the same recovered `source.ip` or child `process.command_line` pattern before terminating additional processes or removing artifacts so scoping completes before evidence is destroyed.
+- Eradicate only scripts, binaries, persistence, or configuration changes identified during the investigation, then remediate the account, source host, or remote administration path that allowed the DCOM execution.
+- Post-incident hardening: keep Windows Firewall enabled, disable unnecessary Microsoft Management Console inbound access, restrict DCOM/RPC between workstations, limit remote administrative rights to recognized jump hosts, and record the evidence and control changes 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/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection]
+
 
 ==== Rule query
 
@@ -101,7 +138,7 @@ Distributed Component Object Model (DCOM) enables software components to communi
 ----------------------------------
 sequence by host.id with maxspan=1m
  [network where host.os.type == "windows" and event.type == "start" and process.name : "mmc.exe" and source.port >= 49152 and
- destination.port >= 49152 and source.ip != "127.0.0.1" and source.ip != "::1" and
+  destination.port >= 49152 and source.ip != "127.0.0.1" and source.ip != "::1" and
   network.direction : ("incoming", "ingress") and network.transport == "tcp"
  ] by process.entity_id
  [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "mmc.exe"
diff --git a/docs/detections/prebuilt-rules/rule-details/interactive-logon-by-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/interactive-logon-by-an-unusual-process.asciidoc
index 6c3427f3da..2e6de39904 100644
--- a/docs/detections/prebuilt-rules/rule-details/interactive-logon-by-an-unusual-process.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/interactive-logon-by-an-unusual-process.asciidoc
@@ -34,7 +34,7 @@ Identifies interactive logon attempt with alternate credentials and by an unusua
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 108
+*Version*: 109
 
 *Rule authors*: 
 
@@ -50,45 +50,59 @@ Identifies interactive logon attempt with alternate credentials and by an unusua
 *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 Interactive Logon by an Unusual Process*
 
 
-Interactive logons in Windows environments typically involve standard processes like winlogon.exe. Adversaries may exploit alternate processes to create tokens, escalating privileges and bypassing controls. This detection rule identifies anomalies by flagging logons via non-standard executables, focusing on mismatched user SIDs and unusual process paths, thus highlighting potential privilege escalation attempts.
-
-
 *Possible investigation steps*
 
 
-- Review the process executable path to determine if it is a known or expected application for interactive logons. Investigate any unfamiliar or suspicious paths.
-- Examine the SubjectUserSid and TargetUserSid to identify the users involved in the logon attempt. Check for any discrepancies or unusual patterns in user activity.
-- Analyze the event logs around the time of the alert to identify any related or preceding events that might indicate how the unusual process was initiated.
-- Investigate the system for any signs of compromise, such as unexpected changes in system files, unauthorized software installations, or other indicators of malicious activity.
-- Check for any recent privilege escalation attempts or access token manipulations that might correlate with the alert, using the MITRE ATT&CK framework references for guidance.
+- Did Advapi create an interactive logon for a different target identity?
+  - Focus: `winlog.logon.type`, `winlog.event_data.LogonProcessName`, `winlog.event_data.SubjectUserSid`, `winlog.event_data.TargetUserSid`, and `host.id`.
+  - Implication: escalate when Advapi creates a different Target session without recognized credential-switch use; lower suspicion only for bounded runas or helper use on this host. Subject initiated the action; Target received the session or token.
+- Which process requested the alternate-credential session?
+  - Focus: `process.executable`, `process.name`, `process.pid`, `winlog.event_data.SubjectUserName`, and `winlog.event_data.SubjectDomainName`.
+  - Implication: escalate when the requester is user-writable, temporary, renamed, or unrelated to credential switching; lower suspicion only for System32 runas.exe or a recognized helper tied to the same Subject. Process identity alone does not clear token creation.
+- Did the Target session create privileged or linked-token access?
+  - Focus: `winlog.event_data.TargetUserSid`, `winlog.event_data.TargetLogonId`, `winlog.event_data.TargetLinkedLogonId`, `winlog.event_data.ElevatedToken`, and `winlog.event_data.ImpersonationLevel`.
+  - Implication: escalate on a privileged or unusual Target account, elevated token, linked session, or impersonation-capable token. Keep unresolved when the Target cannot be tied to the requesting Subject and process; a recognized requester does not clear elevated Target token state.
+- Did explicit-credential records show who supplied Target credentials?
+  - Focus: same-host 4648 records using `winlog.event_data.SubjectLogonId`; read `winlog.event_data.TargetUserName`, `winlog.event_data.TargetDomainName`, `winlog.event_data.TargetServerName`, and `source.ip`.
+  - Hint: make-token tooling may leave only Advapi, different Subject/Target SIDs, and Target session fields; do not require endpoint command-line evidence before escalation. !{investigate{"description":"","label":"Explicit-credential events from the subject session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when 4648 shows the same Subject session presenting Target credentials to an unexpected server or non-local origin. Local or absent `source.ip` can occur in make-token cases and must be weighed with requester, identity pair, and token state; missing Security telemetry is unresolved, not benign.
+- Did the created Target session show follow-on success or authentication-method signals?
+  - Focus: same-host 4624 and 4634 records using `winlog.event_data.TargetLogonId`; read `winlog.event_data.TargetUserSid`, `winlog.event_data.AuthenticationPackageName`, and `source.ip`.
+  - Implication: escalate on unexpected authentication package use, repeated successful session activity, or a non-local origin that contradicts local workflow; absent or local source details should be weighed with Target-token evidence. Missing 4624/4634 telemetry is unresolved, not benign.
+    - !{investigate{"description":"","label":"Target logon records for the created session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.TargetLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Target logoff records for the created session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4634","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.TargetLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+- What activity is tied to the created Target logon session?
+  - Focus: same-host events carrying `winlog.event_data.TargetLogonId`, especially process, privilege, or authentication records tied to the Target identity. !{investigate{"description":"","label":"Events for the created target logon session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.TargetLogonId}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.logon.id","queryType":"phrase","value":"{{winlog.event_data.TargetLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the Target session performs privileged operations, starts unexpected processes, or chains authentication; no follow-on telemetry narrows activity only when the requester, identity pair, and token state are otherwise explained.
+- If local evidence remains suspicious or unresolved, do related alerts change scope?
+  - Focus: recent alerts for the same `host.id`, Subject SID, and Target SID.
+    - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Alerts associated with the subject identity","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}],[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Alerts associated with the target identity","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetUserSid","queryType":"phrase","value":"{{winlog.event_data.TargetUserSid}}","valueType":"string"}],[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{winlog.event_data.TargetUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when related alerts show credential access, privilege escalation, persistence, or lateral movement tied to the host or either identity; quiet alert history cannot close unresolved token/session evidence.
+- Escalate on unauthorized Subject-to-Target token creation; close only when the identity pair, requester, Target token, and Security records all bind to one recognized workflow; if mixed, preserve records and use related alerts plus recent session activity to scope the case.
 
 
 *False positive analysis*
 
 
-- Legitimate administrative tools or scripts may trigger this rule if they use non-standard executables for logon processes. To manage this, identify and whitelist these known tools by adding their executable paths to the exception list.
-- Custom applications developed in-house that require interactive logon might be flagged. Review these applications and, if verified as safe, exclude their executable paths from the detection rule.
-- Automated tasks or services that use alternate credentials for legitimate purposes can cause false positives. Analyze these tasks and, if they are part of regular operations, adjust the rule to exclude their specific user SIDs or executable paths.
-- Security software or monitoring tools that perform logon actions for scanning or auditing purposes may be incorrectly flagged. Confirm their legitimacy and add them to the exception list to prevent unnecessary alerts.
+- Recognized runas, enterprise PAM or credential-broker helpers, and authorized assessment can trigger this rule from monitored admin hosts. Confirm `process.executable`, Subject and Target identities, `host.id`, and explicit-credential or session records bind to the same workflow or validation scope; contradictory Target token details block benign closure.
+- Build exceptions only from the minimum confirmed pattern, such as `process.executable` plus `winlog.event_data.SubjectUserSid`, `winlog.event_data.TargetUserSid`, and a bounded `host.id` or host group. Avoid exceptions on `process.name`, `user.name`, or the Target account alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Terminate any suspicious processes identified as executing from non-standard paths that are not part of the legitimate Windows system processes.
-- Revoke any tokens or credentials associated with the anomalous logon session to prevent further misuse.
-- Conduct a thorough review of user accounts involved, focusing on any unauthorized privilege escalations or changes in permissions, and reset passwords as necessary.
-- Analyze the system for any signs of persistence mechanisms or additional malware, and remove any identified threats.
-- Restore the system from a known good backup if any unauthorized changes or malware are detected that cannot be easily remediated.
-- Report the incident to the appropriate internal security team or management for further investigation and potential escalation to law enforcement if necessary.
+- If confirmed benign, document the evidence categories, reverse temporary containment, and create only the narrow exception described above.
+- If suspicious but unconfirmed, export the alert and surrounding Windows Security records, preserve the requesting process image and Subject-to-Target session context, and collect the referenced executable before containment.
+- Apply reversible containment first: restrict the affected account or host session, increase monitoring on the involved `host.id` and identities, and weigh host criticality before isolation.
+- If confirmed malicious, preserve the executable referenced by `process.executable`, session records, and Subject/Target identifiers, then contain involved hosts or accounts and invalidate active sessions.
+- Reset or rotate Target credentials only when compromise or unauthorized use is supported; treat Subject as the operator or requesting context before disabling it.
+- Eradicate only confirmed token-abuse tooling or credential material, review local privilege assignments that allowed the session, and retain Windows Security events needed to reconstruct Subject-to-Target token creation.
 
 ==== Setup
 
@@ -97,7 +111,8 @@ Interactive logons in Windows environments typically involve standard processes
 *Setup*
 
 
-Audit event 4624 is needed to trigger this rule.
+Audit Logon must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-logon
 
 
 ==== Rule query
diff --git a/docs/detections/prebuilt-rules/rule-details/krbtgt-delegation-backdoor.asciidoc b/docs/detections/prebuilt-rules/rule-details/krbtgt-delegation-backdoor.asciidoc
index dfaec0b160..759dc40ba1 100644
--- a/docs/detections/prebuilt-rules/rule-details/krbtgt-delegation-backdoor.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/krbtgt-delegation-backdoor.asciidoc
@@ -37,7 +37,7 @@ Identifies the modification of the msDS-AllowedToDelegateTo attribute to KRBTGT.
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 213
+*Version*: 214
 
 *Rule authors*: 
 
@@ -53,46 +53,59 @@ Identifies the modification of the msDS-AllowedToDelegateTo attribute to KRBTGT.
 *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 KRBTGT Delegation Backdoor*
 
 
-In Active Directory, the KRBTGT account is crucial for Kerberos ticket granting. Adversaries may exploit this by altering the msDS-AllowedToDelegateTo attribute, enabling unauthorized ticket requests and persistent domain access. The detection rule identifies such modifications by monitoring specific event actions and codes, flagging high-risk changes to the KRBTGT delegation settings.
-
 
 *Possible investigation steps*
 
 
-- Review the event logs for the specific event code 4738 to identify the user account that was modified and verify if the msDS-AllowedToDelegateTo attribute includes the KRBTGT service.
-- Investigate the user account that performed the modification by checking their recent activities and login history to determine if the action was authorized or suspicious.
-- Examine the timeline of the modification event to correlate it with any other unusual activities or alerts in the network around the same time.
-- Check for any other modifications to sensitive attributes or accounts in Active Directory that might indicate a broader compromise.
-- Assess the potential impact on the domain by evaluating the access level and permissions of the modified account and any associated systems or services.
-- Consult with the IT security team to determine if there are any known maintenance activities or changes that could explain the modification, ensuring it was not a legitimate administrative action.
+- What account was changed, and what krbtgt delegation value did the alert preserve?
+  - Focus: alert 4738 evidence in `winlog.event_data.TargetSid`, `winlog.event_data.TargetUserName`, `winlog.event_data.TargetDomainName`, `winlog.event_data.AllowedToDelegateTo`, and `winlog.computer_name`.
+  - Implication: Escalate when the target now lists a krbtgt service target such as "krbtgt/DOMAIN"; lower suspicion only when the target, value, and controller match a time-boxed security validation or emergency delegation repair explicitly naming krbtgt, which is not routine delegation.
+
+- Who initiated the account change?
+  - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, and `winlog.event_data.SubjectLogonId`.
+  - Implication: Escalate when a human admin, newly introduced service identity, or unexpected controller-local context made the change; lower suspicion only when the same stable tier-0 identity owns this exact delegation-maintenance path.
+
+- What source and authentication method created the modifying session?
+  - Focus: authentication events on the same `host.id` where `winlog.event_data.TargetLogonId` equals alert `winlog.event_data.SubjectLogonId`; review `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Authentication events for the modifying session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: missing authentication telemetry, or absent `source.ip` on local/service sessions, is unresolved, not benign; review same-session 4648 records when credential-source context matters. !{investigate{"description":"","label":"Explicit-credential events from the modifying session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: Escalate for an unusual source, remote-interactive access, unexpected NTLM, or explicit credentials; lower suspicion when the session maps to the expected tier-0 admin path for this controller.
+
+- Did surrounding directory changes prepare, repeat, or roll back the krbtgt delegation?
+  - Focus: surrounding 4738 records for the same `winlog.event_data.TargetSid`, plus 5136 records on the same `winlog.computer_name` and modifying subject/session; use `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeLDAPDisplayName`, and `winlog.event_data.AttributeValue` to identify the affected object and value.
+  - Hint: reconstruct the burst from same-target 4738 and same-controller directory-service changes; if 5136 grouping is thin, use `winlog.record_id` order on the same controller plus subject/session and object DN. Absent 5136 evidence leaves prerequisite and rollback context unresolved, not benign.
+    - !{investigate{"description":"","label":"4738 changes for this delegation target","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4738","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetSid","queryType":"phrase","value":"{{winlog.event_data.TargetSid}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4738","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"5136 directory changes by this modifying session","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Implication: Escalate when `winlog.event_data.AttributeLDAPDisplayName` and `winlog.event_data.AttributeValue` show delegation-enabling changes, repeated msDS-AllowedToDelegateTo writes, or no rollback; prompt removal narrows the persistence window but does not clear actor or session intent.
+
+- Does the same actor or target touch other delegation-relevant accounts in the case window?
+  - Focus: run this only if earlier answers are suspicious or unresolved; search 4738 and 5136 records for the same modifying subject/session or `winlog.event_data.TargetSid`, then compare `winlog.event_data.TargetUserName`, `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeLDAPDisplayName`, and `winlog.event_data.AttributeValue`.
+  - Implication: Broaden scope when the same actor or target appears in additional delegation writes across objects or controllers; keep it narrow when changes stay confined to one exact target and resolved maintenance path. !{investigate{"description":"","label":"Delegation-sensitive changes by this actor","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4738","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+
+- Escalate when a non-routine actor/session adds krbtgt delegation, supporting directory changes show setup, the value remains, or same-actor/target scope expands; close only when the modified account, krbtgt value, actor/session, source/authentication context, surrounding changes, rollback, and scope all align with one tightly controlled authorized workflow; preserve raw 4738, authentication, and directory-change evidence and escalate when findings stay mixed or incomplete.
 
 
 *False positive analysis*
 
 
-- Routine administrative tasks involving legitimate changes to the msDS-AllowedToDelegateTo attribute for service accounts may trigger alerts. Review the context of the change and verify with the IT team if it aligns with scheduled maintenance or updates.
-- Automated scripts or tools used for Active Directory management might modify delegation settings as part of their operations. Identify these scripts and exclude their activity from triggering alerts by creating exceptions based on the script's signature or the account used.
-- Changes made by trusted third-party applications that require delegation for functionality can be mistaken for malicious activity. Document these applications and adjust the detection rule to exclude their known and expected behavior.
-- Regular audits or compliance checks that involve modifications to delegation settings should be accounted for. Coordinate with audit teams to schedule these activities and temporarily adjust monitoring rules to prevent false positives during these periods.
+- Authorized security validation or emergency delegation repair can trigger this rule only when krbtgt delegation is the explicit planned action. Confirm the target (`winlog.event_data.TargetSid` plus `winlog.event_data.AllowedToDelegateTo`), actor/session (`winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectLogonId`, and recovered authentication context), controller, and surrounding attribute evidence all align. If change records are unavailable, telemetry-only closure must still bind one exact workflow with no contradictions; prior benign recurrence strengthens confidence but is not required.
+- Do not close generic service onboarding, migration, or constrained-delegation cutover as benign unless outside confirmation explicitly names krbtgt delegation and telemetry matches that exact target, actor, session, and controller path. A normal service-delegation explanation that does not account for the krbtgt value is incomplete.
+- Before creating an exception, validate that the same `winlog.event_data.SubjectUserSid`, `winlog.event_data.TargetSid`, exact `winlog.event_data.AllowedToDelegateTo`, `winlog.computer_name`, and recovered session pattern identify the authorized workflow across prior benign cases or a tightly controlled test plan. Build the exception from that minimum confirmed pattern, and avoid exceptions on "krbtgt", event 4738, or "msDS-AllowedToDelegateTo" alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further unauthorized access or ticket requests using the KRBTGT account.
-- Revert any unauthorized changes to the msDS-AllowedToDelegateTo attribute for the KRBTGT account by restoring it to its previous state using a known good backup or manually resetting the attribute.
-- Reset the KRBTGT account password twice to invalidate any existing Kerberos tickets that may have been issued using the compromised delegation settings.
-- Conduct a thorough review of recent changes to user accounts and delegation settings in Active Directory to identify any other potential unauthorized modifications.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the compromise.
-- Implement enhanced monitoring for changes to critical accounts and attributes in Active Directory, focusing on the KRBTGT account and similar high-value targets.
-- Review and update access controls and delegation permissions to ensure that only authorized personnel have the ability to modify sensitive attributes like msDS-AllowedToDelegateTo.
+- If confirmed benign, document the actor, target account, krbtgt value, controller, recovered session context, and surrounding delegation-change pattern before reversing temporary containment. Create an exception only if that same pattern is stable across prior benign cases.
+- If suspicious but unconfirmed, first export the alert, raw 4738 record, matching authentication events, and surrounding 4738 or 5136 records. Preserve the modified account, krbtgt value, actor/session, source/auth context, and rollback evidence before reversible containment such as heightened monitoring or temporary delegation-administration restrictions.
+- If confirmed malicious, preserve the same identity, session, and directory-change evidence first, then restrict or disable the modifying account. Restrict the modified target only when it was intentionally backdoored or used for follow-on Kerberos abuse. Contain the recovered source host when session evidence identifies one, or hand off the preserved evidence set to Active Directory or incident response.
+- After containment, review recent 4738 and 5136 records for the same actor, target, and controller before cleanup. Remove the unauthorized krbtgt value from the `msDS-AllowedToDelegateTo` attribute, roll back related delegation-prerequisite changes identified in the same change set, and verify clean replication across domain controllers.
+- If ticket abuse or broader Active Directory compromise is confirmed, activate the domain-compromise plan, including the required double reset of krbtgt after scoping and coordination with directory owners.
+- Post-incident hardening: restrict delegation administration and SeEnableDelegationPrivilege to dedicated tier-0 identities, keep Audit User Account Management plus supporting 5136, 4624, and 4648 visibility on domain controllers, and document any recurring benign validation pattern for future triage.
+
 
 ==== Setup
 
@@ -101,19 +114,8 @@ In Active Directory, the KRBTGT account is crucial for Kerberos ticket granting.
 *Setup*
 
 
-The 'Audit User Account Management' logging policy must be configured for (Success, Failure).
-Steps to implement the logging policy with Advanced Audit Configuration:
-
-```
-Computer Configuration >
-Policies >
-Windows Settings >
-Security Settings >
-Advanced Audit Policies Configuration >
-Audit Policies >
-Account Management >
-Audit User Account Management (Success,Failure)
-```
+Audit User Account Management must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-user-account-management
 
 
 ==== Rule query
diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-admission-webhook-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-admission-webhook-created-or-modified.asciidoc
new file mode 100644
index 0000000000..91e7835c91
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-admission-webhook-created-or-modified.asciidoc
@@ -0,0 +1,141 @@
+[[kubernetes-admission-webhook-created-or-modified]]
+=== Kubernetes Admission Webhook Created or Modified
+
+Detects creation, modification, or deletion of Kubernetes MutatingWebhookConfigurations or ValidatingWebhookConfigurations by non-system identities. Admission webhooks intercept every API request matching their rules before persistence, giving an attacker powerful capabilities: injecting malicious sidecars into every new pod via a mutating webhook, blocking security tooling deployments via a validating webhook, or silently exfiltrating pod specifications to an external server. Webhook manipulation is a stealthy persistence and defense evasion technique because the webhook configuration itself looks benign in kubectl output while actively modifying or intercepting all matching Kubernetes API traffic.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes Admission Webhook Created or Modified*
+
+
+Admission webhooks can mutate or validate resources before they are persisted. A malicious webhook can inject sidecars,
+alter securityContext, block defensive workloads, or exfiltrate pod specs. This rule alerts on allowed changes to
+MutatingWebhookConfiguration and ValidatingWebhookConfiguration objects by identities outside common system patterns.
+
+
+*Possible investigation steps*
+
+
+- Confirm the webhook resource and operation:
+  - kubernetes.audit.objectRef.resource and kubernetes.audit.verb
+  - kubernetes.audit.objectRef.name (the webhook configuration name)
+- Attribute the actor and access path:
+  - user.name (human vs service account vs node identity)
+  - source.ip and user_agent.original
+  - In cloud-managed clusters, map the identity to IAM/Entra principal data present in kubernetes.audit.user.extra.*.
+- Extract the webhook destination and review for external exfiltration:
+  - kubernetes.audit.requestObject.webhooks.clientConfig.url (suspicious when pointing to the public internet)
+  - kubernetes.audit.requestObject.webhooks.clientConfig.service.* (in-cluster service; still validate namespace/name)
+- Review impact-driving webhook settings:
+  - failurePolicy (e.g., Ignore can make malicious webhooks stealthier by avoiding obvious outages)
+  - namespaceSelector / objectSelector targeting (e.g., excluding kube-system while targeting everything else)
+  - rules.operations and rules.resources (e.g., CREATE pods is consistent with broad sidecar injection)
+  - sideEffects, timeoutSeconds, matchPolicy, reinvocationPolicy
+- Scope blast radius and follow-on activity:
+  - Hunt for pods created/updated after the webhook change that include unexpected containers, initContainers, env vars,
+    volume mounts, or securityContext changes.
+  - Check for concurrent RBAC changes, token creation, or secret access from the same identity and source IP.
+
+
+*False positive analysis*
+
+
+- GitOps upgrades or controller installs can legitimately change admission webhooks. Validate the change against:
+  - approved Helm/Git commits, change tickets, and expected controller namespaces
+  - known controller identities (cert-manager, Gatekeeper, Kyverno, service mesh controllers)
+
+
+*Response and remediation*
+
+
+- If unauthorized, revert or delete the webhook configuration from a known-good source (GitOps/Helm), then block the
+  actor identity and rotate any credentials it used.
+- If the webhook targeted pod creation, assume workload impact: identify affected namespaces/workloads, redeploy from
+  trusted manifests/images, and validate that new pods are no longer being mutated.
+- If an external clientConfig.url was used, treat it as potential data exfiltration and review egress/DNS logs for the
+  destination around the alert window.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+kubernetes.audit.objectRef.resource:("mutatingwebhookconfigurations" or "validatingwebhookconfigurations") and
+kubernetes.audit.verb:("create" or "update" or "patch" or "delete") and
+kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and 
+user.name:(* and not 
+  (system\:kube-controller-manager or
+  system\:kube-scheduler or
+  system\:serviceaccount\:kube-system\:* or
+  eks\:* or aksService or masterclient or nodeclient or
+  system\:serviceaccount\:gke-managed-system\:* or
+  system\:serviceaccount\:cert-manager\:* or
+  system\:serviceaccount\:gatekeeper-system\:* or
+  system\:serviceaccount\:kyverno\:* or
+  system\:serviceaccount\:*\:*-operator)
+) and
+kubernetes.audit.objectRef.name:(* and not (pod-identity-webhook or vpc-resource-mutating-webhook or eks-* or gke-*))
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Event Triggered Execution
+** ID: T1546
+** Reference URL: https://attack.mitre.org/techniques/T1546/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc
new file mode 100644
index 0000000000..6fd6c19375
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc
@@ -0,0 +1,176 @@
+[[kubernetes-and-cloud-credential-path-access-via-process-arguments]]
+=== Kubernetes and Cloud Credential Path Access via Process Arguments
+
+Flags Linux process executions whose arguments reference high-value Kubernetes service-account material, kubeconfig or node PKI paths, or common cloud and SSH credential files, when invoked via typical file-reading utilities or from ephemeral directories. Useful for spotting in-cluster and hybrid credential theft early.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* auditbeat-*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1552/
+* https://kubernetes.io/docs/concepts/security/service-accounts/
+
+*Tags*: 
+
+* Data Source: Auditd Manager
+* Data Source: Elastic Defend
+* Domain: Endpoint
+* Domain: Kubernetes
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes and Cloud Credential Path Access via Process Arguments*
+
+
+Confirm whether the process user and parent chain are expected to read the matched path (for example a CI job,
+bootstrap script, or kubelet). Reconstruct the full command line and check for piping, encoding, or exfiltration
+patterns immediately after the read.
+
+
+*Possible investigation steps*
+
+
+- Map the workload or login session to an identity; prioritize events from nodes, jump hosts, or pods with mounted
+  service account tokens.
+- Correlate with file, network, and Kubernetes audit telemetry for secret reads, token minting, or API calls using
+  harvested material.
+
+
+*Response and remediation*
+
+
+- Rotate affected service account tokens, kubeconfigs, and cloud keys when access was unauthorized; review RBAC and
+  secret mount policy for the workload.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Requires **Elastic Defend** and/or **Auditd Manager** process telemetry (`logs-endpoint.events.process*`,
+`logs-auditd_manager.auditd-*`, `auditbeat-*`) with command-line argument capture for exec events.
+
+
+*Elastic Defend*
+
+Install the Elastic Defend integration via Fleet on Linux hosts and use a policy that collects process events with
+arguments.
+
+
+*Auditd Manager*
+
+Deploy Auditd Manager and ensure execve (or equivalent process) auditing is enabled so `process.args` and
+`process.executable` populate for monitored binaries.
+
+See https://docs.elastic.co/integrations/auditd_manager
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+host.os.type:linux and event.category:process and event.action:(exec or executed) and 
+(
+  process.name:(
+    busybox or cat or head or tail or more or less or sed or awk or 
+    find or grep or ls or whereis or cp or mv or ln or
+    curl or wget or scp or rsync or tar or zip or gzip or
+    base64 or xxd or od or dd or tee or strings or xargs or jq or yq or
+    openssl or ssh or sftp or nc or ncat or netcat or socat or
+    python* or perl* or ruby* or node or php* or lua* or .*
+  ) or
+  process.args:(
+    cat or head or tail or more or less or sed or awk or 
+    find or grep or cp or mv or curl or wget or base64 or 
+    tar or scp or dd or strings or xargs
+  ) or
+  process.executable:(/tmp/* or /var/tmp/* or /dev/shm/* or /home/* or /run/user/*)
+) and process.args:(
+  "/var/run/secrets/kubernetes.io/serviceaccount/token" or
+  "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt" or
+  "/var/run/secrets/eks.amazonaws.com/serviceaccount/token" or
+  "/var/run/secrets/azure/tokens/azure-identity-token" or
+  "/var/run/secrets/tokens/azure-identity-token" or
+  "/var/lib/kubelet/kubeconfig" or
+  "/etc/kubernetes/admin.conf" or
+  "/etc/kubernetes/pki/ca.key" or
+  "/etc/kubernetes/pki/apiserver-kubelet-client.key" or
+  "/var/lib/kubelet/pki/kubelet-client-current.pem" or
+  "/etc/rancher/k3s/k3s.yaml" or
+  "/etc/shadow" or
+  */.ssh/id_rsa or
+  */root/.ssh/id_ed25519 or
+  */.ssh/id_ecdsa or
+  */.aws/credentials or
+  */.aws/cli/cache/*.json or
+  */.aws/sso/cache/*.json or
+  */.azure/accessTokens.json or
+  */.azure/azureProfile.json or
+  */.azure/msal_token_cache.json or
+  */.config/gcloud/application_default_credentials.json or
+  */.config/gcloud/credentials.db or
+  */.config/gcloud/access_tokens.db or
+  */.config/gcloud/legacy_credentials or
+  */.kube/config or
+  */.docker/config.json
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Unsecured Credentials
+** ID: T1552
+** Reference URL: https://attack.mitre.org/techniques/T1552/
+* Sub-technique:
+** Name: Credentials In Files
+** ID: T1552.001
+** Reference URL: https://attack.mitre.org/techniques/T1552/001/
+* Technique:
+** Name: Steal Application Access Token
+** ID: T1528
+** Reference URL: https://attack.mitre.org/techniques/T1528/
diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-api-request-impersonating-privileged-identity.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-api-request-impersonating-privileged-identity.asciidoc
new file mode 100644
index 0000000000..8099d0f1b4
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-api-request-impersonating-privileged-identity.asciidoc
@@ -0,0 +1,111 @@
+[[kubernetes-api-request-impersonating-privileged-identity]]
+=== Kubernetes API Request Impersonating Privileged Identity
+
+Detects Kubernetes API requests where a user is impersonating a privileged cluster identity such as system:kube-controller-manager, system:admin, system:anonymous, or a member of the system:masters group. These identities have broad cluster-wide permissions including unrestricted access to all secrets, the ability to create tokens for any service account, schedule pods on any node, and modify RBAC policies. An attacker impersonating system:masters gains full cluster-admin equivalent access, while impersonating system:kube-controller-manager grants access to every secret in every namespace and the ability to mint service account tokens for lateral movement.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes API Request Impersonating Privileged Identity*
+
+
+Compare the real actor (user.name, groups, source.ip, user_agent.original) with impersonated
+fields (kubernetes.audit.impersonatedUser.username, kubernetes.audit.impersonatedUser.groups). Confirm whether
+impersonation is authorized for that principal and target identity.
+
+
+*Possible investigation steps*
+
+
+- Review kubernetes.audit.requestURI, kubernetes.audit.verb, and kubernetes.audit.objectRef for the scope of the
+  operation performed while impersonating.
+- Determine whether the real user or service account should have impersonate rights against the impersonated user
+  or group; inspect RBAC impersonate verb bindings and any recent changes.
+- Correlate with adjacent audit activity (secrets, tokens, RBAC writes, CSR approval) from the same source identity.
+- Hunt for repeated impersonation across namespaces or rapid pivoting after the event.
+
+
+*Response and remediation*
+
+
+- Revoke or tighten impersonate permissions for unexpected identities; rotate credentials for any account that may
+  have abused impersonation.
+- If unauthorized, treat as cluster-wide credential risk: review secrets exposure, issued tokens, and RBAC drift;
+  engage incident response per policy.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:kubernetes.audit_logs and 
+kubernetes.audit.impersonatedUser.username:(* and not ("eks-event-service:event-controller" or eks\:*)) and 
+kubernetes.audit.annotations.authorization_k8s_io/decision:allow and 
+kubernetes.audit.verb:(create or delete or get or list or patch or update) and 
+(kubernetes.audit.impersonatedUser.username:(admin or cluster-admin or kubernetes-admin or "system:admin" or "system:anonymous" or "system:apiserver" or "system:kube-controller-manager" or "system:kube-proxy" or "system:kube-scheduler" or "system:volume-scheduler" or system\:node\:* or system\:serviceaccount\:kube-system\:*) or kubernetes.audit.impersonatedUser.groups:(cluster-admin or "system:cluster-admins" or "system:masters")) and 
+not user.name:(acsService or aksService or masterclient or nodeclient or "system:kube-controller-manager" or "system:kube-scheduler" or arn\:aws\:iam\:*\:role/aws-service-role* or arn\:aws\:sts\:*\:assumed-role/AWSServiceRoleForAmazonEKS* or arn\:aws\:sts\:*\:assumed-role/AWSServiceRoleForAmazonEKSNodegroup* or eks\:* or system\:node\:* or system\:serviceaccount\:kube-system\:*)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Access Token Manipulation
+** ID: T1134
+** Reference URL: https://attack.mitre.org/techniques/T1134/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Access Token Manipulation
+** ID: T1134
+** Reference URL: https://attack.mitre.org/techniques/T1134/
diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-api-server-proxying-request-to-kubelet.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-api-server-proxying-request-to-kubelet.asciidoc
new file mode 100644
index 0000000000..1ece9c88b2
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-api-server-proxying-request-to-kubelet.asciidoc
@@ -0,0 +1,148 @@
+[[kubernetes-api-server-proxying-request-to-kubelet]]
+=== Kubernetes API Server Proxying Request to Kubelet
+
+Detects non-system identities using the Kubernetes nodes/proxy API to proxy requests through the API server directly to a node's Kubelet. The nodes/proxy subresource allows any principal with this RBAC permission to reach the Kubelet API on any worker node without needing direct network access or Kubelet TLS certificates. Through this proxy path, an attacker can list all pod specifications including environment variable secrets, read Kubelet configuration and PKI material, retrieve container logs, and access running pod metadata across all workloads on the target node. Monitoring and health check endpoints such as /metrics, /healthz, and /stats are excluded to reduce noise from legitimate observability tooling.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://kubernetes.io/docs/concepts/cluster-administration/proxies/
+* https://attack.mitre.org/techniques/T1552/007/
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Tactic: Lateral Movement
+* Tactic: Discovery
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes API Server Proxying Request to Kubelet*
+
+
+Review the user.name, source.ip, and user_agent.original fields to determine who initiated the proxy request and from
+where. Examine kubernetes.audit.requestURI to identify which Kubelet endpoint was proxied — the path after /proxy/
+maps directly to the Kubelet API path the attacker accessed.
+
+
+*Possible investigation steps*
+
+
+- Check the proxied Kubelet path in requestURI to determine attacker intent:
+  - /proxy/pods — pod spec enumeration including environment variable secrets
+  - /proxy/exec or /proxy/run — command execution inside containers on that node
+  - /proxy/configz — Kubelet configuration and authentication settings
+  - /proxy/runningpods — active workload enumeration
+  - /proxy/containerLogs — log harvesting for leaked credentials
+- Identify how the principal obtained nodes/proxy permission by reviewing RBAC bindings
+- Check if a ServiceAccount token was created shortly before via the TokenRequest API - this 
+  indicates the attacker minted a token specifically for this access.
+- Review whether the same principal accessed multiple nodes via proxy in a short window, which
+  indicates systematic lateral movement across the cluster.
+
+
+*False positive analysis*
+
+
+- Prometheus, Datadog, and other monitoring agents scrape /metrics and /stats via nodes/proxy.
+  These endpoints are excluded by default. If additional monitoring paths generate noise, add
+  them to the requestURI exclusion.
+- Cluster administration tools that inspect node health via the proxy API can match. Correlate
+  with change management windows and verify the source identity.
+
+
+*Response and remediation*
+
+
+- Immediately review the RBAC role granting nodes/proxy permission and determine if the binding
+  is authorized. Remove unauthorized bindings.
+- If /proxy/pods was accessed, assume all environment variable secrets on that node are compromised.
+  Rotate affected credentials, API keys, and database passwords.
+- If /proxy/exec or /proxy/run was accessed, treat the target node as compromised. Isolate the node,
+  review running containers for unauthorized modifications, and check for persistence mechanisms.
+- Audit all ClusterRoles for nodes/proxy permission — this is a powerful privilege that should be
+  restricted to infrastructure automation only, never granted to application service accounts.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+kubernetes.audit.objectRef.subresource:"proxy" and
+kubernetes.audit.objectRef.resource:"nodes" and
+not kubernetes.audit.requestURI:(*metrics* or *healthz* or *stats/summary* or *elastic-agent* or *configz*) and
+not user.name:(
+  system\:kube-controller-manager or
+  system\:kube-scheduler or
+  system\:serviceaccount\:kube-system\:* or
+  system\:node\:* or
+  eks\:* or aksService
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Escape to Host
+** ID: T1611
+** Reference URL: https://attack.mitre.org/techniques/T1611/
+* Tactic:
+** Name: Lateral Movement
+** ID: TA0008
+** Reference URL: https://attack.mitre.org/tactics/TA0008/
+* Technique:
+** Name: Use Alternate Authentication Material
+** ID: T1550
+** Reference URL: https://attack.mitre.org/techniques/T1550/
+* Sub-technique:
+** Name: Application Access Token
+** ID: T1550.001
+** Reference URL: https://attack.mitre.org/techniques/T1550/001/
+* 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/rule-details/kubernetes-client-certificate-signing-request-created-or-approved.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-client-certificate-signing-request-created-or-approved.asciidoc
new file mode 100644
index 0000000000..ad386498be
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-client-certificate-signing-request-created-or-approved.asciidoc
@@ -0,0 +1,146 @@
+[[kubernetes-client-certificate-signing-request-created-or-approved]]
+=== Kubernetes Client Certificate Signing Request Created or Approved
+
+Detects creation or approval of a Kubernetes CertificateSigningRequest (CSR) by a non-system identity. Attackers who have gained cluster access can submit a CSR with a privileged Common Name such as system:kube-controller-manager or system:masters, then approve it themselves to obtain a long-lived client certificate. Unlike service account tokens which expire in hours, client certificates persist until they expire or the cluster CA is rotated, providing durable access that survives pod termination, token revocation, and RBAC changes. On non-EKS clusters, the signed certificate allows the attacker to authenticate as the privileged identity from anywhere without needing cluster network access, making it one of the most persistent backdoor mechanisms available in Kubernetes.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/
+* https://attack.mitre.org/techniques/T1098/
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Privilege Escalation
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes Client Certificate Signing Request Created or Approved*
+
+
+Identify the actor (`user.name`, groups), client (`user_agent.original`), and `source.ip`. Confirm whether the
+principal is expected to create or approve CSRs. Review `kubernetes.audit.requestURI` and, when audit level captures
+request bodies, the CSR `spec` (requested signer, usages, and requested identity / Common Name).
+
+
+*Extracting the Certificate Common Name*
+
+
+For create events, "kubernetes.audit.requestObject.spec.request" holds the base64-encoded PEM certificate signing request.
+Decode that value to PEM, then inspect the CSR subject (for example with OpenSSL’s CSR subject view) to read the
+requested Common Name (CN). 
+
+Known base64 substrings that often appear inside the encoded request for high-risk identities:
+
+- `c3lzdGVtOm1hc3Rlcn` — `system:masters`
+- `c3lzdGVtOmt1YmUtY29udHJvbGxlci1tYW5hZ2Vy` — `system:kube-controller-manager`
+- `c3lzdGVtOmFkbWlu` — `system:admin`
+
+Priority CNs that usually indicate privilege escalation intent:
+
+- `system:masters` (cluster-admin group)
+- `system:kube-controller-manager` (broad control-plane–style access, including secrets and token minting)
+- `system:kube-scheduler` (scheduling across the cluster)
+- `system:kube-proxy` (node/network–adjacent access)
+- Any CN that matches an existing ClusterRoleBinding subject name
+
+
+*Possible investigation steps*
+
+
+- Compare the CSR name and extracted CN against approved PKI or bootstrap processes.
+- Determine whether the same identity both created and approved or patched the CSR in a short window, which matches
+  self-approval abuse.
+- Review `kubernetes.audit.objectRef` and subsequent authentication or API activity from unusual networks.
+- Correlate with RBAC changes, secret access, or TokenRequest activity that preceded CSR activity.
+
+
+*Response and remediation*
+
+
+- If malicious, deny further approval, delete or deny the CSR per incident policy, revoke or rotate cluster signing
+  trust if the CA or signer was abused, and invalidate issued credentials.
+- Remove excessive RBAC that allows `certificatesigningrequests` create/update/patch or approval for untrusted
+  identities; enforce signer restrictions and approved issuers where supported.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"kubernetes.audit_logs" and 
+kubernetes.audit.objectRef.resource:"certificatesigningrequests" and
+kubernetes.audit.verb:("create" or "update" or "patch") and
+kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and
+not user.name:(
+  system\:kube-controller-manager or
+  system\:kube-scheduler or
+  system\:node\:* or
+  system\:serviceaccount\:kube-system\:* or
+  eks\:* or aksService
+)
+
+----------------------------------
+
+*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 Container Cluster Roles
+** ID: T1098.006
+** Reference URL: https://attack.mitre.org/techniques/T1098/006/
+* 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/
diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-coredns-or-kube-dns-configuration-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-coredns-or-kube-dns-configuration-modified.asciidoc
new file mode 100644
index 0000000000..7296d3e370
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-coredns-or-kube-dns-configuration-modified.asciidoc
@@ -0,0 +1,110 @@
+[[kubernetes-coredns-or-kube-dns-configuration-modified]]
+=== Kubernetes CoreDNS or Kube-DNS Configuration Modified
+
+Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace. These ConfigMaps control cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service DNS names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server, database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every pod in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS configuration changes are rare in normal operations and any unexpected modification should be investigated immediately.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/
+* https://coredns.io/plugins/rewrite/
+* https://attack.mitre.org/techniques/T1565/001/
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* Use Case: Threat Detection
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes CoreDNS or Kube-DNS Configuration Modified*
+
+
+Identify who performed the change (user.name, groups), from where (source.ip), and which ConfigMap was modified.
+If request/response capture is available, review the changed Corefile content for upstream redirection, wildcard
+rewrites, or unexpected forward/proxy targets.
+
+
+*Possible investigation steps*
+
+
+- Confirm the actor is authorized to modify kube-system DNS configuration and whether the change aligns with a change window.
+- Review the ConfigMap diff for added rewrite rules, hosts entries, or forwarding to external or unexpected internal IPs.
+- Correlate with follow-on suspicious activity such as secret reads, token minting, or RBAC modifications.
+- Check for cluster-wide symptoms: service connection failures, TLS errors, or sudden endpoint changes across namespaces.
+
+
+*Response and remediation*
+
+
+- Revert the ConfigMap to a known-good version and restart DNS pods if required by your deployment.
+- Restrict RBAC permissions that allow update/patch/delete on kube-system DNS ConfigMaps and investigate the source identity.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"kubernetes.audit_logs" and 
+kubernetes.audit.objectRef.resource:"configmaps" and
+kubernetes.audit.objectRef.name:("coredns" or "kube-dns" or "coredns-custom") and
+kubernetes.audit.objectRef.namespace:"kube-system" and
+kubernetes.audit.verb:("update" or "patch" or "delete") and
+kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and 
+not user.name:(
+  system\:serviceaccount\:kube-system\:coredns or
+  system\:serviceaccount\:kube-system\:kube-dns or
+  system\:node\:* or
+  eks\:* or aksService or acsService
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Data Manipulation
+** ID: T1565
+** Reference URL: https://attack.mitre.org/techniques/T1565/
+* Sub-technique:
+** Name: Stored Data Manipulation
+** ID: T1565.001
+** Reference URL: https://attack.mitre.org/techniques/T1565/001/
diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-ephemeral-container-added-to-pod.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-ephemeral-container-added-to-pod.asciidoc
new file mode 100644
index 0000000000..eece440681
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-ephemeral-container-added-to-pod.asciidoc
@@ -0,0 +1,112 @@
+[[kubernetes-ephemeral-container-added-to-pod]]
+=== Kubernetes Ephemeral Container Added to Pod
+
+Detects allowed updates to the pods/ephemeralcontainers subresource by a non-system identity. Ephemeral containers are commonly used for debugging (kubectl debug) but can also be abused to inject tooling into a running pod, access mounted secrets, and execute commands in the target pod context. Attackers with sufficient RBAC may use ephemeral containers to escalate privileges, move laterally, or establish persistence without deploying a new workload.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: Kubernetes
+* 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 Kubernetes Ephemeral Container Added to Pod*
+
+
+Ephemeral containers allow adding a container to an existing pod for troubleshooting. When abused, they can be used to
+gain interactive access to a workload, read sensitive files, and run tools that were not present in the original image.
+
+
+*Possible investigation steps*
+
+
+- Review the actor (user.name, groups), source.ip, and user_agent.original and confirm the identity is authorized to use ephemeral containers.
+- Inspect kubernetes.audit.objectRef (namespace, name) to identify the targeted pod and workload owner.
+- If request bodies are captured, review the ephemeral container image, command, and securityContext for privilege indicators.
+- Correlate with follow-on audit activity such as pod exec, secret reads, TokenRequest, or RBAC modifications.
+
+
+*Response and remediation*
+
+
+- If unauthorized, remove excessive RBAC that grants update/patch on pods/ephemeralcontainers and rotate exposed credentials.
+- Quarantine or redeploy impacted workloads and hunt for additional compromised pods or identities.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"kubernetes.audit_logs" and 
+kubernetes.audit.objectRef.resource:"pods" and
+kubernetes.audit.objectRef.subresource:"ephemeralcontainers" and
+kubernetes.audit.verb:("update" or "patch") and
+kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and
+not user.name:(
+  system\:node\:* or
+  system\:serviceaccount\:kube-system\:*
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Escape to Host
+** ID: T1611
+** Reference URL: https://attack.mitre.org/techniques/T1611/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Container Administration Command
+** ID: T1609
+** Reference URL: https://attack.mitre.org/techniques/T1609/
diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-multi-resource-discovery.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-multi-resource-discovery.asciidoc
index 4df039cbe2..60143577bb 100644
--- a/docs/detections/prebuilt-rules/rule-details/kubernetes-multi-resource-discovery.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-multi-resource-discovery.asciidoc
@@ -30,7 +30,7 @@ Adversaries who land credentials in a cluster—or abuse an over-privileged toke
 * Tactic: Discovery
 * Resources: Investigation Guide
 
-*Version*: 1
+*Version*: 2
 
 *Rule authors*: 
 
@@ -96,15 +96,16 @@ from logs-kubernetes.audit_logs-* metadata _id, _index, _version
     and kubernetes.audit.objectRef.resource in ("namespaces", "nodes", "pods", "roles", "configmaps", "serviceaccounts", "clusterroles", "clusterrolebindings", "rolebindings")
     and source.ip is not null and user.name IS NOT NULL
     and not to_string(source.ip) in ("127.0.0.1", "::1")
-    and not user.name rlike """(system:serviceaccount:kube-system:|eks:|system:kube-|arn:aws:sts::.*:assumed-role/AWSServiceRoleForAmazonEKS/|system:serviceaccount:kube-system:azure|system:node:aks-default|aksService).*"""
+    and not user.name rlike """(system:serviceaccount:kube-system:|eks:|system:kube-|arn:aws:sts::.*:assumed-role/AWSServiceRoleForAmazonEKS/|system:serviceaccount:kube-system:azure|system:node:aks-default|aksService).*""" 
+    and not kubernetes.audit.user.username in ("system:serviceaccount:flux-system:kustomize-controller", "system:serviceaccount:flux-system:helm-controller", "system:serviceaccount:flux-system:source-controller", "system:serviceaccount:security:trivy-operator")
 | stats
     Esql.unique_resources = count_distinct(kubernetes.audit.objectRef.resource),
     Esql.enumerated_resources = values(kubernetes.audit.objectRef.resource),
     Esql.enumerated_namespaces = values(kubernetes.audit.objectRef.namespace),
     Esql.decisions = values(`kubernetes.audit.annotations.authorization_k8s_io/decision`)
-  by user.name, source.ip, user_agent.original, Esql.time_interval
+  by user.name, kubernetes.audit.user.username, source.ip, user_agent.original, Esql.time_interval
 | where Esql.unique_resources >= 3
-| keep Esql.*, user.name, source.ip, user_agent.original
+| keep Esql.*, kubernetes.audit.user.username, user.name, source.ip, user_agent.original
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-rapid-secret-get-activity-against-multiple-objects.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-rapid-secret-get-activity-against-multiple-objects.asciidoc
index b6be1b1c8c..74b0941a78 100644
--- a/docs/detections/prebuilt-rules/rule-details/kubernetes-rapid-secret-get-activity-against-multiple-objects.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-rapid-secret-get-activity-against-multiple-objects.asciidoc
@@ -29,7 +29,7 @@ This rule detects an unusual volume of Kubernetes API get requests against multi
 * Tactic: Credential Access
 * Resources: Investigation Guide
 
-*Version*: 1
+*Version*: 2
 
 *Rule authors*: 
 
@@ -85,15 +85,16 @@ from logs-kubernetes.audit_logs-* metadata _id, _index, _version
     and source.ip is not null and user.name is not null 
     and not to_string(source.ip) in ("127.0.0.1", "::1") and 
     not user.name in ("system:kube-controller-manager", "system:kube-scheduler") and 
-    not kubernetes.audit.objectRef.name like "sh.helm.release.*"
+    not kubernetes.audit.objectRef.name like "sh.helm.release.*" and 
+    not kubernetes.audit.user.username in ("system:serviceaccount:flux-system:kustomize-controller", "system:serviceaccount:flux-system:helm-controller", "system:serviceaccount:flux-system:source-controller", "system:serviceaccount:security:trivy-operator")
 | stats
     Esql.unique_credentials = count_distinct(kubernetes.audit.objectRef.name),
     Esql.secrets_names = values(kubernetes.audit.objectRef.name),
     Esql.namespaces = values(kubernetes.audit.objectRef.namespace),
     Esql.outcome = values(`kubernetes.audit.annotations.authorization_k8s_io/decision`)
-  by user.name, source.ip, user_agent.original
+  by user.name, kubernetes.audit.user.username, source.ip, user_agent.original
 | where Esql.unique_credentials >= 3
-| KEEP user.name, source.ip, user_agent.original, Esql.*
+| KEEP user.name, kubernetes.audit.user.username, source.ip, user_agent.original, Esql.*
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-secret-get-or-list-from-node-or-pod-service-account.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-secret-get-or-list-from-node-or-pod-service-account.asciidoc
index 3e909e2cf6..fff3e56f0c 100644
--- a/docs/detections/prebuilt-rules/rule-details/kubernetes-secret-get-or-list-from-node-or-pod-service-account.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-secret-get-or-list-from-node-or-pod-service-account.asciidoc
@@ -32,7 +32,7 @@ Kubernetes audit identities for kubelet (`system:node:*`) and workloads (`system
 * Tactic: Credential Access
 * Resources: Investigation Guide
 
-*Version*: 1
+*Version*: 2
 
 *Rule authors*: 
 
@@ -93,7 +93,18 @@ high-value secret names, and clients that do not match the workload’s normal u
 data_stream.dataset:"kubernetes.audit_logs" and
 event.action:(get or list) and
 kubernetes.audit.objectRef.resource:"secrets" and
-user.name:(system\:serviceaccount\:* or system\:node\:*) and source.ip:*
+user.name:(system\:serviceaccount\:* or system\:node\:*) and source.ip:* and 
+not kubernetes.audit.user.groups:(
+  "system:serviceaccounts:flux-system"
+  or "system:serviceaccounts:kyverno"
+  or "system:serviceaccounts:ibm-csi"
+  or "system:serviceaccounts:harvester-system"
+  or "system:serviceaccounts:cattle-system"
+  or "system:serviceaccounts:cattle-monitoring-system"
+  or system\:serviceaccounts\:cluster-fleet-local-local-*
+  or "system:serviceaccounts:rabbitmq-system"
+  or "system:serviceaccounts:cattle-fleet-system"
+)
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-secrets-list-across-cluster-or-sensitive-namespaces.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-secrets-list-across-cluster-or-sensitive-namespaces.asciidoc
index 52a793147e..3251109e28 100644
--- a/docs/detections/prebuilt-rules/rule-details/kubernetes-secrets-list-across-cluster-or-sensitive-namespaces.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-secrets-list-across-cluster-or-sensitive-namespaces.asciidoc
@@ -32,7 +32,7 @@ Detects list operations on Kubernetes Secrets from a non-loopback client when th
 * Tactic: Discovery
 * Resources: Investigation Guide
 
-*Version*: 1
+*Version*: 2
 
 *Rule authors*: 
 
@@ -80,7 +80,8 @@ event.dataset:"kubernetes.audit_logs" and event.action:list and
 kubernetes.audit.objectRef.resource:secrets and 
 kubernetes.audit.requestURI :(/api/v1/secrets or /api/v1/secrets?limit* or /api/v1/namespaces/kube-system/secrets or /api/v1/namespaces/kube-system/secrets?limit* or /api/v1/namespaces/default/secrets or /api/v1/namespaces/default/secrets?limit*) and 
 source.ip:(* and not ("::1" or "127.0.0.1")) and 
-not user.name: (system\:kube-controller-manager or eks\:cloud-controller-manager or eks\:kms-storage-migrator)
+not user.name: (system\:kube-controller-manager or eks\:cloud-controller-manager or eks\:kms-storage-migrator) and 
+not kubernetes.audit.user.groups:"system:serviceaccounts:ibm-csi"
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc
new file mode 100644
index 0000000000..b38b219bcf
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc
@@ -0,0 +1,132 @@
+[[kubernetes-service-account-token-created-via-tokenrequest-api]]
+=== Kubernetes Service Account Token Created via TokenRequest API
+
+Detects the creation of a Kubernetes service account token through the TokenRequest API by a non-system identity. The TokenRequest API allows users and workloads to programmatically generate short-lived tokens for any service account they have create permissions on, without accessing the filesystem or the mounted projected token. Attackers who have gained initial access to a cluster can abuse this API to mint tokens for more privileged service accounts, pivot to cloud provider resources via IRSA/workload identity, or generate long-lived tokens that persist beyond pod termination. Unlike mounted service account tokens which are detectable through file access monitoring, tokens created via the TokenRequest API leave no filesystem footprint, they are only visible in Kubernetes audit logs as a create verb on the serviceaccounts/token subresource. This rule excludes legitimate system components such as the kubelet, kube-controller-manager, and cloud provider managed identities (EKS, AKS, GKE) that routinely create tokens for pod lifecycle management.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-kubernetes.audit_logs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-v1/
+* https://attack.mitre.org/techniques/T1552/007/
+
+*Tags*: 
+
+* Data Source: Kubernetes
+* Domain: 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 Kubernetes Service Account Token Created via TokenRequest API*
+
+
+This alert indicates a successful `create` against the `serviceaccounts/token` subresource (TokenRequest API), which
+issues a new service account token without a filesystem read. In EKS and other managed clusters, this can be abused to
+mint tokens for more privileged service accounts (including IRSA-linked ones) and pivot to cloud APIs.
+
+
+*What to review first*
+
+
+- Actor and origin:
+  - `user.name` / `kubernetes.audit.user.username`
+  - `source.ip` / `kubernetes.audit.sourceIPs`
+  - `user_agent.original` / `kubernetes.audit.userAgent`
+  - For cloud identity, review `kubernetes.audit.user.extra.*` (e.g., `arn`, `principalId`).
+- Targeted service account:
+  - `kubernetes.audit.objectRef.namespace` and `kubernetes.audit.objectRef.name`
+  - `kubernetes.audit.requestURI` (should resemble `/api/v1/namespaces/<ns>/serviceaccounts/<sa>/token`)
+- Token issuance hints:
+  - `kubernetes.audit.annotations.authentication_kubernetes_io/issued-credential-id` (token JTI/issued credential id)
+
+
+*Scoping*
+
+
+- Identify which Role/ClusterRoleBindings grant the actor `create` on `serviceaccounts/token` in the affected namespace.
+- Pivot on the same `user.name` and `source.ip` for follow-on secret reads, pod exec, RBAC changes, or cloud API calls.
+
+
+*Response and remediation*
+
+
+- If unauthorized, remove/revert the RBAC permission that allows TokenRequest (`serviceaccounts/token`) and rotate the
+  affected service account credentials where applicable.
+- For IRSA/workload identity cases, rotate/revoke the cloud role session pathways and review cloud audit logs for API
+  activity from the time window of the token mint.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"kubernetes.audit_logs" and 
+kubernetes.audit.verb:"create" and
+kubernetes.audit.objectRef.resource:"serviceaccounts" and
+kubernetes.audit.objectRef.subresource:"token" and
+user.name:(* and not 
+ (system\:kube-controller-manager or
+  system\:kube-scheduler or
+  system\:node\:* or
+  system\:serviceaccount\:kube-system\:* or
+  eks\:* or
+  aksService or
+  aks-service or
+  masterclient or
+  nodeclient or
+  system\:serviceaccount\:gke-managed-system\:* or
+  system\:serviceaccount\:gke-connect\:* or
+  system\:serviceaccount\:anthos-identity-service\:* or
+  system\:gke-controller-manager or
+  system\:serviceaccount\:tigera-operator\:* or
+  system\:serviceaccount\:calico-system\:*))
+
+----------------------------------
+
+*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/rule-details/kubernetes-static-pod-manifest-file-access.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-static-pod-manifest-file-access.asciidoc
new file mode 100644
index 0000000000..208d2628e0
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-static-pod-manifest-file-access.asciidoc
@@ -0,0 +1,152 @@
+[[kubernetes-static-pod-manifest-file-access]]
+=== Kubernetes Static Pod Manifest File Access
+
+Detects Linux process executions where shells, editors, interpreters, or file/stream utilities reference /etc/kubernetes/manifests in process arguments. That directory holds static pod manifests read by the kubelet; interaction via editors, downloaders, kubectl, redirection helpers (tee, dd), or scripting runtimes may indicate staging or tampering with manifests for persistence or privileged workload placement. Pairs with file-telemetry rules that flag direct manifest creation on container workloads.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* auditbeat-*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/
+* https://attack.mitre.org/techniques/T1053/007/
+
+*Tags*: 
+
+* Data Source: Auditd Manager
+* Data Source: Elastic Defend
+* Domain: Endpoint
+* Domain: Kubernetes
+* Domain: Container
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Privilege Escalation
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kubernetes Static Pod Manifest File Access*
+
+
+Review the full command line (process.args, process.command_line), user.id, user.name, process.parent, and whether the
+session was interactive. Confirm if the host is a Kubernetes node or admin jump host where manifest edits are expected.
+
+
+*Possible investigation steps*
+
+
+- Compare activity to change windows and identity baselines; prioritize events without matching change tickets.
+- Inspect subsequent process and file events on the same host for writes under /etc/kubernetes/manifests or kubelet
+  restarts.
+- Correlate with Kubernetes audit logs and node/agent telemetry for related compromise indicators.
+
+
+*Response and remediation*
+
+
+- If unauthorized, restore manifests from known-good sources, isolate the host, and review cluster integrity per incident
+  policy.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Requires **Elastic Defend** and/or **Auditd Manager** process telemetry (`logs-endpoint.events.process*`,
+`logs-auditd_manager.auditd-*`, `auditbeat-*`) with command-line argument capture for exec events.
+
+
+*Elastic Defend*
+
+Install the Elastic Defend integration via Fleet on Linux hosts and use a policy that collects process events with
+arguments.
+
+
+*Auditd Manager*
+
+Deploy Auditd Manager and ensure execve (or equivalent process) auditing is enabled so `process.args` and
+`process.executable` populate for monitored binaries.
+
+See https://docs.elastic.co/integrations/auditd_manager
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+host.os.type:linux and event.category:process and event.action:(exec or executed) and 
+process.name:(
+  bash or sh or dash or zsh or 
+  cat or cp or mv or touch or tee or dd or
+  sed or awk or 
+  curl or wget or scp or
+  vi or vim or nano or echo or
+  busybox or
+  python* or perl* or ruby* or node or lua* or
+  openssl or base64 or xxd or
+  .*) and 
+  process.args:(*/etc/kubernetes/manifests/* and not (/etc/kubernetes/manifests/etcd* or /etc/kubernetes/manifests/kube-apiserver* or /etc/kubernetes/manifests/kube-scheduler* or /etc/kubernetes/manifests/kube-controller-manager*))
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Scheduled Task/Job
+** ID: T1053
+** Reference URL: https://attack.mitre.org/techniques/T1053/
+* Sub-technique:
+** Name: Container Orchestration Job
+** ID: T1053.007
+** Reference URL: https://attack.mitre.org/techniques/T1053/007/
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Create or Modify System Process
+** ID: T1543
+** Reference URL: https://attack.mitre.org/techniques/T1543/
+* Sub-technique:
+** Name: Container Service
+** ID: T1543.005
+** Reference URL: https://attack.mitre.org/techniques/T1543/005/
diff --git a/docs/detections/prebuilt-rules/rule-details/lateral-movement-via-startup-folder.asciidoc b/docs/detections/prebuilt-rules/rule-details/lateral-movement-via-startup-folder.asciidoc
index 2be55576c5..d8775f2dfe 100644
--- a/docs/detections/prebuilt-rules/rule-details/lateral-movement-via-startup-folder.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/lateral-movement-via-startup-folder.asciidoc
@@ -42,7 +42,7 @@ Identifies suspicious file creations in the startup folder of a remote system. A
 * Data Source: SentinelOne
 * Resources: Investigation Guide
 
-*Version*: 314
+*Version*: 315
 
 *Rule authors*: 
 
@@ -58,46 +58,76 @@ Identifies suspicious file creations in the startup folder of a remote system. A
 *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 Lateral Movement via Startup Folder*
 
 
-The Windows Startup folder is a mechanism that allows programs to run automatically upon user logon or system reboot. Adversaries exploit this by placing malicious files in the Startup folder of remote systems, often accessed via RDP or SMB, to ensure persistence and facilitate lateral movement. The detection rule identifies suspicious file activities in these folders, focusing on processes like mstsc.exe, which may indicate unauthorized access and file creation, signaling potential lateral movement attempts.
-
 
 *Possible investigation steps*
 
 
-- Review the alert details to confirm the file creation or change event in the specified Startup folder paths, focusing on the file path patterns: "?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*" and "?:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*".
-- Check the process information associated with the event, particularly if the process name is "mstsc.exe" or if the process ID is 4, to determine if the activity is linked to remote access via RDP or SMB.
-- Investigate the origin of the remote connection by examining network logs or RDP session logs to identify the source IP address and user account involved in the connection.
-- Analyze the newly created or modified file in the Startup folder for malicious characteristics, such as unusual file names, unexpected file types, or known malware signatures, using antivirus or sandbox analysis tools.
-- Review user account activity and permissions to determine if the account associated with the process has been compromised or is being misused for unauthorized access.
-- Correlate this event with other security alerts or logs from data sources like Sysmon, Microsoft Defender XDR, or SentinelOne to identify any related suspicious activities or patterns indicating lateral movement attempts.
+- What remote Startup-folder write did the alert capture?
+  - Focus: `file.path`, `file.extension`, `process.name`, `process.pid`, and `process.executable`.
+  - Implication: escalate when a remote writer plants a scriptable or executable item, especially in ProgramData Startup; lower suspicion only when the Startup item, writer, user, and host identify one bounded deployment or support component.
+- What does the planted Startup item contain or point to?
+  - Focus: `file.name`, `file.size`, `file.Ext.header_bytes`, and `file.Ext.windows.zone_identifier`.
+  - Implication: escalate on shortcuts, scripts, archives, executables, renamed payloads, or content/header mismatches that could run at logon; lower suspicion when a bounded installer or support shortcut has content and provenance matching the same named tool.
+- Does writer and user context identify the same support or deployment component?
+  - Focus: `user.id`, `user.domain`, `process.command_line`, and `process.parent.name`.
+  - Hint: for PID 4 SMB writes, recover surrounding SMB connection events to identify `source.ip`; for "mstsc.exe" writes, validate the RDP drive-redirection source through Terminal Services or RDP session logs when available. Missing SMB/RDP telemetry is unresolved, not benign. !{investigate{"description":"","label":"SMB connection events on the host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"event.action","queryType":"phrase","value":"connection_accepted","valueType":"string"},{"excluded":false,"field":"destination.port","queryType":"phrase","value":"445","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the account, host, parent, or command line does not explain remote RDP/SMB Startup persistence; lower suspicion when command line, parent, and user-host pairing point to the same bounded component.
+- Did the same Startup directory show staging, renames, or cleanup?
+  - Focus: file events in the same Startup directory on `host.id`, especially `file.directory`, `file.path`, `file.name`, and `file.Ext.original.path`. !{investigate{"description":"","label":"File events in the same Startup directory","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.directory","queryType":"phrase","value":"{{file.directory}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: use the directory view to separate one bounded write from broader Startup-folder staging.
+  - Implication: escalate on multiple writes, renames, mixed payload types, or cleanup artifacts; a single stable artifact narrows scope but does not clear the alert until execution and workflow fit are resolved.
+- Has the Startup item executed on the host?
+  - Focus: process starts on `host.id` where `process.executable` matches the written `file.path`, then review `process.command_line` and `user.id`. !{investigate{"description":"","label":"Process events where the Startup item later executed","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Hint: for shortcuts or scripts, exact path matching may miss the launched target; inspect the artifact and search same-host process starts for the referenced interpreter or target path.
+  - Implication: escalate when the item or referenced target executes, especially under a different user than the writer; no execution yet lowers immediacy, but clears only when writer, artifact, and directory evidence already prove a benign tool.
+- If local evidence is suspicious or incomplete, are there related same-host alerts?
+  - Focus: related alerts for the same `host.id` involving remote services, credentials, execution, discovery, or persistence. !{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: related alerts broaden the case from one Startup write to an intrusion path; no related alerts or an unavailable pivot narrows scope only and cannot close contradictory artifact, writer, or execution evidence.
+- Escalate for remotely planted Startup persistence or later execution; close only when writer mechanism, path, artifact, directory, execution, and alert pivots bind to one bounded benign component without contradiction; preserve artifacts and escalate when evidence is mixed or incomplete.
 
 
 *False positive analysis*
 
 
-- Legitimate software installations or updates may create files in the Startup folder, triggering the rule. Users can manage this by maintaining a list of known software that typically modifies the Startup folder and creating exceptions for these processes.
-- System administrators using remote desktop tools like mstsc.exe for legitimate purposes might inadvertently trigger the rule. To handle this, users can exclude specific administrator accounts or known IP addresses from the detection rule.
-- Automated scripts or system management tools that deploy updates or configurations across multiple systems might cause false positives. Users should identify these tools and add them to an exclusion list to prevent unnecessary alerts.
-- Some enterprise applications may use the Startup folder for legitimate operations, especially during system boot or user logon. Users should document these applications and configure the rule to ignore file changes associated with them.
+- Software deployment, break-fix support, enterprise agents, or line-of-business applications can place bounded installers, shortcuts, support utilities, or stable per-user/all-users components in Startup through RDP or SMB. Confirm that `file.path`, `file.name`, `file.extension`, writer process or command line, `user.id`, `host.id`, directory view, and later direct or shortcut-target execution all identify the same bounded component, with no extra staging files or suspicious same-host alerts. Do not close on a role, ticket, or partial field match when current telemetry does not bind writer, artifact, and execution behavior together.
+- Build exceptions from the minimum confirmed workflow pattern: the specific `file.path`, writer `process.name` or `process.pid`, `user.id`, `host.id`, and bounded later-execution or quiet-directory evidence that distinguishes the benign case. Avoid exceptions on the Startup folder path alone, on "mstsc.exe" alone, or on PID 4 alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further lateral movement and potential spread of the threat.
-- Terminate any suspicious processes, particularly those related to mstsc.exe or any unauthorized processes with PID 4, to halt any ongoing malicious activities.
-- Remove any unauthorized files or scripts found in the Startup folder paths specified in the detection query to prevent them from executing on reboot or user logon.
-- 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 files or remnants.
-- Review and reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent 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 RDP and SMB activities, focusing on unusual file creation events in Startup folders, to improve detection of similar threats in the future.
+- If confirmed benign, reverse temporary containment and document the exact `file.path`, writer `process.name` or `process.pid`, `user.id`, `host.id`, and quiet-directory or later-execution evidence that established the bounded workflow. Create an exception only when that same evidence set distinguishes the benign workflow from remote Startup-folder abuse.
+- If suspicious but unconfirmed, preserve a copy of the written Startup item, the Startup directory listing, and case exports for the relevant file events, writer process metadata, later execution records, user-host identifiers, and related-alert context before containment.
+- Apply reversible containment before destructive action: quarantine the Startup item after preserving it, restrict further RDP or SMB administrative access to the host, or heighten monitoring on the affected `host.id`. Isolate the host only when later execution or related alerts show broader compromise and the host role can tolerate disruption.
+- If confirmed malicious, record any later-executed process identifiers and command lines, preserve the Startup item and same-directory artifacts, then isolate the host when feasible, terminate malicious execution, and remove the Startup item, shortcuts, scripts, and staging artifacts identified during the investigation.
+- Before deleting artifacts or resetting credentials, scope other hosts and accounts for the same `file.name`, `file.path`, writer `process.command_line`, or later `process.executable` pattern. Reset or reissue credentials only when related alerts or later execution indicate likely account misuse.
+- Post-incident hardening: restrict unnecessary RDP drive redirection, tighten SMB administrative write access, monitor Startup folder changes on remote-access targets, and retain the file/process telemetry needed to distinguish repeat deployment workflows from repeat abuse.
+
+==== 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
 
diff --git a/docs/detections/prebuilt-rules/rule-details/lsass-memory-dump-handle-access.asciidoc b/docs/detections/prebuilt-rules/rule-details/lsass-memory-dump-handle-access.asciidoc
index 323366a135..f5efb5a202 100644
--- a/docs/detections/prebuilt-rules/rule-details/lsass-memory-dump-handle-access.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/lsass-memory-dump-handle-access.asciidoc
@@ -39,7 +39,7 @@ Identifies handle requests for the Local Security Authority Subsystem Service (L
 * Resources: Investigation Guide
 * Data Source: Windows Security Event Logs
 
-*Version*: 217
+*Version*: 218
 
 *Rule authors*: 
 
@@ -135,6 +135,7 @@ host.os.type:"windows" and event.code:"4656" and
     winlog.event_data.AccessMask : ("0x1fffff" or "0x1010" or "0x120089" or "0x1F3FFF") or
     winlog.event_data.AccessMaskDescription : ("READ_CONTROL" or "Read from process memory")
   ) and
+  winlog.event_data.ObjectType : "Process" and 
   winlog.event_data.ObjectName : *\\Windows\\System32\\lsass.exe and
   not winlog.event_data.ProcessName : (
       "C:\Windows\System32\wbem\WmiPrvSE.exe" or
@@ -142,7 +143,13 @@ host.os.type:"windows" and event.code:"4656" and
       "C:\Windows\System32\dllhost.exe" or
       "C:\Windows\System32\svchost.exe" or
       "C:\Windows\System32\msiexec.exe" or
-      "C:\Windows\explorer.exe"
+      "C:\Windows\explorer.exe" or 
+      "C:\\Windows\\Sysmon64.exe" or 
+      "C:\\Windows\\BTPass\\x64\\BTPassSvc.exe" or 
+      "C:\\Windows\\Sysmon.exe" or 
+      "C:\\Windows\\System32\\RtkAudUService64.exe" or 
+      "C:\\Windows\\System32\\RtkAudUService64.exe" or 
+       C\:\\Windows\\System32\\DriverStore\\FileRepository\\fn.inf_amd64_*\\driver\\tphkload.exe
   )
 
 ----------------------------------
diff --git a/docs/detections/prebuilt-rules/rule-details/lsass-process-access-via-windows-api.asciidoc b/docs/detections/prebuilt-rules/rule-details/lsass-process-access-via-windows-api.asciidoc
index 0f7e4d6800..42bacec845 100644
--- a/docs/detections/prebuilt-rules/rule-details/lsass-process-access-via-windows-api.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/lsass-process-access-via-windows-api.asciidoc
@@ -32,7 +32,7 @@ Identifies access attempts to the LSASS handle, which may indicate an attempt to
 * Data Source: Microsoft Defender XDR
 * Resources: Investigation Guide
 
-*Version*: 18
+*Version*: 19
 
 *Rule authors*: 
 
@@ -154,8 +154,8 @@ from logs-endpoint.events.api-*, logs-m365_defender.event-* metadata _id, _versi
    // Noisy patterns
    not to_lower(process.executable) like """c:\\program files\\*.exe""" and
    not to_lower(process.executable) like """c:\\program files (x86)\\*.exe""" and
-   not process.executable like """C:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\MsMpEng.exe""" and
-   not process.executable like """C:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\*\\MsMpEng.exe"""
+   not to_lower(process.executable) like """c:\\programdata\\microsoft\\windows defender\\platform\\msmpeng.exe""" and
+   not to_lower(process.executable) like """c:\\programdata\\microsoft\\windows defender\\platform\\*\\msmpeng.exe"""
 
  /* normalize process paths to reduce known random patterns in process.executable */
 | eval Esql.process_path = replace(process.executable, """([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|ns[a-z][A-Z0-9]{3,4}\.tmp|DX[A-Z0-9]{3,4}\.tmp|7z[A-Z0-9]{3,5}\.tmp|[0-9\.\-\_]{3,})""", "")
diff --git a/docs/detections/prebuilt-rules/rule-details/m365-identity-login-from-atypical-region.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-identity-login-from-atypical-region.asciidoc
new file mode 100644
index 0000000000..08c48e01bd
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/m365-identity-login-from-atypical-region.asciidoc
@@ -0,0 +1,136 @@
+[[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 <<rule-schedule, `Additional look-back time`>>)
+
+*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*: 11
+
+*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 10 or 2 or 3 or 5 or 6) and
+    o365.audit.UserId:(* and not "Not Available") and
+    source.geo.country_name:* and
+    source.geo.region_name:* and
+    not o365.audit.ApplicationId:(
+        29d9ed98-a469-4536-ade2-f981bc1d605e or
+        38aa3b87-a06d-4817-b275-7a316988d93b or
+        a809996b-059e-42e2-9866-db24b99a9782 or
+        08e18876-6177-487e-b8b5-cf950c1e598c or
+        3e62f81e-590b-425b-9531-cad6683656cf or
+        d7b530a4-7680-4c23-a8bf-c52c121d2e87
+    ) and not o365.audit.ExtendedProperties.RequestType:(
+        "Consent:Set" or
+        "DeviceAuth:ReprocessTls" or
+        "Kmsi:kmsi" or
+        "Login:reprocess" or
+        "Login:resume" or
+        "MessagePrompt:MessagePrompt" or
+        "Saml2:processrequest" or
+        "SAS:EndAuth" or
+        "SAS:ProcessAuth"
+    ) and
+    not user_agent.original:(*iPhone* or *iPad* or *Android* or *PKeyAuth*)
+
+----------------------------------
+
+*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/rule-details/m365-identity-login-from-impossible-travel-location.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-identity-login-from-impossible-travel-location.asciidoc
index fd6dc9dd9c..5982996de5 100644
--- a/docs/detections/prebuilt-rules/rule-details/m365-identity-login-from-impossible-travel-location.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/m365-identity-login-from-impossible-travel-location.asciidoc
@@ -34,7 +34,7 @@ Detects successful Microsoft 365 portal logins from impossible travel locations.
 * Tactic: Initial Access
 * Resources: Investigation Guide
 
-*Version*: 9
+*Version*: 10
 
 *Rule authors*: 
 
@@ -96,11 +96,14 @@ data_stream.dataset:o365.audit and
     event.outcome:success and
     o365.audit.Target.Type:(0 or 10 or 2 or 3 or 5 or 6) and
     o365.audit.UserId:(* and not "Not Available") and
-    source.geo.region_iso_code:* and
+    source.geo.country_name:* and
     not o365.audit.ApplicationId:(
         29d9ed98-a469-4536-ade2-f981bc1d605e or
         38aa3b87-a06d-4817-b275-7a316988d93b or
-        a809996b-059e-42e2-9866-db24b99a9782
+        a809996b-059e-42e2-9866-db24b99a9782 or
+        08e18876-6177-487e-b8b5-cf950c1e598c or
+        3e62f81e-590b-425b-9531-cad6683656cf or
+        d7b530a4-7680-4c23-a8bf-c52c121d2e87
     ) and not o365.audit.ExtendedProperties.RequestType:(
         "Cmsi:Cmsi" or
         "Consent:Set" or
diff --git a/docs/detections/prebuilt-rules/rule-details/m365-potential-aitm-userloggedin-via-office-app-tycoon2fa.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-potential-aitm-userloggedin-via-office-app-tycoon2fa.asciidoc
new file mode 100644
index 0000000000..6d55d76602
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/m365-potential-aitm-userloggedin-via-office-app-tycoon2fa.asciidoc
@@ -0,0 +1,119 @@
+[[m365-potential-aitm-userloggedin-via-office-app-tycoon2fa]]
+=== M365 Potential AiTM UserLoggedIn via Office App (Tycoon2FA)
+
+Detects Microsoft 365 audit "UserLoggedIn" events consistent with Tycoon 2FA phishing-as-a-service (PhaaS) adversary-in-the-middle (AiTM) activity: the Microsoft Authentication Broker requesting access where the object identifier matches Microsoft Graph or Exchange Online, or the Office web client application authenticating to itself, combined with Node.js-style user agents (node, axios, undici). Tycoon 2FA bypasses MFA by relaying authentication and capturing session material, often targeting Microsoft 365 and Gmail. Baseline legitimate automation and developer tooling before tuning.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://any.run/malware-trends/tycoon/
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Domain: SaaS
+* Data Source: Microsoft 365
+* Data Source: Microsoft 365 Audit Logs
+* Use Case: Threat Detection
+* Threat: Tycoon2FA
+* Tactic: Initial Access
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating M365 Potential AiTM UserLoggedIn via Office App (Tycoon2FA)*
+
+
+Review `o365.audit.UserId`, `user_agent.original`, `source.ip` or `o365.audit.ActorIpAddress`, and related Entra ID
+sign-in logs (`azure.signinlogs`) for the same session or time window.
+
+Confirm whether the account owner intentionally authenticated and whether Node.js-style user agents (node, axios, undici)
+are expected for Microsoft Authentication Broker or Office web client flows in your environment.
+
+
+*Possible investigation steps*
+
+
+- Correlate with `azure.signinlogs` for matching user principal name, IP, and session identifiers.
+- Review Microsoft Graph or Exchange audit activity following the login for mailbox or data access anomalies.
+- Hunt for other `UserLoggedIn` events from the same source with unusual user agents or rapid OAuth patterns.
+
+
+*Response and remediation*
+
+
+- If malicious, revoke refresh tokens for the user, reset credentials per policy, and review conditional access outcomes.
+- Block or monitor the source IP and escalate per incident procedures.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+data_stream.dataset:"o365.audit" and event.category:"authentication" and event.action:"UserLoggedIn" and
+(
+    (
+        o365.audit.ApplicationId:"29d9ed98-a469-4536-ade2-f981bc1d605e" and
+        o365.audit.ObjectId:(
+            "00000002-0000-0ff1-ce00-000000000000" or "00000003-0000-0000-c000-000000000000"
+        )
+    ) or
+    (
+        o365.audit.ApplicationId:"4765445b-32c6-49b0-83e6-1d93765276ca" and
+        o365.audit.ObjectId:"4765445b-32c6-49b0-83e6-1d93765276ca"
+    )
+) and user_agent.original:(node or axios* or undici)
+
+----------------------------------
+
+*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/
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Steal Web Session Cookie
+** ID: T1539
+** Reference URL: https://attack.mitre.org/techniques/T1539/
diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-worker-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-worker-spawning-suspicious-processes.asciidoc
index 785c2d150b..2216493997 100644
--- a/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-worker-spawning-suspicious-processes.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-worker-spawning-suspicious-processes.asciidoc
@@ -36,7 +36,6 @@ Identifies suspicious processes being spawned by the Microsoft Exchange Server w
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Initial Access
-* Tactic: Execution
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
 * Data Source: Sysmon
@@ -44,7 +43,7 @@ Identifies suspicious processes being spawned by the Microsoft Exchange Server w
 * Data Source: SentinelOne
 * Resources: Investigation Guide
 
-*Version*: 315
+*Version*: 316
 
 *Rule authors*: 
 
@@ -60,48 +59,82 @@ Identifies suspicious processes being spawned by the Microsoft Exchange Server w
 *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 Microsoft Exchange Worker Spawning Suspicious Processes*
 
 
-Microsoft Exchange Server uses the worker process (w3wp.exe) to handle web requests, often running under specific application pools. Adversaries exploit this by executing malicious scripts or commands, potentially via web shells, to gain unauthorized access or execute arbitrary code. The detection rule identifies unusual child processes like command-line interpreters spawned by w3wp.exe, signaling possible exploitation or backdoor activity.
-
 
 *Possible investigation steps*
 
 
-- Review the alert details to confirm the parent process is w3wp.exe and check if the process arguments include "MSExchange*AppPool" to ensure the alert is relevant to Microsoft Exchange.
-- Examine the child process details, focusing on the process names and original file names such as cmd.exe, powershell.exe, pwsh.exe, and powershell_ise.exe, to identify any unauthorized or unexpected command-line activity.
-- Investigate the timeline of events leading up to the alert, including any preceding or subsequent processes, to understand the context and potential impact of the suspicious activity.
-- Check for any associated network activity or connections initiated by the suspicious processes to identify potential data exfiltration or communication with external command and control servers.
-- Review recent changes or access logs on the affected Exchange server to identify any unauthorized access attempts or modifications that could indicate exploitation or the presence of a web shell.
-- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender XDR, or SentinelOne to gather additional context and corroborate findings.
-- Assess the risk and impact of the detected activity, considering the severity and risk score, and determine appropriate response actions, such as isolating the affected system or conducting a deeper forensic analysis.
+- What Exchange worker-child path did the alert capture?
+  - Focus: child `process.executable` and `process.command_line`; worker `process.parent.executable`, `process.parent.args`, and `process.parent.command_line`; exact MSExchange app pool.
+  - Implication: escalate when an Exchange app pool launches shell/PowerShell for execution, download, discovery, or staging; lower suspicion only when parent arguments and child command match one narrow maintenance task with no webshell or RCE indicators.
+- What intent does the shell or PowerShell command show?
+  - Focus: `process.command_line`; encoded or inline execution, download cradles, archive/export, discovery, Set-OabVirtualDirectory, mailbox access, or FrontEnd\HttpProxy, aspnet_client, web.config, and applicationHost.config paths.
+  - Implication: escalate on payload retrieval, web-root staging, credential access, account changes, mailbox export, cleanup, or lateral movement; lower suspicion only for one bounded recognized Exchange maintenance or validation action.
+- Does token and session context support human administration or service-context abuse?
+  - Why: w3wp.exe children often inherit app-pool or service identity, so user fields alone do not prove human administration.
+  - Focus: `user.id`, `user.name`, `user.domain`, `process.Ext.session_info.logon_type`, and `process.Ext.authentication_id`.
+  - Implication: escalate when a service, app-pool, or unexpected logon context launches interactive shell behavior or remote administration; lower suspicion only when identity, session type, and command scope match the same recognized workflow.
+- Is the child binary expected or masqueraded?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the child is renamed, user-writable, unsigned or untrusted, hash-new for the server, or mismatched to PE original name; a trusted Microsoft shell lowers identity concern but does not clear the unusual chain.
+- If process evidence is suspicious or unresolved, did file evidence show webshells or artifacts?
+  - Focus: with endpoint file telemetry, scope by `host.id` + `process.entity_id`, or `host.id` + `process.pid` + tight alert window if absent; inspect `file.path`, `file.Ext.original.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier` for ASPX, scripts, binaries, DLLs, archives, or output under Exchange/IIS paths. !{investigate{"description":"","label":"File events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: check whether a written `file.path` later appears as `process.executable`; missing file telemetry limits proof but is not benign.
+  - Implication: escalate when the child writes new or modified ASPX, scripts, binaries, DLLs, archives, or output under Exchange FrontEnd\HttpProxy, IIS aspnet_client, temp, or web-root paths; lower suspicion only when file activity stays inside the exact maintenance path with no web-content or payload staging.
+- If process evidence is suspicious or unresolved, did network evidence show retrieval or callback?
+  - Focus: with endpoint network telemetry, scope DNS and connections by `host.id` + `process.entity_id`, or `host.id` + `process.pid` + tight alert window if absent; read DNS (`dns.question.name`, `dns.resolved_ip`) separately from connections (`destination.ip`, `destination.port`). !{investigate{"description":"","label":"Network events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: map `dns.resolved_ip` to `destination.ip` before deciding whether the same process reached it. Missing network telemetry is unresolved, not benign.
+  - Implication: escalate when the child downloads tools, reaches public staging or callback infrastructure, or connects to systems unrelated to the Exchange task; lower suspicion only when destinations are internal, proxy, or vendor services fitting the same bounded workflow.
+- Does same-worker or same-host scope show broader Exchange compromise?
+  - Focus: surrounding same-worker process starts and related alerts on `host.id` or `user.id`, especially `process.parent.executable`, `process.parent.args`, `process.command_line`, and `process.hash.sha256` for repeated w3wp.exe descendants, credential dumping, account changes, archiving, cleanup, or side-loading chains.
+    - !{investigate{"description":"","label":"Process events from the same Exchange worker","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","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"}}
+    - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate scope when the host shows credential dumping, account changes, archive creation, cleanup, lateral movement, or repeated Exchange worker children; keep local only when surrounding process evidence and related alerts stay confined to the same recognized maintenance window.
+- Escalate on unexplained server-side execution, suspicious command intent, payload staging, suspicious destinations, or broader host compromise; close only when all available evidence aligns with one recognized Exchange workflow on this host; preserve artifacts and escalate when evidence is mixed or visibility incomplete.
 
 
 *False positive analysis*
 
 
-- Routine administrative tasks may trigger the rule if administrators use command-line tools like cmd.exe or powershell.exe for legitimate maintenance. To manage this, create exceptions for known administrative accounts or specific IP addresses that regularly perform these tasks.
-- Scheduled tasks or scripts that run under the MSExchangeAppPool context might spawn command-line interpreters as part of their normal operation. Identify these tasks and exclude them by specifying their unique process arguments or command lines.
-- Monitoring or backup software that interacts with Exchange Server could inadvertently trigger the rule. Review the software's documentation to confirm its behavior and exclude its processes by name or hash if they are verified as safe.
-- Custom applications or integrations that interact with Exchange Server and use command-line tools for automation may also cause false positives. Work with application developers to understand these interactions and exclude them based on process names or specific command-line patterns.
-- If a known security tool or script is used to test Exchange Server's security posture, it might mimic suspicious behavior. Document these tools and exclude their processes during scheduled testing periods to avoid false alerts.
+- Recognized Exchange maintenance or controlled validation is the bounded benign path. Confirm only when `process.parent.args`, child `process.command_line`, `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `user.id`, and `host.id` align with one task, and any `file.path`, `dns.question.name`, or `destination.ip` evidence shows no payload staging or external callback. Use change records as corroboration; otherwise require recurring prior alerts with the same parent arguments, command pattern, child identity, user, host, and no contradictory artifacts or destinations.
+- Build exceptions only from the minimum confirmed pattern: `process.parent.args`, child `process.executable` or `process.hash.sha256`, `process.code_signature.subject_name`, stable `process.command_line` fragment, `user.id`, `host.id`, and any bounded artifact or destination pattern distinguishing the benign task. Avoid exceptions on "w3wp.exe", `process.name`, or `host.id` alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected Microsoft Exchange Server from the network to prevent further unauthorized access or lateral movement.
-- Terminate any suspicious processes identified as being spawned by w3wp.exe, such as cmd.exe or powershell.exe, to halt any ongoing malicious activity.
-- Conduct a thorough review of the server's application pools and web directories to identify and remove any unauthorized web shells or scripts.
-- Restore the server from a known good backup taken before the suspicious activity was detected to ensure system integrity.
-- Apply the latest security patches and updates to the Microsoft Exchange Server to mitigate known vulnerabilities and prevent exploitation.
-- Monitor network traffic and server logs for any signs of continued or attempted exploitation, focusing on unusual outbound connections or repeated access attempts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised.
+- If confirmed benign, reverse temporary containment and document the exact evidence that validated the workflow: `process.parent.args`, child `process.executable`, `process.command_line`, `user.id`, `host.id`, and any bounded artifact or destination pattern. Create an exception only after the same pattern is stable across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve the alert, process tree, child `process.entity_id` or `process.pid`, `process.command_line`, parent `process.parent.entity_id`, `process.parent.args`, child hash and signer, `user.id`, `host.id`, and any staged artifacts, destinations, or IIS/Exchange log snippets before containment. Apply reversible containment first: block confirmed malicious destinations, restrict external access to the implicated Exchange service, or increase monitoring. Isolate only when active compromise evidence and server criticality justify disruption.
+- If confirmed malicious, contain the Exchange server or exposed service path based on the process, artifact, destination, and same-host evidence already preserved. Record process and artifact identifiers before terminating the child, then block confirmed malicious domains, IPs, and hashes.
+- Eradicate only the webshells, scripts, archives, scheduled tasks, dropped utilities, and configuration changes identified during triage. Restore modified Exchange or IIS content from known-good state, patch the Exchange server, review the virtual directories and app pools implicated by `process.parent.args`, and rotate Exchange, application, or service credentials if credential access, configuration theft, or mailbox export was involved.
+- Retain the related process, file, network, IIS, and Exchange logs that supported the decision. Document any adjacent variant or telemetry gap, such as missing endpoint file/network events or unavailable IIS request logs, for the detection engineering team.
+
+
+==== 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
 
diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-graph-multi-category-reconnaissance-burst.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-graph-multi-category-reconnaissance-burst.asciidoc
new file mode 100644
index 0000000000..761291267f
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/microsoft-graph-multi-category-reconnaissance-burst.asciidoc
@@ -0,0 +1,213 @@
+[[microsoft-graph-multi-category-reconnaissance-burst]]
+=== Microsoft Graph Multi-Category Reconnaissance Burst
+
+Detects Microsoft Graph activity from delegated user tokens (public client, client_auth_method 0) where a single user session and source IP rapidly touches multiple high-value Graph paths indicative of reconnaissance. The query classifies requests into categories such as role discovery, cross-tenant relationship queries, mailbox paths, contact harvesting, and organization or licensing metadata. When three or more distinct categories appear within a short burst window, it suggests a broad enumeration playbook rather than normal application traffic.
+
+*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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Domain: API
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Graph
+* Data Source: Microsoft Graph Activity Logs
+* Use Case: Threat Detection
+* Tactic: Discovery
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Microsoft Graph Multi-Category Reconnaissance Burst*
+
+
+This rule uses an aggregation-based ES|QL query. Alert documents contain summarized fields; pivot to raw Graph activity
+logs using user principal object ID, session ID (c_sid), source IP, tenant ID, and timestamps from the alert.
+
+
+*Possible investigation steps*
+
+
+- Review Esql.categories and Esql.sample_paths to see which Graph endpoints were touched and whether they align with the app purpose.
+- Validate azure.graphactivitylogs.properties.app_id and user_agent.original against approved applications.
+- Correlate with Entra ID sign-in logs for the same user and session for MFA, conditional access, and token issuance context.
+- Check whether failed_calls indicates probing or permission errors versus successful enumeration.
+
+
+*Response and remediation*
+
+
+- If malicious, revoke refresh tokens for the user, disable or restrict the application consent, and reset credentials per policy.
+- Add conditional access or block rules for high-risk Graph patterns where appropriate.
+
+
+==== Setup
+
+
+
+*Microsoft Graph Activity Logs*
+
+Requires Microsoft Graph Activity Logs ingested into `logs-azure.graphactivitylogs-*` (for example via Azure Event Hub).
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-azure.graphactivitylogs-* metadata _id, _version, _index
+
+// Graph calls via delegated user tokens (any status, any method)
+| where event.dataset == "azure.graphactivitylogs"
+  and azure.graphactivitylogs.properties.c_idtyp == "user"
+  and azure.graphactivitylogs.properties.client_auth_method == 0
+
+// high-value recon endpoints by url.path
+| eval Esql.is_role_enum = case(
+    url.path like "*roleManagement/directory*"
+      or url.path like "*memberOf/microsoft.graph.directoryRole*"
+      or url.path like "*transitiveRoleAssignments*",
+    true,
+    false
+  )
+| eval Esql.is_cross_tenant_enum = case(
+    url.path like "*tenantRelationships*"
+      or url.path like "*getResourceTenants*",
+    true,
+    false
+  )
+| eval Esql.is_mailbox_recon = case(
+    url.path like "*mailboxSettings*"
+      or url.path like "*mailFolders*"
+      or url.path like "*messages*"
+      or url.path like "*inbox*",
+    true,
+    false
+  )
+| eval Esql.is_contact_harvest = case(
+    url.path like "*contacts*"
+      or url.path like "*contactFolders*",
+    true,
+    false
+  )
+| eval Esql.is_org_recon = case(
+    url.path like "*subscribedSkus*"
+      or url.path like "*appRoleAssign*"
+      or (
+          url.path like "*/organization*"
+          and not url.path like "*branding*"
+          and not url.path like "*localizations*"
+        ),
+    true,
+    false
+  )
+
+// Combine: is this request hitting a high-value endpoint?
+| eval Esql.is_high_value = case(
+    Esql.is_role_enum or Esql.is_cross_tenant_enum or Esql.is_mailbox_recon
+      or Esql.is_contact_harvest or Esql.is_org_recon,
+    true,
+    false
+  )
+| where Esql.is_high_value == true
+
+// Classify each hit into a recon category
+| eval Esql.recon_category = case(
+    Esql.is_role_enum, "role_discovery",
+    Esql.is_cross_tenant_enum, "cross_tenant_recon",
+    Esql.is_mailbox_recon, "mailbox_recon",
+    Esql.is_contact_harvest, "contact_harvesting",
+    Esql.is_org_recon, "org_and_licensing_recon",
+    "other"
+  )
+
+// Flag failed requests (recon that errored is still recon)
+| eval Esql.is_failed_request = case(
+    http.response.status_code >= 400, true, false
+  )
+
+// Aggregate per user + session + source IP
+| stats
+    Esql.total_high_value_calls = count(*),
+    Esql.distinct_categories = count_distinct(Esql.recon_category),
+    Esql.distinct_paths = count_distinct(url.path),
+    Esql.failed_calls = sum(case(Esql.is_failed_request, 1, 0)),
+    Esql.categories = values(Esql.recon_category),
+    Esql.sample_paths = values(url.path),
+    Esql.http_methods = values(http.request.method),
+    Esql.status_codes = values(http.response.status_code),
+    Esql.first_seen = min(@timestamp),
+    Esql.last_seen = max(@timestamp),
+    Esql.user_agents = values(user_agent.original),
+    Esql.app_ids = values(azure.graphactivitylogs.properties.app_id)
+  by
+    azure.graphactivitylogs.properties.user_principal_object_id,
+    source.ip,
+    source.`as`.organization.name,
+    source.`as`.number,
+    azure.graphactivitylogs.properties.c_sid,
+    azure.tenant_id
+
+// Threshold: 3+ distinct recon categories 
+| where Esql.distinct_categories >= 4 and Esql.total_high_value_calls >= 20
+
+// Burst duration in seconds
+| eval Esql.burst_duration_seconds = date_diff("seconds", Esql.first_seen, Esql.last_seen)
+| where Esql.burst_duration_seconds <= 60
+
+| keep
+    azure.graphactivitylogs.properties.user_principal_object_id,
+    azure.graphactivitylogs.properties.c_sid,
+    azure.tenant_id,
+    source.ip,
+    source.`as`.organization.name,
+    source.`as`.number,
+    Esql.*
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Discovery
+** ID: TA0007
+** Reference URL: https://attack.mitre.org/tactics/TA0007/
+* Technique:
+** Name: Cloud Service Discovery
+** ID: T1526
+** Reference URL: https://attack.mitre.org/techniques/T1526/
+* Technique:
+** Name: Account Discovery
+** ID: T1087
+** Reference URL: https://attack.mitre.org/techniques/T1087/
diff --git a/docs/detections/prebuilt-rules/rule-details/mimikatz-memssp-log-file-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/mimikatz-memssp-log-file-detected.asciidoc
index f9a7855763..4baa69fad8 100644
--- a/docs/detections/prebuilt-rules/rule-details/mimikatz-memssp-log-file-detected.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/mimikatz-memssp-log-file-detected.asciidoc
@@ -43,7 +43,7 @@ Identifies the default Mimikatz MemSSP credential log file, mimilsa.log. This fi
 * Data Source: Microsoft Defender XDR
 * Data Source: Crowdstrike
 
-*Version*: 418
+*Version*: 419
 
 *Rule authors*: 
 
@@ -79,7 +79,7 @@ Identifies the default Mimikatz MemSSP credential log file, mimilsa.log. This fi
 - Which process activity likely enabled MemSSP before LSASS wrote the log?
   - Focus: process starts on the same `host.id`: `process.command_line`, `process.executable`, `process.parent.executable`, `process.code_signature.trusted`, and `process.Ext.token.integrity_level_name`.
   - Implication: escalate when "misc::memssp", Mimikatz/Invoke-Mimikatz, "mimilib.dll", PowerShell, rundll32, regsvr32, unsigned helpers, or high-integrity/system tooling appear before the write; a clean process search narrows the launcher only if collection covers that window.
-  - Hint: search backward from alert `@timestamp` for process starts containing "memssp", "mimikatz", "mimilib", or script/LOLBIN launchers on the same `host.id`. !{investigate{"description":"","label":"MemSSP-related process starts","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.command_line","queryType":"phrase","value":"*memssp*","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.command_line","queryType":"phrase","value":"*mimikatz*","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.command_line","queryType":"phrase","value":"*mimilib*","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: search backward from alert `@timestamp` for process starts containing "memssp", "mimikatz", "mimilib", or script/LOLBIN launchers on the same `host.id`.
 
 - Which accounts may have been exposed after the log appeared?
   - Why: MemSSP records credentials from successful authentications after injection, so exposure depends on who logged on or unlocked the host after the write.
@@ -88,7 +88,7 @@ Identifies the default Mimikatz MemSSP credential log file, mimilsa.log. This fi
 
 - Does the host show default in-memory MemSSP only, or a persistent SSP setup?
   - Why: persistent SSP changes survive a single process-memory event and widen eradication scope beyond the observed log file.
-  - Focus: companion DLL file events (`file.path`, `file.extension`) and, when registry telemetry is available, LSA Security Packages changes in `registry.path` and `registry.data.strings`. !{investigate{"description":"","label":"MemSSP persistence file and registry evidence","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.name","queryType":"phrase","value":"mimilib.dll","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"registry.path","queryType":"phrase","value":"*\\Control\\Lsa\\Security Packages*","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"registry.data.strings","queryType":"phrase","value":"*mimilib*","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}}
+  - Focus: companion DLL file events (`file.path`, `file.extension`) and, when registry telemetry is available, LSA Security Packages changes in `registry.path` and `registry.data.strings`.
   - Implication: escalate persistence scope when "mimilib.dll" or an unfamiliar SSP DLL is placed for loading, or when LSA Security Packages registry data names it; if registry telemetry is unavailable, persistence is unresolved and must not be used to close.
 
 - If local evidence is suspicious or unresolved, what related alert activity changes scope?
diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-hidden-run-key-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-hidden-run-key-detected.asciidoc
index f42717c27e..9729e91071 100644
--- a/docs/detections/prebuilt-rules/rule-details/persistence-via-hidden-run-key-detected.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-hidden-run-key-detected.asciidoc
@@ -36,8 +36,6 @@ Identifies a persistence mechanism that utilizes the NtSetValueKey native API to
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Persistence
-* Tactic: Defense Evasion
-* Tactic: Execution
 * Resources: Investigation Guide
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
@@ -46,7 +44,7 @@ Identifies a persistence mechanism that utilizes the NtSetValueKey native API to
 * Data Source: SentinelOne
 * Data Source: Microsoft Defender XDR
 
-*Version*: 215
+*Version*: 216
 
 *Rule authors*: 
 
@@ -62,55 +60,96 @@ Identifies a persistence mechanism that utilizes the NtSetValueKey native API to
 *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 Hidden Run Key Detected*
 
 
-The Windows Registry is a critical system database that stores configuration settings. Adversaries exploit it for persistence by creating hidden registry keys using native APIs, making them invisible to standard tools like regedit. The detection rule identifies changes in specific registry paths associated with startup programs, flagging null-terminated keys that suggest stealthy persistence tactics.
-
 
 *Possible investigation steps*
 
 
-- Review the specific registry path where the change was detected to determine if it matches any of the paths listed in the query, such as "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\" or "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\".
-- Check the timestamp of the registry change event to correlate it with other system activities or user actions that occurred around the same time.
-- Investigate the process that made the registry change by examining process creation logs or using tools like Sysmon to identify the responsible process and its parent process.
-- Analyze the content of the registry key value that was modified or created to determine if it points to a legitimate application or a potentially malicious executable.
-- Cross-reference the detected registry change with known threat intelligence sources to identify if the key or value is associated with known malware or adversary techniques.
-- Assess the affected system for additional indicators of compromise, such as unusual network connections, file modifications, or other persistence mechanisms.
+- Does the registry event support hidden or null-terminated Run-value semantics, and what would it launch?
+  - Why: trailing Run-key `registry.path` with launch data can indicate a null-prefixed value name created through NtSetValueKey; raw telemetry can preserve it when regedit does not.
+  - Focus: `registry.path`, `registry.hive`, `registry.value`, `registry.data.type`, and `registry.data.strings`.
+  - Hint: trust the registry event over GUI rendering; record exact `registry.data.strings` before tools normalize the hidden value name.
+  - Implication: escalate when raw evidence supports hidden-value semantics and an unexpected command; lower suspicion only when exact raw value, payload, user, and host match authorized hidden-registry testing. The alert indicates a hiding technique, not one tool.
+
+- Which hive and logon scope would activate the hidden autorun?
+  - Focus: `registry.hive`, `registry.path`, `user.id`, and `host.id`.
+  - Implication: prioritize host-wide containment for machine hives and user-focused containment for user hives; lower urgency only when raw value evidence supports a constrained test user or lab host.
+
+- Which process wrote the hidden value, and does its identity and launch chain fit the expected test or validation workflow?
+  - Focus: `process.entity_id`, `process.executable`, `process.command_line`, `process.parent.executable`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Hint: use the writer's process-start event on `host.id` and `process.entity_id` to confirm command line, parent, and signer. !{investigate{"description":"","label":"Process events for the registry writer","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the writer is a script host, document child, remote-admin tool, unsigned/untrusted binary, user-writable executable, or SharpHide-like command line; lower suspicion when signer, path, parent, command line, user, and host align with the same recognized test or validation component.
+
+- Did the hidden autorun command execute after logon or spawn suspicious follow-on activity?
+  - Focus: post-alert process starts on `host.id` where `process.executable` or `process.command_line` matches the `registry.data.strings` payload.
+  - Hint: for user-hive paths, include `user.id`; for machine-hive paths, check the next interactive logon. Use `process.parent.name` and `process.parent.executable` to identify the launcher. !{investigate{"description":"","label":"Process starts matching the hidden Run payload","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.command_line","queryType":"phrase","value":"{{registry.data.strings}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}}
+  - Implication: escalate when the payload launches after logon, runs through a shell, script host, LOLBin, user-writable path, or obfuscated chain, or creates unusual children; no later launch leaves execution unproven, not benign, unless the value and writer are fully explained.
+
+- Did the same writer modify other startup or hidden-registry locations around the alert time?
+  - Focus: writer-scoped registry events, especially `registry.path`, `registry.key`, `registry.value`, and `registry.data.strings` for Run, RunOnce, Policies\Explorer\Run, or related startup paths.
+  - Hint: start with `host.id` and `process.entity_id`, then widen only to the same host and startup-path family. !{investigate{"description":"","label":"Registry events from the writer process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the process spreads persistence across startup keys, rewrites the same path, or creates additional hidden or malformed values; a single bounded change lowers scope only after writer and payload are independently explained.
+
+- If local evidence remains suspicious or unresolved, do same-user or same-host alerts show broader activity?
+  - Focus: recent same-`user.id` alerts tied to persistence, defense evasion, credential access, or lateral movement. !{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: review same-`host.id` alerts when local evidence is suspicious or incomplete. !{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 containment when related alerts show precursor access, more persistence, credential abuse, or follow-on movement; keep local only when related alerts are absent and the hidden value is otherwise exactly explained.
+
+- Escalate when hidden Run semantics pair with a suspicious writer, payload, later execution, adjacent persistence, or related alerts; close only when same-host telemetry and corroborating test or validation records explain the exact value, writer, payload, user, and host with no contradictions; preserve registry, process, and payload evidence and escalate when answers remain mixed or incomplete.
 
 
 *False positive analysis*
 
 
-- Legitimate software installations or updates may create registry keys in the specified paths, leading to false positives. Users can monitor the installation process and temporarily disable the rule during known software updates to prevent unnecessary alerts.
-- System administrators may intentionally configure startup programs for maintenance or monitoring purposes. Document these configurations and create exceptions in the detection rule to avoid flagging them as threats.
-- Some security software may use similar techniques to ensure their components start with the system. Verify the legitimacy of such software and whitelist their registry changes to prevent false alarms.
-- Custom scripts or automation tools used within an organization might modify registry keys for operational reasons. Identify these scripts and exclude their activities from the detection rule to reduce false positives.
-- Regularly review and update the list of known safe applications and processes that interact with the registry paths in question, ensuring that the detection rule remains relevant and accurate.
+- Authorized adversary emulation, detection validation, or security-product testing can create hidden Run values to test detection of regedit-hidden startup entries. Close only when `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `registry.path`, `registry.data.strings`, `user.id`, and `host.id` match the same authorized test chain, and any later `process.command_line` stays bounded to it. Without validation records, do not close on recurrence alone; keep suspicious or unresolved until exact test scope is verified.
+- Routine software installation can explain ordinary Run-key writes, but should not require a hidden or null-terminated value name. Treat installer or support claims as insufficient unless telemetry proves the exact hidden value, writer, payload, and execution pattern belong to a recognized lab, validation, or product-test workflow.
+- Before an exception, require a verified test or validation workflow, then confirm the same `process.executable`, `process.code_signature.subject_name`, `registry.path`, `registry.data.strings`, `user.id`, and `host.id` pattern recurs across prior alerts from this rule. Build the exception from that minimum confirmed workflow; avoid exceptions on Run paths alone, `process.name` alone, payload strings alone, or the rule name alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
-- Use a trusted tool to manually inspect and remove the hidden registry keys identified in the alert from the specified registry paths to eliminate the persistence mechanism.
-- 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 files or processes associated with the threat.
-- Review recent user activity and system logs to identify any unauthorized access or changes made by the adversary, and reset credentials for any compromised accounts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced monitoring on the affected system and similar endpoints to detect any recurrence of the threat, focusing on registry changes and process execution.
-- Update and reinforce endpoint security configurations to prevent similar persistence techniques, such as enabling registry auditing and restricting access to critical registry paths.
+- If confirmed benign, reverse any temporary containment and record the `process.executable`, signer, `process.command_line`, `registry.path`, exact `registry.data.strings`, `user.id`, `host.id`, and later logon execution pattern that proved the authorized workflow. Keep any exception narrow and tied to the recurring workflow.
+- If suspicious but unconfirmed, first preserve the raw registry event, affected Run-key hive with the hidden value intact when possible, writer `process.entity_id`, writer command line, process lineage, payload string from `registry.data.strings`, and related-alert context. Then apply reversible containment tied to those findings, such as isolating the host if its role tolerates it, temporarily preventing the affected user from logging back in, or blocking execution of the referenced payload.
+- If confirmed malicious, preserve the same registry and process evidence before destructive action. Use tooling that can enumerate null-prefixed value names to remove the hidden autorun, collect or quarantine the referenced payload artifact, and review the same `process.entity_id`, `registry.path`, and startup-key family for additional hidden or visible autoruns before cleanup. Terminate a recovered payload process only after recording its `process.entity_id` and command line.
+- After containment, review other hosts and users for the same `registry.data.strings`, startup-path family, signer, or payload path before deleting artifacts, then verify that no additional Run or RunOnce locations reference the same payload.
+- Post-incident hardening: restrict startup-key modifications to recognized installers and management tools, retain registry and process telemetry needed to correlate hidden Run-key writes with writer lineage and logon execution, and record any adjacent hidden-registry or startup-persistence variant in case notes.
+
+
+==== 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-reg-setup[Sysmon Registry Events]
+
 
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
-/* Registry Path ends with backslash */
 registry where host.os.type == "windows" and event.type == "change" and length(registry.data.strings) > 0 and
+  
+  /* Registry Path ends with backslash */
   registry.path : "*\\Run\\" and
   registry.path : (
     "*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\",
diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-microsoft-office-addins.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-microsoft-office-addins.asciidoc
index 3c00aaf823..f4865a1dd0 100644
--- a/docs/detections/prebuilt-rules/rule-details/persistence-via-microsoft-office-addins.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-microsoft-office-addins.asciidoc
@@ -43,7 +43,7 @@ Detects attempts to establish persistence on an endpoint by abusing Microsoft Of
 * Data Source: Crowdstrike
 * Resources: Investigation Guide
 
-*Version*: 313
+*Version*: 314
 
 *Rule authors*: 
 
@@ -59,47 +59,86 @@ Detects attempts to establish persistence on an endpoint by abusing Microsoft Of
 *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 Microsoft Office AddIns*
 
 
-Microsoft Office AddIns enhance productivity by allowing custom functionalities in Office applications. However, adversaries exploit this by placing malicious add-ins in specific startup directories, ensuring execution each time the application launches. The detection rule identifies suspicious files with extensions like .xll or .xlam in these directories, flagging potential persistence mechanisms on Windows systems.
-
 
 *Possible investigation steps*
 
 
-- Review the file path and extension from the alert to confirm it matches the suspicious directories and extensions specified in the detection rule, such as .xll or .xlam in the Microsoft Office startup directories.
-- Check the file creation and modification timestamps to determine when the suspicious file was added or altered, which can help establish a timeline of potential malicious activity.
-- Investigate the file's origin by examining recent file downloads, email attachments, or network activity that might have introduced the file to the system.
-- Analyze the file's contents or hash against known malware databases to identify if it is a known threat or potentially malicious.
-- Review user activity and system logs around the time the file was created or modified to identify any unusual behavior or processes that could be related to the persistence mechanism.
-- Assess the impacted user's role and access level to determine the potential risk and impact of the persistence mechanism on the organization.
+- Which Office add-in autoload mechanism does the alert show?
+  - Focus: alert `file.path`, `file.name`, `file.extension`, and `user.id` on `host.id`: "wll" maps to Word Startup, "xla"/"xlam" to Excel XLSTART, and "xll"/"ppa"/"ppam" to add-in locations that may need loader settings.
+  - Implication: escalate when a user-profile Office startup or add-in path receives a one-off or user-initiated add-in; lower suspicion only when path, name, extension, writer, and provenance all fit the same recognized deployment or repair.
+
+- Does the artifact identity or provenance look like a staged payload?
+  - Why: DLL-style "wll"/"xll" and Office container add-ins have different expected headers, so rename and origin fields can expose payload staging.
+  - Focus: `file.Ext.header_bytes`, `file.Ext.original.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier`.
+  - Implication: escalate when headers, rename history, internet-zone provenance, or archive/mail-cache origin conflict with the claimed add-in; lower suspicion when format and provenance align with the same recognized vendor package.
+
+- Does the writer process fit an add-in installer or a dropper chain?
+  - Focus: writer `process.executable`, `process.command_line`, `process.parent.executable`, and `process.code_signature.subject_name`.
+  - Implication: escalate when browsers, mail clients, scripting engines, archive tools, or unsigned user-writable binaries write the add-in; lower suspicion when signer, path, command line, and parent all match the same recognized installer or managed integration. Signer trust alone never clears the placement.
+
+- If registry telemetry is available, did the writer create loader settings required for this add-in type?
+  - Why: the alert is a file write; loader settings, when visible, show whether Office was configured to consume the add-in rather than merely store it.
+  - Focus: same `host.id` and writer `process.entity_id`; check `registry.path`, `registry.value`, `registry.data.type`, and `registry.data.strings` for Office loader values pointing to the alerted file. !{investigate{"description":"","label":"Registry events for the same writing 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":"registry","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when loader values reference the alerted file or directory; do not require registry corroboration when path, provenance, or writer evidence is already suspicious. Missing registry telemetry is unresolved, not benign.
+
+- Did Office later load the add-in or spawn follow-on activity from it?
+  - Focus: later Office `process.name` values "WINWORD.EXE", "EXCEL.EXE", or "POWERPNT.EXE" on the same `host.id`, Office `process.entity_id`, child `process.parent.entity_id`, child `process.executable`, and, if library telemetry exists, `dll.path` matching the add-in.
+    - !{investigate{"description":"","label":"Office process starts on the host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"WINWORD.EXE","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"EXCEL.EXE","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"POWERPNT.EXE","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Library loads for the add-in path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"dll.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Hint: missing library telemetry is unresolved, not benign; use those pivots and child process expansion from recovered Office instances as fallback execution evidence.
+  - Implication: escalate when Office loads the add-in path, starts a child from the same session, or touches a payload dropped with the add-in; do not wait for library telemetry when file, writer, or loader evidence already warrants escalation.
+
+- If local evidence is suspicious or unresolved, what related host activity changes scope?
+  - Focus: related alerts on the same `host.id`, especially document delivery, script execution, suspicious file writes, Office child processes, or additional persistence activity. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: expand scope when related host alerts connect the add-in write to delivery, execution, credential access, or another persistence mechanism; do not close solely because related alerts are absent.
+
+- What disposition do the add-in mechanism, artifact identity, writer lineage, loader state, Office execution, and scope support?
+  - Escalate on suspicious provenance, unexpected writer lineage, matching loader values, Office follow-on execution, or related host activity; close only when file, writer, provenance, loader state, and Office behavior align with one verified deployment or integration and no contradictions remain; preserve artifacts and escalate mixed or incomplete evidence.
 
 
 *False positive analysis*
 
 
-- Legitimate add-ins installed by trusted software vendors may trigger alerts. Verify the source and publisher of the add-in to determine its legitimacy.
-- Custom add-ins developed internally for business purposes can be flagged. Maintain a whitelist of known internal add-ins to prevent unnecessary alerts.
-- Frequent updates to legitimate add-ins might cause repeated alerts. Implement version control and update the whitelist accordingly to accommodate these changes.
-- User-specific add-ins for accessibility or productivity tools may be detected. Educate users on safe add-in practices and monitor for any unusual behavior.
-- Temporary add-ins used for specific projects or tasks can be mistaken for threats. Document and review these cases to ensure they are recognized as non-threatening.
+- Managed Office add-in deployment, repair, and productivity, accessibility, or CRM first-use installs can place files in these paths. Close only when writer `process.executable`, `process.command_line`, signer `process.code_signature.subject_name`, parent `process.parent.executable`, final `file.path`, required loader state, provenance fields, later Office `process.name`, and child `process.executable` all align with one deployment or vendor workflow and no contradictory evidence remains. Use change or inventory records as corroboration, not as a telemetry substitute.
+- Before creating an exception, build it from the minimum current-case pattern: `file.path`, writer `process.code_signature.subject_name`, writer `process.parent.executable`, required loader-state pattern, and `host.id` or `user.id` scope. Avoid exceptions on Office startup directories, file extensions, or Office process names alone.
 
 
 *Response and remediation*
 
 
-- Isolate the affected endpoint from the network to prevent further spread of the potential threat.
-- Terminate any suspicious Microsoft Office processes that may be running add-ins from the identified directories.
-- Remove the malicious add-in files from the specified startup directories: "C:\Users\*\AppData\Roaming\Microsoft\Word\Startup\", "C:\Users\*\AppData\Roaming\Microsoft\AddIns\", and "C:\Users\*\AppData\Roaming\Microsoft\Excel\XLSTART\".
-- Conduct a full antivirus and antimalware scan on the affected system using tools like Microsoft Defender XDR to ensure no other malicious files are present.
-- Review and restore any altered system configurations or settings to their default state to ensure system integrity.
-- Monitor the affected system and network for any signs of re-infection or related suspicious activity, using enhanced logging and alerting mechanisms.
-- Escalate the incident to the security operations center (SOC) or relevant IT security team for further analysis and to determine if additional systems are affected.
+- If confirmed benign, reverse temporary containment and document the verified workflow with `file.path`, `file.hash.sha256`, writer `process.executable`, signer `process.code_signature.subject_name`, and any recovered loader-state evidence. Create any exception from that exact workflow pattern and scope it narrowly to the confirmed host or user cohort.
+- If suspicious but unconfirmed, preserve the alert export, the add-in file and hash from `file.path` and `file.hash.sha256`, writer `process.entity_id` and `process.command_line`, and any recovered loader-state, library-load, or child-process evidence before deleting anything. Apply reversible containment first, such as quarantining the add-in file, disabling the affected Office add-in path, or temporarily restricting Office execution on the host.
+- If confirmed malicious, isolate the host if its role can tolerate interruption, then terminate responsible Office or loader processes only after preserving their entity IDs, command lines, and the add-in file evidence. Remove the malicious add-in, clear associated Office loader configuration, restore affected Office add-in settings, and remediate the delivery path that introduced the file. Reset credentials only if the investigation also shows account misuse.
+- Review related hosts and users for the same `file.path`, `file.hash.sha256`, writer lineage, and loader-state pattern before eradication. For Word WLL cases, do not rely on the Office UI alone to prove the add-in is disabled; verify the file and supporting configuration are gone.
+- Post-incident hardening: restrict write access to Office startup directories and add-in loader locations, prefer signed managed add-in deployment, retain process/file plus registry or library telemetry needed to confirm later Office execution, and document adjacent variants such as Word WLL autoload abuse or registry-backed Office add-in loading in the case record.
+
+
+==== 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-11-setup[Sysmon Event ID 11 - File Create]
+
 
 ==== Rule query
 
@@ -117,7 +156,8 @@ file where host.os.type == "windows" and event.type != "deletion" and
     "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Roaming\\Microsoft\\Word\\Startup\\*",
     "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Roaming\\Microsoft\\AddIns\\*",
     "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Roaming\\Microsoft\\Excel\\XLSTART\\*"
- )
+ ) and
+ not (file.name : "~$*" and process.name : "excel.exe" and ?file.size in (0, 165))
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc
index db810378fd..05bc0d538f 100644
--- a/docs/detections/prebuilt-rules/rule-details/persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc
@@ -37,7 +37,6 @@ Detects the successful hijack of Microsoft Compatibility Appraiser scheduled tas
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Persistence
-* Tactic: Privilege Escalation
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
 * Data Source: Windows Security Event Logs
@@ -47,7 +46,7 @@ Detects the successful hijack of Microsoft Compatibility Appraiser scheduled tas
 * Data Source: Crowdstrike
 * Resources: Investigation Guide
 
-*Version*: 317
+*Version*: 318
 
 *Rule authors*: 
 
@@ -63,47 +62,91 @@ Detects the successful hijack of Microsoft Compatibility Appraiser scheduled tas
 *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 TelemetryController Scheduled Task Hijack*
 
 
-The Microsoft Compatibility Appraiser, part of Windows telemetry, uses scheduled tasks to assess system compatibility. Adversaries exploit this by hijacking the task to execute malicious code with system-level privileges, ensuring persistence. The detection rule identifies anomalies by monitoring processes initiated by the Appraiser that deviate from expected behavior, flagging potential hijacks for further investigation.
-
 
 *Possible investigation steps*
 
 
-- Review the process tree to identify the parent process CompatTelRunner.exe and verify if it has spawned any unexpected child processes that match the alert criteria.
-- Examine the command-line arguments of the suspicious process to determine if they include the "-cv*" flag, which may indicate a hijack attempt.
-- Check the execution history of the flagged process to see if it aligns with legitimate system activities or if it appears anomalous.
-- Investigate the user account context under which the suspicious process is running to assess if it has elevated privileges or is associated with unusual user behavior.
-- Correlate the alert with other security logs and telemetry data from sources like Microsoft Defender XDR or Sysmon to identify any related malicious activities or indicators of compromise.
-- Analyze any network connections initiated by the suspicious process to detect potential data exfiltration or communication with known malicious IP addresses.
-- Review recent changes to scheduled tasks on the system to identify unauthorized modifications that could indicate persistence mechanisms.
+- What behavior path did the alert preserve from CompatTelRunner to the child?
+  - Why: "-cv" marks the TelemetryController handoff; the executable path before it is the key artifact.
+  - Focus: `process.parent.executable`, `process.command_line`, `process.executable`, `process.Ext.token.integrity_level_name`, and `user.id`.
+  - Implication: escalate when "CompatTelRunner.exe" launches a user-writable, script-hosted, renamed, or newly introduced child with SYSTEM context; lower suspicion only when the handoff resolves to a stable Microsoft telemetry component for this host, then still validate the registry state that produced it.
+
+- Does the child binary identity match the command path and expected telemetry role?
+  - Focus: `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.Ext.relative_file_creation_time`.
+  - Implication: escalate when metadata, signer, hash, or recent file age conflicts with the path or Microsoft telemetry role; lower suspicion when identity, signer, path, and age fit a stable Windows or enterprise diagnostic binary.
+
+- Which TelemetryController values enabled this launch, and which process wrote them?
+  - Focus: recovered registry events on `host.id` for TelemetryController `registry.path`, `registry.value`, `registry.data.strings`, and writer `process.executable`.
+  - Range: search back several days; the registry hijack can precede scheduled task execution.
+  - Hint: search the TelemetryController root and subkeys, compare command-like `registry.data.strings` to the alert child, and treat registry telemetry as recovery evidence; missing registry history leaves persistence unresolved. Do not clear only because startup folders or service keys are clean.
+  - Implication: escalate when a command value points to the alert child or another non-Windows binary or script and the same subkey enables execution; an unexpected writer exposes the privileged component that planted HKLM persistence. Lower suspicion only when values, writer, and child path all match one controlled diagnostic or test workflow.
+
+- Did the launched child stage or reuse artifacts that extend the persistence chain?
+  - Focus: same-process file events on `host.id` using `process.entity_id`, or `process.pid` in a tight alert window: `file.path`, `file.Ext.original.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and later `process.executable` reuse. !{investigate{"description":"","label":"File events for the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the child writes executable or scriptable content to user-writable, startup, service, or task paths, especially with external provenance or later execution; absent file telemetry does not clear a suspicious command or registry handoff.
+
+- Did the launched child contact destinations inconsistent with telemetry or the signer?
+  - Focus: same-process DNS and connection events on `host.id`: `dns.question.name`, `dns.resolved_ip`, `destination.ip`, `destination.port`, and `destination.as.organization.name`. !{investigate{"description":"","label":"Network events for the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: Missing network telemetry is unresolved, not benign. Treat infrastructure ownership as context rather than a verdict.
+  - Implication: escalate when the child reaches public, rare, or signer-misaligned infrastructure; lower suspicion when destinations consistently fit Microsoft telemetry, internal servicing, or the same verified diagnostic workflow.
+
+- If local evidence remains suspicious or unresolved, is this a local test pattern or repeated TelemetryController persistence?
+  - Focus: recent alerts for the same `process.executable` before broader host review. !{investigate{"description":"","label":"Alerts involving the same child path","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: use host alert history only after child identity, command line, registry, file, or network evidence remains suspicious or unresolved. !{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 the same child path, TelemetryController pattern, or follow-on alert chain appears on unrelated hosts; keep scope local when telemetry ties the exact child, writer, values, and host scope to one verified lab or diagnostic workflow.
+
+- Escalate when the handoff, child identity, registry writer/values, artifacts, destinations, or alert history show arbitrary or staged execution through TelemetryController; close only when the same evidence ties the exact child, writer, values, and scope to a controlled diagnostic or validation workflow; preserve artifacts and escalate when registry, file, or network evidence is missing or contradictory.
 
 
 *False positive analysis*
 
 
-- Legitimate system maintenance tasks may trigger the rule if they involve processes that are not typically associated with the Microsoft Compatibility Appraiser. Users can create exceptions for known maintenance scripts or tools that are verified as safe.
-- Software updates or installations that temporarily use unusual processes under the Appraiser's context might be flagged. Users should monitor and whitelist these processes if they are part of a trusted update or installation routine.
-- Custom scripts or administrative tools that leverage the Appraiser's context for legitimate purposes could be misidentified. Users should document and exclude these scripts from detection if they are part of regular administrative operations.
-- Security tools or monitoring software that interact with the Appraiser process for analysis or logging purposes may cause false positives. Users should ensure these tools are recognized and excluded from the detection rule to prevent unnecessary alerts.
+- Non-Microsoft TelemetryController command registration is an operational anti-pattern. Controlled image-validation or compatibility-lab workflows can still trigger this rule when they register a signed diagnostic or servicing binary. Close benign only when telemetry ties `process.command_line`, `process.executable`, `process.hash.sha256`, TelemetryController `registry.path`, `registry.data.strings`, writer `process.executable`, and the `host.id` cohort to the same build or lab workflow. Use records only as corroboration; before exceptioning, validate recurrence for the same payload identity, writer, value pattern, and lab-host scope.
+- Authorized adversary-emulation or detection-validation tests can deliberately hijack TelemetryController. Close benign only when `process.command_line`, `process.hash.sha256`, TelemetryController `registry.path`, expected `host.id` or `user.id` test scope, and registry-writing `process.executable` all match exercise telemetry. Use engagement records only as corroboration; before exceptioning, verify the same payload hash or path and writer recur only on known test assets and not unrelated production hosts. Do not exception on `process.parent.name`, "CompatTelRunner.exe", "-cv", or `process.name` alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Terminate any suspicious processes identified by the detection rule that are not part of the expected process list, such as those not matching "conhost.exe", "DeviceCensus.exe", "CompatTelRunner.exe", "DismHost.exe", "rundll32.exe", or "powershell.exe".
-- Review and restore the integrity of the Microsoft Compatibility Appraiser scheduled task by resetting it to its default configuration to ensure it is not executing unauthorized code.
-- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or software.
-- Analyze the system for any unauthorized changes to user accounts or privileges, and revert any modifications to ensure that only legitimate users have 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 the affected system and similar scheduled tasks across the network to detect any future attempts at hijacking or unauthorized modifications.
+- If confirmed benign:
+  - Record the TelemetryController `registry.path`, child `process.executable` or `process.hash.sha256`, writer `process.executable`, host scope, and telemetry that proved the workflow, then reverse any temporary containment. Build exceptions from that minimum pattern plus `host.id`, not from `process.parent.name`, "CompatTelRunner.exe", or "-cv" alone.
+- If suspicious but unconfirmed:
+  - Preserve the alert process record, recovered TelemetryController registry events, writer lineage, written `file.path` artifacts, and any `dns.question.name` or `destination.ip` indicators before cleanup.
+  - Apply reversible containment tied to the findings, such as temporarily disabling the suspect TelemetryController subkey or blocking the child binary or destination. Escalate to host isolation only when host criticality allows it and same-process artifacts or destinations show active follow-on behavior.
+- If confirmed malicious:
+  - Isolate the host and terminate the malicious child only after recording the child process identity, command line, TelemetryController values, writer lineage, written `file.path`, `process.hash.sha256`, and destination indicators. If direct endpoint response is unavailable, escalate with that evidence set to the team that can contain the asset.
+  - Remove the malicious TelemetryController subkey or restore its values to known-good state, then remove only the payloads and additional persistence artifacts identified during the investigation. Validate that the "Microsoft Compatibility Appraiser" task no longer launches the malicious child, and scope other hosts for the same child path or registry pattern before deleting artifacts.
+- Post-incident hardening:
+  - Restrict local admin rights on exposed hosts, keep process, registry, file, and network telemetry for this key family enabled, and record any TelemetryController visibility gaps in the case notes.
+
+
+==== 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
 
diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-update-orchestrator-service-hijack.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-update-orchestrator-service-hijack.asciidoc
index ba219b3557..05f738a5b1 100644
--- a/docs/detections/prebuilt-rules/rule-details/persistence-via-update-orchestrator-service-hijack.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-update-orchestrator-service-hijack.asciidoc
@@ -36,7 +36,6 @@ Identifies potential hijacking of the Microsoft Update Orchestrator Service to e
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Persistence
-* Tactic: Privilege Escalation
 * Use Case: Vulnerability
 * Resources: Investigation Guide
 * Data Source: Elastic Endgame
@@ -46,7 +45,7 @@ Identifies potential hijacking of the Microsoft Update Orchestrator Service to e
 * Data Source: Windows Security Event Logs
 * Data Source: SentinelOne
 
-*Version*: 318
+*Version*: 319
 
 *Rule authors*: 
 
@@ -66,59 +65,89 @@ Identifies potential hijacking of the Microsoft Update Orchestrator Service to e
 *Investigating Persistence via Update Orchestrator Service Hijack*
 
 
-Windows Update Orchestrator Service is a DCOM service used by other components to install Windows updates that are already downloaded. Windows Update Orchestrator Service was vulnerable to elevation of privileges (any user to local system) due to an improper authorization of the callers. The vulnerability affected the Windows 10 and Windows Server Core products. Fixed by Microsoft on Patch Tuesday June 2020.
 
-This rule will detect uncommon processes spawned by `svchost.exe` with `UsoSvc` as the command line parameters. Attackers can leverage this technique to elevate privileges or maintain persistence.
+*Possible investigation steps*
 
-> **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.
 
+- What did UsoSvc actually launch, and does the child identity fit Windows or Office servicing?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Hint: use `process.parent.command_line` to confirm svchost is hosting UsoSvc, not just sharing the name.
+  - Implication: escalate when UsoSvc launches a renamed, user-writable, unsigned, rare, or non-servicing child; lower concern only when path, signer, and parent service context match a recognized Windows Update or Click-to-Run component. Identity alone does not clear it.
 
-*Possible investigation steps*
+- Does the command line show attacker-controlled work running with service-level privilege?
+  - Why: on unpatched hosts, CVE-2020-1313 ScheduleWork can queue signed System32 or Common Files binaries with attacker-controlled arguments.
+  - Focus: `process.command_line`, `process.Ext.token.integrity_level_name`, and `user.id`.
+  - Implication: escalate when "cmd.exe", "rundll32.exe", "regsvr32.exe", a scripting host, or another signed binary runs shell, download, staging, redirection, or persistence arguments under SYSTEM or high integrity; lower concern when arguments fit the exact servicing binary workflow.
+
+- If registry telemetry is available, was matching work queued under the Update Orchestrator UScheduler path?
+  - Focus: same `host.id` registry events for `registry.path` under "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Orchestrator\UScheduler", with `registry.value`, `registry.data.strings`, and writer `process.executable`.
+  - Range: search several days before the alert; queued work can run overnight or after a multi-day service window.
+  - Hint: interpret queued strings with `registry.data.type`, then compare them to `process.command_line` and `process.executable`; missing registry telemetry is unresolved, not benign.
+  - Implication: escalate when the queue names the same unusual child or arguments, especially from a non-servicing writer; absent queue history only limits this corroborator.
 
+- Did the child stage artifacts or spawn follow-on processes that extend the abuse?
+  - Focus: child starts from `process.entity_id`; if file telemetry exists, same-process `file.path`, `file.Ext.original.path`, and `file.origin_url`.
+    - !{investigate{"description":"","label":"Child process starts from the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"File events for the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: scope file pivots with `host.id` plus `process.entity_id`; use `host.id` plus `process.pid` and a tight alert window only when entity ID is absent. Missing file telemetry limits artifact review, but child-process and command evidence can justify escalation.
+  - Implication: escalate when the child writes executable or scriptable content to user-writable or deceptive paths, renames staged content, or launches written artifacts; lower concern when activity stays inside the recognized servicing path with no follow-on execution.
 
-- 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 any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes.
-- 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.
-- Examine the host for derived artifacts that indicate suspicious activities:
-  - Analyze the process executable using a private sandboxed analysis system.
-  - Observe and collect information about the following activities in both the sandbox and the alert subject host:
-    - Attempts to contact external domains and addresses.
-      - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.
-      - Examine the DNS cache for suspicious or anomalous entries.
-        - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}}
-    - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
-    - Examine the host services for suspicious or anomalous entries.
-      - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}}
-      - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}}
-      - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}}
-  - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
-- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.
+- If network telemetry is available, does the child contact destinations consistent with servicing?
+  - Focus: process-scoped DNS `dns.question.name` and `dns.resolved_ip`, then connections by `destination.ip`, `destination.port`, and `destination.as.organization.name`. !{investigate{"description":"","label":"Network events for the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: use "lookup_result" DNS events for populated `dns.resolved_ip`; scope with `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` and a tight alert window. Infrastructure ownership is context, not a verdict; missing network telemetry is unresolved, not benign.
+  - Implication: escalate when the child reaches rare or public infrastructure unrelated to Microsoft servicing, the signer, or recovered queue; lower concern when destinations fit the signed binary's normal update or repair endpoints.
 
+- If local evidence remains suspicious or unresolved, do related alerts change scope?
+  - Focus: compare recent alerts for the same `process.executable`. !{investigate{"description":"","label":"Alerts involving the same child executable","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: review same `host.id` alerts only when child identity, command, queue, artifact, or destination evidence needs scope. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same child path or host shows repeated privilege-escalation, persistence, staging, or follow-on alerts; keep urgency local when isolated and no corroborating alert history appears.
+
+- Escalate on attacker-controlled UsoSvc child identity or command intent, using queue, artifact, destination, or related-alert evidence as corroboration; close only when alert-local and recovered evidence tie to one exact servicing or authorized validation workflow without contradictions; preserve artifacts and escalate when evidence is mixed, incomplete, or unavailable.
 
 
 *False positive analysis*
 
 
-- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+- Windows Update, repair, or Office Click-to-Run servicing can trigger this rule when UsoSvc queues a servicing component outside the exclusions. Close from telemetry first: child path, signer, command line, parent service context, UScheduler queue content when available, artifacts, destinations, and `host.id` cohort must align with one recognized servicing workflow. Patch-window or change records may corroborate; prior alerts only prove exception stability after current evidence fits.
+- Authorized exploit-validation or adversary-emulation tests can exercise Update Orchestrator abuse. Confirm stable payload identity such as `process.hash.sha256`, `process.command_line`, expected `host.id` or `user.id` test scope, matching queue content when available, and no spread to unrelated production hosts. Use engagement records or prior test alerts only as corroboration, and do not exception on `process.parent.executable`, "UsoSvc", or `process.name` alone.
 
 
 *Response and remediation*
 
 
-- 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).
+- If confirmed benign:
+  - Record the exact evidence that proved the servicing or test workflow: child identity, command line, parent service context, queue content when available, same-process artifacts or destinations, and recurrence or records. Then reverse temporary containment and build any exception from that minimum pattern plus `host.id`, not from UsoSvc or a generic signed-binary condition.
+- If suspicious but unconfirmed:
+  - Preserve a case export with the alert process instance, process tree, command line, UScheduler queue values when available, writer-process details, written artifacts, destination indicators, and related-alert context before cleanup.
+  - Apply reversible containment tied to the finding, such as blocking the child hash or destination, temporarily disabling the queued work after preservation, or increasing host monitoring. Escalate to host isolation only when host criticality allows it and artifacts, destinations, or related alerts show active follow-on behavior.
+- If confirmed malicious:
+  - Preserve the case export first: child `process.entity_id` or `process.pid`, command line, queue values, writer lineage, payload hashes, artifact paths, and destination indicators. Then isolate the host when the identity, command, queue, artifact, or destination evidence confirms unauthorized UsoSvc execution.
+  - Remove the malicious queued work or restore the Update Orchestrator registry state to known-good, eradicate only payloads and persistence artifacts identified during triage, validate that UsoSvc returns to recognized servicing children, and review other hosts for the same child path or queue pattern before deleting preserved evidence.
+- Post-incident hardening:
+  - Apply the June 2020 or later Windows security updates where still applicable because the fix blocks untrusted caller queuing, retire unsupported builds, restrict write paths that can feed Update Orchestrator abuse, and retain registry/process telemetry for UScheduler queue changes.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+- https://ela.st/audit-process-creation[Windows Process Creation Logs]
 
 
 ==== Rule query
@@ -176,3 +205,7 @@ process where host.os.type == "windows" and event.type == "start" and
 ** Name: Exploitation for Privilege Escalation
 ** ID: T1068
 ** Reference URL: https://attack.mitre.org/techniques/T1068/
+* Technique:
+** Name: Hijack Execution Flow
+** ID: T1574
+** Reference URL: https://attack.mitre.org/techniques/T1574/
diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-wmi-standard-registry-provider.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-wmi-standard-registry-provider.asciidoc
index 760161ae0a..0180ccfaf5 100644
--- a/docs/detections/prebuilt-rules/rule-details/persistence-via-wmi-standard-registry-provider.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-wmi-standard-registry-provider.asciidoc
@@ -22,7 +22,7 @@ Identifies use of the Windows Management Instrumentation StdRegProv (registry pr
 
 *References*: 
 
-* https://docs.microsoft.com/en-us/previous-versions/windows/desktop/regprov/stdregprov
+* https://learn.microsoft.com/en-us/previous-versions/windows/desktop/regprov/stdregprov
 * https://www.elastic.co/security-labs/hunting-for-persistence-using-elastic-security-part-1
 
 *Tags*: 
@@ -35,7 +35,7 @@ Identifies use of the Windows Management Instrumentation StdRegProv (registry pr
 * Data Source: Elastic Defend
 * Resources: Investigation Guide
 
-*Version*: 113
+*Version*: 114
 
 *Rule authors*: 
 
@@ -55,59 +55,75 @@ Identifies use of the Windows Management Instrumentation StdRegProv (registry pr
 *Investigating Persistence via WMI Standard Registry Provider*
 
 
-The Windows Management Instrumentation (WMI) StdRegProv is a registry provider that allows users to manage registry keys and values on Windows systems. Adversaries may abuse this functionality to modify registry locations commonly used for persistence, enabling them to maintain unauthorized access to a system.
+*Possible investigation steps*
 
-This rule identifies instances where the WMI StdRegProv is used to modify specific registry paths associated with persistence mechanisms.
 
-> **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.
+- Which StdRegProv-backed persistence value changed, and what will it run?
+  - Why: StdRegProv can set logon and service ASEPs through "WmiPrvSe.exe" without a child process from the requester; registry value data is the payload clue.
+  - Focus: `registry.path`, `registry.value`, `registry.data.type`, and `registry.data.strings`.
+  - Implication: escalate when machine-wide Run/RunOnce, Winlogon shell, policy script, "ServiceDLL", or "ImagePath" values launch user-writable, share-hosted, script-host, shell-replacement, or unusual service content; lower suspicion only when the exact value and data match a recognized WMI-based deployment, configuration, or test workflow.
 
+- Who is the logical requester behind the WMI provider host?
+  - Why: `process.executable` usually identifies the provider host; effective process fields can identify the StdRegProv requester.
+  - Focus: `Effective_process.executable`, `Effective_process.name`, `Effective_process.entity_id`, `process.executable`, and `process.entity_id`.
+  - Hint: do not clear on the Microsoft-signed provider host alone; attacker and admin tooling can both route registry writes through "WmiPrvSe.exe".
+  - Implication: escalate when the requester is blank with suspicious value data, or is a script host, user-writable binary, Office/browser descendant, or unexpected remote administration tool; lower suspicion when requester path and name match the management or deployment component that owns the value.
 
-*Possible investigation steps*
+- Does the launch and session context fit the expected WMI workflow?
+  - Focus: `process.command_line`, `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, and `user.id`.
+  - Implication: escalate when WMI registry writes occur under an unexpected user, service, remote, or parent context; lower suspicion when parent chain, session type, and user scope match the same recognized management or validation workflow.
+
+- Did the payload referenced by the modified value execute?
+  - Focus: same-host process starts after `@timestamp` where `process.command_line` matches the payload from `registry.data.strings`. !{investigate{"description":"","label":"Process starts matching the modified registry payload","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.command_line","queryType":"phrase","value":"{{registry.data.strings}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}}
+  - Hint: empty results do not prove non-execution; quoting, environment expansion, or arguments may require manual parsing.
+  - Implication: escalate when the payload launches after the WMI-backed registry change, especially from user-writable, share-hosted, service, shell, or script paths; keep unresolved when value data cannot be matched directly.
+
+- Did the same requester cluster additional persistence changes on this host?
+  - Why: clustered ASEP writes separate one managed configuration change from service-plus-logon fallback persistence.
+  - Focus: same-host registry changes by `Effective_process.entity_id`, or `process.entity_id` when the effective requester is blank, reviewing `registry.path`, `registry.value`, and `registry.data.strings`. !{investigate{"description":"","label":"Registry changes by the same effective requester","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"Effective_process.entity_id","queryType":"phrase","value":"{{Effective_process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the same requester changes multiple ASEPs, service values, shell values, or policy scripts in one timeline; lower suspicion when activity is limited to one exact value with data matching the recognized workflow.
 
+- If local evidence remains suspicious or unresolved, does the requester or host recur in recent alerts?
+  - Focus: recent alerts for `Effective_process.executable`. !{investigate{"description":"","label":"Alerts involving the same effective requester path","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"Effective_process.executable","queryType":"phrase","value":"{{Effective_process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: run the host alert view only after the registry target, requester, session, or same-host registry cluster remains suspicious or unresolved. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the requester path or host shows repeated WMI abuse, persistence changes, or related execution alerts; keep local when recurrence is absent and local evidence supports a recognized workflow.
 
-- 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.
-- Validate if the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.
-- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
-- Identify which process triggered this behavior.
-- Verify whether the file specified in the run key is signed.
-- Examine the host for derived artifacts that indicate suspicious activities:
-  - Examine the file specified in the run key using a private sandboxed analysis system.
-  - Observe and collect information about the following activities in both the sandbox and the alert subject host:
-    - Attempts to contact external domains and addresses.
-      - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.
-      - Examine the DNS cache for suspicious or anomalous entries.
-        - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}}
-    - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
-    - Examine the host services for suspicious or anomalous entries.
-      - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}}
-      - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}}
-      - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}}
-  - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
+- Escalate for unrecognized or blank requester with suspicious value data, unexpected remote/service context, clustered ASEP changes, execution, or alert recurrence; close only when modified ASEP, value data, requester, process/session context, cluster, and recurrence evidence bind one recognized management or test workflow with no contradictory registry data; preserve evidence and escalate if mixed or incomplete.
 
 
 *False positive analysis*
 
 
-- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+- Configuration managers, endpoint-management agents, installers, and hardening baselines can use StdRegProv to set Run keys, policy scripts, or service values. Confirm `Effective_process.executable`, `Effective_process.name`, parent context, registry path/value/data, and host or user scope converge on the same workflow. Use change records, owner confirmation, or tool inventory when available; otherwise require the same requester path, modified ASEP, and registry data pattern to recur across prior alerts from this rule on the same managed host cohort.
+- Authorized security testing or detection validation can write persistence values through StdRegProv. Confirm the expected requester, exact value, value data, parsed payload path, test scope, and engagement records when available. Without records, require recurrence only on known test assets and no appearance on unrelated production hosts. Do not exception on `process.name`, "WmiPrvSe.exe", or a broad ASEP family alone.
+
+
+*Response and remediation*
+
+
+- If confirmed benign:
+  - Reverse temporary containment and document the requester identity, exact registry value and data, host or user scope, and the recurrence or records that proved the management or test workflow. Build exceptions from that minimum pattern, not from "WmiPrvSe.exe", `process.name`, or a broad registry key alone.
+- If suspicious but unconfirmed:
+  - Preserve the alert event, exact registry value and data, effective requester identifiers, parsed payload path from the value data, and same-requester registry timeline before changing host state.
+  - Apply reversible containment tied to the evidence, such as disabling the exact Run, policy, shell, or service value, blocking the requester path, or increasing monitoring on the affected host. Use host isolation only when host criticality allows it and the registry or requester evidence shows active persistence risk.
+- If confirmed malicious:
+  - Isolate the host after preserving the registry evidence, requester identifiers, parsed payload paths, and same-requester registry changes that established malicious activity; contain the affected account only when process or session evidence supports account misuse.
+  - Terminate the requester process only after recording the relevant entity or PID, then remove the malicious Run key, shell value, policy script, "ServiceDLL", or "ImagePath" change, restore the ASEP to known-good state, and remove only the payloads identified from the investigation.
+  - Review other hosts for the same requester path or registry pattern before deleting artifacts that may be needed for scoping.
+- Post-incident hardening:
+  - Restrict unnecessary WMI and remote administration access, monitor WMI-hosted writes to high-value ASEPs, keep endpoint process and registry telemetry enabled, and document any visibility gaps surfaced during triage.
 
 
-*Response and Remediation*
+==== Setup
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Isolate the involved host to prevent further post-compromise behavior.
-- If the triage identified malware, search the environment for additional compromised hosts.
-  - Implement temporary network rules, procedures, and segmentation to contain the malware.
-  - Stop suspicious processes.
-  - Immediately block the identified indicators of compromise (IoCs).
-  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
-- Remove and block malicious artifacts identified during triage.
-- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
-- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
-- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+
+*Setup*
+
+
+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
@@ -177,18 +193,6 @@ registry where host.os.type == "windows" and event.type == "change" and
 ** ID: TA0003
 ** Reference URL: https://attack.mitre.org/tactics/TA0003/
 * Technique:
-** Name: Boot or Logon Initialization Scripts
-** ID: T1037
-** Reference URL: https://attack.mitre.org/techniques/T1037/
-* Sub-technique:
-** Name: Logon Script (Windows)
-** ID: T1037.001
-** Reference URL: https://attack.mitre.org/techniques/T1037/001/
-* Technique:
-** Name: Modify Registry
-** ID: T1112
-** Reference URL: https://attack.mitre.org/techniques/T1112/
-* Technique:
 ** Name: Create or Modify System Process
 ** ID: T1543
 ** Reference URL: https://attack.mitre.org/techniques/T1543/
diff --git a/docs/detections/prebuilt-rules/rule-details/possible-fin7-dga-command-and-control-behavior.asciidoc b/docs/detections/prebuilt-rules/rule-details/possible-fin7-dga-command-and-control-behavior.asciidoc
index 5a68739b74..2cb8f9b0c3 100644
--- a/docs/detections/prebuilt-rules/rule-details/possible-fin7-dga-command-and-control-behavior.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/possible-fin7-dga-command-and-control-behavior.asciidoc
@@ -35,7 +35,7 @@ This rule detects a known command and control pattern in network events. The FIN
 * Data Source: PAN-OS
 * Resources: Investigation Guide
 
-*Version*: 109
+*Version*: 110
 
 *Rule authors*: 
 
@@ -59,7 +59,7 @@ In the event this rule identifies benign domains in your environment, the `desti
 [source, js]
 ----------------------------------
 (data_stream.dataset: (network_traffic.tls OR network_traffic.http) OR
-    (event.category: (network OR network_traffic) AND type: (tls OR http) AND network.transport: tcp)) AND
+    (event.category: (network OR network_traffic) AND network.protocol: (tls OR http) AND network.transport: tcp)) AND
 destination.domain:/[a-zA-Z]{4,5}\.(pw|us|club|info|site|top)/ AND NOT destination.domain:zoom.us
 
 ----------------------------------
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-command-shell-via-netcat.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-command-shell-via-netcat.asciidoc
index 67c805fb23..87cdacca84 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-command-shell-via-netcat.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-command-shell-via-netcat.asciidoc
@@ -30,7 +30,7 @@ Identifies potential attempt to execute via a reverse shell using the netcat uti
 * Resources: Investigation Guide
 * Data Source: Elastic Defend
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -50,40 +50,68 @@ Identifies potential attempt to execute via a reverse shell using the netcat uti
 *Investigating Potential Command Shell via NetCat*
 
 
-Attackers may abuse the NetCat utility to execute commands remotely using the builtin Windows Command Shell interpreters.
-
 
 *Possible investigation steps*
 
 
-- Verify if the user is authorized to use the Netcat utility.
-- Investigate the process execution chain (parent process tree) and how the netcat binary was dropped.
-- Review the network connections made by the parent process and check their reputation.
-- Investiguate all child processes spawned by the Cmd or Powershell instance.
-- Examine the host for other alerts within the same period.
+- Which remote-shell mode does the alert-local process evidence show?
+  - Focus: `process.parent.command_line`, `process.parent.args_count`, and `process.name`.
+  - Implication: escalate when "-e" wires "cmd.exe" or "powershell.exe" to an explicit IP, unusual port, or "-l"/"-p" listener; lower concern only when shell mode, port or destination, and child shell match a known lab, red-team, or break-glass workflow.
+
+- Does the parent binary identity fit a recognized NetCat-family tool instead of a renamed payload?
+  - Focus: `process.parent.executable`, `process.parent.name`, and code signature.
+  - Implication: escalate when the parent is unsigned, renamed, or runs from temp, downloads, archives, shares, or another user-writable path; identity lowers concern only when path and signer fit the same controlled tool, and never clears the `-e` shell behavior by itself.
+
+- Do recovered parent network events confirm a connect-back destination or exposed listener?
+  - Focus: network events on `host.id` for `process.parent.entity_id`; separate DNS `dns.question.name` from `destination.ip`, `destination.port`, and `network.direction`. !{investigate{"description":"","label":"Network events for the netcat parent process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: network fields come from endpoint network events, not the process alert; compare any command-line IP or port with recovered connections.
+  - Implication: escalate when recovered connections confirm a public or unexpected destination, or a listener is exposed on an unexpected asset; missing network telemetry is unresolved, not benign.
+
+- Did the spawned shell launch operator commands after start?
+  - Focus: child process starts where `process.parent.entity_id` matches the spawned shell `process.entity_id`; review `process.name`, `process.executable`, and `process.command_line`. !{investigate{"description":"","label":"Descendant processes from the spawned shell","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 descendants show reconnaissance, credential, download, persistence, staging, lateral movement, or cleanup; no descendants weakens operator-control evidence but does not make the remote-shell pattern benign.
+
+- Does the user and host context support the shell exposure?
+  - Focus: `user.id`, `user.name`, `host.id`, `host.name`, and `process.parent.command_line`.
+  - Implication: escalate when user-host pairing or account identity conflicts with expected testing or emergency use; lower concern only when the same user, host, and parent command fit one bounded authorized activity.
+
+- If local evidence is suspicious or unresolved, do surrounding alerts expand the scope?
+  - Focus: alerts for the same `user.id`, especially execution, defense-evasion, persistence, credential-access, lateral-movement, or command-and-control tied to the same parent command or recovered destination. !{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: also check the same `host.id` to decide whether this remains one process on one asset or part of a broader compromise. !{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 response scope when surrounding alerts share the user, host, parent command, or recovered destination pattern; keep triage local when no corroborating alerts appear after the parent, network, and descendant checks.
+
+- What disposition is supported by shell mode, parent identity, descendant commands, network recovery, user-host context, and alert scope?
+  - Focus: synthesize shell mode, parent identity, descendants, network recovery, user-host context, and alert scope.
+  - Implication: escalate on alert-local "-e" behavior plus any corroborator: unrecognized parent, external or exposed network evidence, operator descendants, user-host conflict, or related alerts. Close only when all categories bind to one authorized security-testing or break-glass activity with no contradictions; if telemetry cannot prove legitimacy, require outside confirmation. Preserve artifacts and escalate when evidence is mixed or visibility is incomplete.
 
 
 *False positive analysis*
 
 
-- IT Support or system amdinistrator authorized activity using NetCat.
+- NetCat "-e" shells are an operational anti-pattern outside confirmed security testing or break-glass support. Confirm benign use only when parent path and signer, exact parent command, shell mode, child shell, recovered destination or listen-port evidence, `user.id`, and `host.id` all align to the same bounded workflow. Use schedules, tickets, or owner confirmation only to corroborate that telemetry-matched activity; without them, require telemetry-only confirmation that the same user, host, parent command, and destination or port pattern recur for this rule. Any mismatch keeps the alert suspicious.
+- Before creating an exception, validate stability across prior alerts for the same `user.id` and `host.id`. Anchor the exception on `process.parent.executable`, `process.parent.command_line`, child `process.command_line`, user/host scope, and recovered destination or listen-port pattern. Avoid exceptions on `process.name`, parent basename, or shell name alone.
 
 
 *Response and remediation*
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Isolate the involved host to prevent further post-compromise behavior.
-- If the triage identified malware, search the environment for additional compromised hosts.
-  - Implement temporary network rules, procedures, and segmentation to contain the malware.
-  - Stop suspicious processes.
-  - Immediately block the identified indicators of compromise (IoCs).
-  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
-- Remove and block malicious artifacts identified during triage.
-- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
-- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
-- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+- If confirmed benign, reverse any temporary containment and document the parent identity, exact command, shell mode, child shell, user/host scope, and recovered destination or listen-port evidence that proved the workflow. Create an exception only if that same workflow is stable across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve volatile state and case exports first: parent and child process entity IDs, command lines, descendant commands, parent binary path and signer, and recovered network indicators. Apply reversible containment tied to the findings, such as temporary destination blocks, firewall control of the exposed listener, or host isolation when interactive control or broader scope is likely and the host can tolerate it. Avoid process termination or deletion until evidence capture is complete.
+- If confirmed malicious, first record `process.parent.entity_id`, `process.entity_id`, parent and child command lines, descendant commands, and recovered network indicators. Then isolate the host as appropriate, block recovered destination, domain, IP, or port indicators, and terminate the NetCat parent, spawned shell, and malicious descendants after evidence capture. Reset credentials only when descendant commands, user-host context, or related alerts show credential or administrator-command exposure.
+- Eradicate only artifacts found during the investigation: the NetCat binary or script wrapper, staged payloads, persistence, service or listener configuration, tunnels, and cleanup scripts. Then remediate the delivery path that placed the tool on the host.
+- Post-incident hardening: restrict unauthorized NetCat-family binaries and "-e" shell usage, retain process and network telemetry, and document adjacent variants such as renamed utilities, relay mode without "-e", or delayed shell handoff in the case record for future response.
+
+
+==== 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
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc
new file mode 100644
index 0000000000..6df7f6d5be
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc
@@ -0,0 +1,186 @@
+[[potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940]]
+=== Potential cPanel WHM CRLF Authentication Bypass (CVE-2026-41940)
+
+Identifies the network signature of CVE-2026-41940, a pre-auth root-level authentication bypass in cPanel and WebHost Manager (WHM) caused by a CRLF injection in the session writer. The exploit-inherent shape on the wire is a `GET /` request to a cPanel/WHM admin port (typically TCP/2087, 2086, 2083, 2082, 2095, 2096) carrying an `Authorization: Basic` header whose base64-decoded value contains CRLF-injected session fields, which causes cpsrvd to respond with a 3xx redirect whose `Location` header leaks a `/cpsessNNNNNNNNNN` token granting the attacker a privileged session. This is the network-layer equivalent of the cPanel `access_log` artifact identified by Unfold and watchTowr as the first bulletproof detection for this CVE: a `GET /` recorded with `auth_method=b` (HTTP Basic). Legitimate access to `GET /` on a WHM admin port returns 200 with the login screen and never includes HTTP Basic credentials, so this combination is not produced by normal use.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* packetbeat-*
+* logs-network_traffic.http*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.unfold.ai/blog/cpanel-exploit-cve-2026-41940
+* https://labs.watchtowr.com/the-internet-is-falling-down-falling-down-falling-down-cpanel-whm-authentication-bypass-cve-2026-41940/
+* https://www.picussecurity.com/resource/blog/cve-2026-41940-explained-cpanel-whm-authentication-bypass-hit-1-5m-servers
+* https://support.cpanel.net/hc/en-us/articles/40073787579671-Security-CVE-2026-41940-cPanel-WHM-WP2-Security-Update-04-28-2026
+* https://nvd.nist.gov/vuln/detail/CVE-2026-41940
+* https://docs.cpanel.net/knowledge-base/cpanel-product/the-cpanel-log-files
+* https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-http-options.html#_send_all_headers
+
+*Tags*: 
+
+* Domain: Network
+* Domain: Application
+* Domain: Web
+* Use Case: Threat Detection
+* Use Case: Vulnerability
+* Tactic: Initial Access
+* Data Source: Network Packet Capture
+* Data Source: Network Traffic
+* 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 cPanel WHM CRLF Authentication Bypass (CVE-2026-41940)*
+
+
+CVE-2026-41940 is a critical (CVSS 9.8) authentication bypass in cPanel & WHM that gives an unauthenticated attacker
+a root-privileged session on the host. The exploit chains a CRLF injection in the session writer with an
+encryption-skip triggered by a malformed cookie, then uses how cPanel caches sessions to promote the injected data
+into a privileged login. Around 1.5M cPanel instances were exposed at disclosure and exploitation has been observed in
+the wild since 2026-02-23, two months before the patch.
+
+This rule fires on the Stage 2 request/response shape: a `GET /` to a cPanel admin port that carries an
+`Authorization: Basic` header and receives a 3xx redirect whose `Location` points at a freshly minted
+`/cpsessNNNNNNNNNN` path. Per the watchTowr and Unfold writeups, this is the only request shape that lets the
+exploit retrieve the security token needed for Stage 4 (privileged use of the session).
+
+
+*Detection logic*
+
+
+The rule requires all of the following on a single decoded HTTP transaction matched from
+`data_stream.dataset:network_traffic.http` (or `event.category:network_traffic` with `network.protocol:http`):
+
+- `http.request.method:GET` and `url.path:"/"` — request targets the root path exactly. The CRLF vulnerability is only
+  reachable on `GET /`; the same payload on other paths does not return the redirect that leaks the token, so the
+  match is intentionally exact (a request like `GET /index.html` will not fire).
+- `destination.port:(2087 OR 2086 OR 2083 OR 2082 OR 2095 OR 2096)` — cPanel/WHM admin and webmail ports. These are
+  not in the default Network Packet Capture HTTP port list and must be added explicitly (see Setup).
+- `http.response.status_code:[300 TO 399]` — a redirect response. Normal `GET /` to WHM returns 200 with the login
+  screen; only the exploit produces a 3xx here.
+- `http.request.headers.authorization:Basic*` — HTTP Basic credentials sent on `GET /`. This is the network-layer
+  equivalent of the `auth_method=b` flag the Unfold and watchTowr writeups identify as the first bulletproof artifact
+  in cPanel's `access_log`. `GET /` is an unauthenticated endpoint in normal cPanel operation and never legitimately
+  carries Basic auth.
+- `http.response.headers.location:/cpsess*` — the response redirects to a `/cpsess`-prefixed path, leaking the CSRF
+  token the attacker needs for Stage 4. This is what makes the exploit succeed and is not produced by any benign flow.
+
+
+*Possible investigation steps*
+
+
+- Capture the alert evidence. Record `source.ip` (attacker), `destination.ip` (cPanel host), `destination.port`,
+  `user_agent.original`, `http.response.status_code`, the exact `http.response.headers.location` value (which contains
+  the leaked `cpsess` token), and the captured `http.request.headers.authorization` value.
+- Decode the Authorization header to confirm the CRLF payload. Strip the leading `Basic ` from
+  `http.request.headers.authorization` and base64-decode the remainder. A legitimate Basic credential decodes to
+  `username:password`; the exploit's payload decodes to a multi-line block delimited by `\r\n` containing fields like
+  `successful_internal_auth_with_timestamp=`, `tfa_verified=1`, and `hasroot=1`. CRLF bytes in the decoded value
+  distinguish exploitation from a misconfigured Basic-auth client.
+- Confirm the destination host runs cPanel/WHM. Identify the installed version and whether the 2026-04-28 emergency
+  patch is applied.
+- Pivot on the source IP across the host's `/usr/local/cpanel/logs/access_log`. The exploit-inherent log artifact is a
+  request line of the form `"GET / HTTP/1.1" 3xx 0 "-" "<UA>" "b" "-" <port>` — `auth_method=b` on `GET /` should never
+  occur in normal operation and corresponds 1:1 to the `http.request.headers.authorization:Basic*` clause in this rule.
+- Look for the Stage 4 follow-on from the same source IP: a request to the leaked `cpsess` path
+  (`/cpsessNNNNNNNNNN/...`) with `auth_method=s` (session) and HTTP 200, without a preceding successful login
+  (form POST `/login`, `/openid_connect/`, or reseller `?session=`). This is the post-exploitation artifact.
+- Identify whether privileged WHM API actions were invoked under the leaked `cpsess` token (account creation, package
+  install, file manager writes, terminal API).
+- Review egress from the host for outbound connections initiated after the alert that could indicate web shell or
+  implant install.
+
+
+*False positive analysis*
+
+
+- Legitimate WHM administration never produces `GET /` with HTTP Basic authentication and a 3xx redirect leaking a
+  fresh `cpsess` token. This combination is exploit-inherent.
+- Authorized vulnerability scans running CVE-2026-41940 plugins will reproduce the request shape.
+
+
+*Response and remediation*
+
+
+- Apply the cPanel emergency patch released 2026-04-28 (or the WP Squared equivalent). Verify by checking the
+  installed cPanel version against the advisory.
+- If the alert is paired with an `auth_method=s` `cpsess` request (post-exploitation), assume host compromise:
+  rotate root credentials, audit `/var/cpanel/sessions/`, look for newly created accounts, scheduled tasks, SSH keys,
+  and `authorized_keys` modifications.
+- Restrict access to cPanel admin ports (2087/2086/2083/2082/2095/2096) to known administrator source IPs at the
+  perimeter or via host firewall.
+- Block the source IP at the WAF or perimeter if exploitation is confirmed.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires HTTP traffic decoded by the Network Packet Capture integration (or legacy Packetbeat) with cPanel
+admin ports added to the HTTP protocol configuration and `send_all_headers` enabled, so that
+`http.request.headers.authorization` and `http.response.headers.location` are populated. cPanel admin ports
+(2087/2086/2083/2082/2095/2096) are not in the default HTTP port list and must be added explicitly. Because cPanel
+admin traffic is normally TLS, the sensor needs decryption visibility (TLS interception, sidecar on the host, or
+sensor on the management network upstream of TLS termination) for this rule to observe HTTP fields.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+(data_stream.dataset:network_traffic.http OR (event.category:network_traffic AND network.protocol:http)) AND
+http.request.method:GET AND
+url.path:"/" AND
+destination.port:(2087 OR 2086 OR 2083 OR 2082 OR 2095 OR 2096) AND
+http.response.status_code>=300 and http.response.status_code < 400 AND
+http.request.headers.authorization:Basic* AND
+http.response.headers.location:/cpsess*
+
+----------------------------------
+
+*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/rule-details/potential-cve-2025-33053-exploitation.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-cve-2025-33053-exploitation.asciidoc
index f41781d80e..08b9e3072d 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-cve-2025-33053-exploitation.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-cve-2025-33053-exploitation.asciidoc
@@ -1,7 +1,7 @@
 [[potential-cve-2025-33053-exploitation]]
 === Potential CVE-2025-33053 Exploitation
 
-Identifies a suspicious Diagnostics Utility for Internet Explorer child process. This may indicate the successful exploitation of the vulnerability CVE-2025-33053.
+Identifies Internet Explorer Diagnostics launching a helper name from a non-System32 path, which may indicate CVE-2025-33053 exploitation.
 
 *Rule type*: eql
 
@@ -35,7 +35,6 @@ Identifies a suspicious Diagnostics Utility for Internet Explorer child process.
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Initial Access
-* Tactic: Defense Evasion
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
 * Data Source: Sysmon
@@ -43,7 +42,7 @@ Identifies a suspicious Diagnostics Utility for Internet Explorer child process.
 * Data Source: SentinelOne
 * Resources: Investigation Guide
 
-*Version*: 3
+*Version*: 4
 
 *Rule authors*: 
 
@@ -67,28 +66,74 @@ Identifies a suspicious Diagnostics Utility for Internet Explorer child process.
 *Possible investigation steps*
 
 
-- Review the process details to confirm the suspicious child process was indeed started by iediagcmd.exe.
-- Check any URL file type creation before the alert and review the source of those files.
-- Investigate the process tree and make sure all descendant processes are terminated.
-- Examine the network activity associated with the suspicious process to detect any unauthorized data exfiltration or communication with known malicious IP addresses.
-- Assess the system for any additional indicators of compromise, such as unexpected changes in system files or registry keys, which might suggest a broader attack.
+- Does the alert show "iediagcmd.exe" launching a non-system helper?
+  - Focus: `process.parent.executable`, `process.name`, `process.executable`, and `process.command_line`; check for WebDAV, UNC, temp, downloads, archive-extracted, or user-writable helper paths.
+  - Implication: escalate when the helper name matches a diagnostics utility but `process.executable` is outside "C:\Windows\System32\" or points to remote/user-writable content; lower suspicion only when the path is a controlled diagnostic harness bounded to this `host.id` and `user.id`.
+- Does child identity fit the claimed system utility?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the child is unsigned, newly seen, remotely hosted, user-writable, or PE metadata mismatches the helper name; a trusted signer/familiar name confirms identity only, not benign "iediagcmd.exe" use.
+- Does parent/session context fit user-triggered execution?
+  - Focus: `process.parent.command_line`, `process.Ext.session_info.logon_type`, and `user.id`.
+  - Hint: inspect `process.Ext.ancestry` only when direct parent/child context is incomplete.
+  - Implication: escalate when the parent command line/ancestry points to a shortcut, archive, browser, mail client, or document-open path in an interactive user session; lower suspicion when parent/session evidence stays inside a controlled diagnostic or authorized test launch path.
+- If file telemetry is available, did the lure or child stage follow-on artifacts?
+  - Focus: recover file events with `host.id` + `process.entity_id`; if absent, use `host.id` + `process.pid` in the alert window. Review `file.name`, `file.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier` for ".url" lures, archive extraction, decoy PDFs, copied helpers, DLLs, or payloads. !{investigate{"description":"","label":"File events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if the child writes a file, check later starts where `process.executable` equals `file.path`.
+  - Implication: escalate on internet provenance, WebDAV/UNC lure paths, decoys, copied utilities, DLLs, or written artifacts later executed; missing file telemetry is unresolved, not benign.
+- If DNS/connection telemetry is available, did the child contact a remote share or callback?
+  - Focus: recover network events with `host.id` + `process.entity_id`; if absent, use `host.id` + `process.pid` in the alert window. Separate DNS `dns.question.name`/`dns.resolved_ip` from connection `destination.ip`/`destination.port`. !{investigate{"description":"","label":"Network events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: map "lookup_result" `dns.question.name` to `dns.resolved_ip`, then compare with `destination.ip` and any remote host from the helper path or lure.
+  - Implication: escalate when the child reaches a remote-share host, rare public destination, or later C2-like infrastructure unrelated to diagnostics; missing DNS/connection telemetry is unresolved, not benign.
+- Do descendants or siblings show cleanup, decoy opening, or payload execution?
+  - Focus: later process starts on the same `host.id`, using direct `process.parent.entity_id` links first; review `process.executable`, `process.command_line`, `process.Ext.created_suspended`, and signer context. !{investigate{"description":"","label":"Child process starts from the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: use PID matching only in a tight alert-time window, and inspect `process.Ext.ancestry` only when direct lineage is incomplete.
+  - Implication: escalate when the chain launches "taskkill.exe", opens a decoy through "cmd.exe", starts a browser from an abnormal path, creates a suspended process, or runs unsigned follow-on payloads; keep host-local only when no follow-on evidence contradicts a bounded diagnostic or test path.
+- If local evidence is suspicious or incomplete, do related alerts show broader delivery or post-exploitation?
+  - Focus: review same-`user.id` alerts over 48 hours for the same lure, proxy-execution, payload, or C2 pattern. !{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 user scope is sparse or shared, compare same-`host.id` alerts for the same ".url", WebDAV, child hash, or payload pattern. !{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 response scope when related alerts show the same lure, remote working directory, payload, or post-exploitation pattern; keep response host-local only when related alerts are absent and local telemetry fully explains one recognized workflow.
+- What disposition do helper-path, identity, launch, artifact, network, descendant, and related-alert findings support?
+  - Implication: escalate on remote working-directory abuse, lure delivery, payload staging, suspicious destinations, cleanup, or broader compromise; close only when process, artifact, network, descendant, and alert-scope evidence bind one recognized diagnostic or authorized test workflow; preserve and escalate on incomplete or mixed visibility.
 
 
 *False positive analysis*
 
 
-- This behavior is very rare and should be highly suspicious.
+- Routine diagnostics resolve helpers from "C:\Windows\System32\". Treat helper execution from WebDAV, UNC, temp, downloads, or archive paths as an operational anti-pattern unless telemetry proves a controlled harness or authorized exploit test: child identity (`process.executable`, `process.hash.sha256`, signer, `process.command_line`), parent launch context, `user.id`, `host.id`, and ".url", file-provenance, DNS, or destination evidence stay inside the same bounded workflow; use testing records only to corroborate telemetry.
+- Before exceptions, validate the minimum recurring pattern: child path or hash, signer, command line, `process.parent.executable`, `user.id`, `host.id`, and bounded lure or destination pattern. Avoid exceptions on "iediagcmd.exe", `process.name`, helper basename, or `host.id` alone because those fields also match malicious working-directory hijack chains.
 
 
 *Response and remediation*
 
 
-- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
-- Terminate the suspicious child process identified in the alert.
-- 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 files or processes.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign.
-- Implement additional monitoring and alerting for similar suspicious activities involving explorer.exe to enhance detection capabilities and prevent recurrence.
-- Review and update endpoint security policies to restrict the execution of potentially malicious URL files.
+- If confirmed benign, reverse containment and document the exact child path/hash, command line, parent launch context, `user.id`, `host.id`, and lure or destination evidence proving the diagnostic or testing workflow. Create an exception only for that recurring bounded pattern.
+- If suspicious but unconfirmed, preserve a case export of the alert, parent/child process details, suspicious helper binary, ".url" or archive artifacts, file-provenance records, DNS/connection records, and descendant process evidence before containment. Apply reversible containment first: block the confirmed WebDAV or callback destination, remove remote-share access, or raise monitoring on `host.id`; isolate only when artifact, network, or descendant evidence shows active compromise and the host role can tolerate disruption.
+- If confirmed malicious, isolate the host or terminate the malicious child and confirmed descendants only after recording process entity IDs, command lines, hashes, lure paths, destination indicators, and related alert identifiers. If endpoint response is unavailable, hand off preserved evidence to contain the endpoint or block remote infrastructure.
+- Before deleting artifacts, scope other users and hosts for the same ".url" filename pattern, WebDAV/UNC host, child hash, command line, decoy path, and payload path. Remove only lure files, dropped helpers, DLLs, decoys, archives, and payloads found during the investigation, then restore modified execution paths that supported the hijack chain.
+- After containment, apply the June 2025 Windows security updates for CVE-2025-33053 where missing, restrict untrusted Internet Shortcut content and remote-working-directory execution paths, retain process/file/network telemetry, and document variants such as helper names or WebDAV paths for detection engineering review.
+
+
+==== 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
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-escalation-via-vulnerable-msi-repair.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-escalation-via-vulnerable-msi-repair.asciidoc
index 1bfba31f0e..959dba717a 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-escalation-via-vulnerable-msi-repair.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-escalation-via-vulnerable-msi-repair.asciidoc
@@ -42,7 +42,7 @@ Identifies when a browser process navigates to the Microsoft Help page followed
 * Data Source: Microsoft Defender XDR
 * Resources: Investigation Guide
 
-*Version*: 206
+*Version*: 207
 
 *Rule authors*: 
 
@@ -58,46 +58,80 @@ Identifies when a browser process navigates to the Microsoft Help page followed
 *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 Escalation via Vulnerable MSI Repair*
 
 
-Windows Installer (MSI) is a service used for software installation and maintenance. Adversaries exploit vulnerabilities in MSI repair functions to gain elevated privileges. This detection rule identifies suspicious activity by monitoring browser processes accessing Microsoft Help pages, followed by elevated process creation, indicating potential privilege escalation attempts.
-
-
 *Possible investigation steps*
 
 
-- Review the alert details to identify the specific browser process that accessed the Microsoft Help page, noting the process name and command line details.
-- Check the user domain associated with the process to confirm if it matches "NT AUTHORITY", "AUTORITE NT", or "AUTORIDADE NT", which may indicate a system-level account was used.
-- Investigate the parent process of the browser to determine if it was expected or if it shows signs of compromise or unusual behavior.
-- Examine the timeline of events to see if an elevated process was spawned shortly after the browser accessed the Microsoft Help page, indicating potential exploitation.
-- Correlate the event with other security logs or alerts from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR to gather additional context or evidence of malicious activity.
-- Assess the risk and impact of the elevated process by identifying its actions and any changes made to the system, such as modifications to critical files or registry keys.
+- What did the elevated browser parent launch?
+  - Why: MSI repair abuse can expose a SYSTEM browser through a help-link redirect; a non-browser child marks the privilege-escalation boundary.
+  - Focus: `process.parent.command_line`, `process.name`, `process.executable`, `process.command_line`, and `process.Ext.token.integrity_level_name`.
+  - Implication: escalate when a Microsoft Help-tied browser launches a SYSTEM or high-integrity shell, script host, installer, admin utility, file manager, or user-writable binary; lower concern only when the command line shows a browser-internal role, path and signer match the parent browser family, and no non-browser child appears in the alert window.
+- Does the lineage fit an MSI repair-to-help-link path?
+  - Focus: `process.parent.entity_id`, `process.parent.pid`, surrounding `process.name`, and `process.command_line`.
+  - Implication: escalate when ancestry or surrounding starts show MSI repair, installer custom actions, console activity, or an unexpected SYSTEM browser before the child; lower concern when the chain stays inside browser self-maintenance without repair, console, or custom-action ancestry.
+  - Hint: recover the parent browser event first. If parentage is incomplete, inspect `process.Ext.ancestry`; if entity IDs are absent, use `host.id`, `process.parent.pid`, and a tight alert window. !{investigate{"description":"","label":"SYSTEM browser parent process event","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+- Is the child process identity expected for the host and signer?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.Ext.relative_file_creation_time`.
+  - Implication: escalate when the child runs from a user-writable or temporary path, has a mismatched original file name, lacks a trusted signer, or was recently created; lower concern only when signer, path, age, and browser parent context all fit the same recognized component.
+- What follow-on process activity came from the same SYSTEM browser or spawned child?
+  - Focus: same-host starts from the browser `process.parent.entity_id` or child `process.entity_id`: `process.name`, `process.command_line`, and `process.Ext.token.integrity_level_name`.
+  - Implication: escalate when the browser or child launches shells, scripts, persistence or administration tools, additional installers, or chained SYSTEM processes; keep scope local when activity stops at browser helpers with no privileged child chain.
+  - Hint: prefer `host.id` plus parent or child `process.entity_id`; use `host.id`, `process.pid`, and a tight window only when entity IDs are absent.
+    - !{investigate{"description":"","label":"Process starts from the SYSTEM browser parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","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.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Process starts from the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}}
+- Does the user and session context support interactive exploitation?
+  - Focus: `user.id`, `user.name`, `user.domain`, `process.Ext.authentication_id`, and `process.Ext.session_info.logon_type`.
+  - Implication: escalate when a low-privileged or unexpected interactive session is tied to the SYSTEM browser-to-child chain; a pre-existing user browser usually breaks the SYSTEM child path, so a SYSTEM or high-integrity child tied to an interactive session is severity-changing. Lower concern only when process evidence maps to controlled repair validation or browser-helper behavior.
+- Does process telemetry show the same SYSTEM-browser-to-tool pattern beyond this process instance?
+  - Focus: same `process.parent.command_line` redirect fragment, suspicious `process.name` or `process.executable`, `user.id`, and `host.id` across recent starts.
+  - Implication: broaden when recent starts show the same non-browser child pattern across unrelated hosts or users; keep response scoped when telemetry shows only this browser parent, child command line, and no repeated non-browser descendants.
+  - Hint: run this pivot only if child intent, lineage, or session context remains suspicious or unresolved. !{investigate{"description":"","label":"Recent process starts with the same child executable","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+- Based on the evidence gathered, what disposition is supported?
+  - Escalate on SYSTEM or high-integrity browser-to-tool execution, MSI repair lineage, suspicious child identity, interactive session linkage, or repeated scope; close only for same-browser helper behavior with no non-browser descendants or an authorized test whose process facts exactly match scope. Preserve evidence and escalate when child intent, lineage, or session context is mixed or incomplete.
 
 
 *False positive analysis*
 
 
-- Legitimate software updates or installations may trigger the rule if they involve browser-based help documentation. To manage this, identify and whitelist known software update processes that frequently access Microsoft Help pages.
-- Automated scripts or administrative tools that use browsers to access Microsoft Help for legitimate purposes can cause false positives. Exclude these scripts or tools by specifying their unique command-line patterns or process names.
-- User-initiated troubleshooting or help-seeking behavior that involves accessing Microsoft Help pages might be misinterpreted as suspicious. Educate users on safe browsing practices and consider excluding specific user accounts or domains that are known to frequently engage in such activities.
-- Security tools or monitoring solutions that simulate browser activity for testing purposes may inadvertently trigger the rule. Identify these tools and create exceptions based on their process names or command-line arguments to prevent unnecessary alerts.
+- Browser helper, renderer, GPU, updater, or crash subprocesses can trigger after a SYSTEM browser opens a Microsoft Help link. Confirm a browser-internal role, same browser family, installed-browser path and signer, and no shell, installer, file manager, or admin tool from the same parent.
+- Authorized MSI repair security validation is benign only when `@timestamp`, `host.id`, `user.id`, the SYSTEM browser parent command line, and child command line match the exact exercise; outside records may corroborate but not replace process facts.
+- Build exceptions from the minimum confirmed workflow: browser family and signer, exact redirect parent context, expected child executable or command pattern, `host.id`, and tightly scoped test or managed-repair cohort. Avoid exceptions on `user.domain`, browser name, or redirect URL alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
-- Terminate any suspicious elevated processes that were spawned following the browser's navigation to the Microsoft Help page to halt potential privilege escalation activities.
-- Conduct a thorough review of the affected system's event logs and process creation history to identify any unauthorized changes or additional indicators of compromise.
-- Apply the latest security patches and updates to the Windows Installer service and any other vulnerable components to mitigate the exploited vulnerability.
-- Restore the affected system from a known good backup if unauthorized changes or persistent threats are detected that cannot be easily remediated.
-- Monitor the network for any signs of similar exploitation attempts or related suspicious activities, using enhanced detection rules and threat intelligence feeds.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery efforts.
+- If confirmed benign, document the process evidence that proved the browser-helper or validation workflow, reverse any temporary containment, and create only the narrow exception described above if the same workflow recurs.
+- If suspicious but unconfirmed, preserve the alert and Timeline/export records for the browser parent, child, ancestor chain, host, and user. Record command lines, `process.entity_id`, `process.parent.entity_id`, `host.id`, `user.id`, and any visible MSI package or vulnerable-application names before containment or process termination.
+- Apply reversible containment first when findings remain suspicious: isolate the host if its business role allows, or restrict the affected account/session while preserving endpoint telemetry. Do not terminate the child process until its command line, parentage, and spawned descendants are recorded.
+- If confirmed malicious, contain the host and affected account based on the process lineage and session evidence, then terminate the malicious child and descendants after recording their identifiers. Remove only the payloads, repair artifacts, or configuration changes identified during the investigation.
+- Patch Windows Installer and the vulnerable application package involved in the repair path, verify that the affected OS has the relevant vendor security update for CVE-2024-38014, and repackage or disable repair flows that let low-privileged users reach elevated custom actions, console windows, or help-link execution.
+- Document the final evidence set, repair path, affected hosts, and any missing telemetry that limited certainty so future alerts can distinguish browser helper noise, authorized validation, and repeated exploitation.
+
+==== 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
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-execution-via-filefix-phishing-attack.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-execution-via-filefix-phishing-attack.asciidoc
index 7c70963a01..9f055683c1 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-execution-via-filefix-phishing-attack.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-execution-via-filefix-phishing-attack.asciidoc
@@ -1,7 +1,7 @@
 [[potential-execution-via-filefix-phishing-attack]]
 === Potential Execution via FileFix Phishing Attack
 
-Identifies the execution of Windows commands or downloaded files via the browser's dialog box. Adversaries may use phishing to instruct the victim to copy and paste malicious commands for execution via crafted phsihing web pages.
+Identifies the execution of Windows commands or downloaded files via the browser's dialog box. Adversaries may use phishing to instruct the victim to copy and paste malicious commands for execution via crafted phishing web pages.
 
 *Rule type*: eql
 
@@ -33,8 +33,6 @@ Identifies the execution of Windows commands or downloaded files via the browser
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Execution
-* Tactic: Initial Access
-* Tactic: Defense Evasion
 * Data Source: Windows Security Event Logs
 * Data Source: Elastic Defend
 * Data Source: Sysmon
@@ -42,7 +40,7 @@ Identifies the execution of Windows commands or downloaded files via the browser
 * Data Source: Microsoft Defender XDR
 * Resources: Investigation Guide
 
-*Version*: 3
+*Version*: 4
 
 *Rule authors*: 
 
@@ -58,9 +56,6 @@ Identifies the execution of Windows commands or downloaded files via the browser
 *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 Execution via FileFix Phishing Attack*
 
@@ -69,29 +64,72 @@ Identifies the execution of Windows commands or downloaded files via the browser
 *Possible investigation steps*
 
 
-- Review the process command line and arguments to identify any malicious intent.
-- Review web activity preceeding the alert to identify the initial vector.
-- Investigate any files, network or child process events from the suspected process.
-- 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.
+- Does the alert show the FileFix browser-to-Explorer execution path?
+  - Focus: alert-local `process.parent.executable`, `process.parent.args`, `process.name`, `process.executable`, and `process.command_line`.
+  - Implication: escalate when a Chromium-style file-picker parent using "--message-loop-type-ui" and "--service-sandbox-type=none" launches PowerShell, curl, certutil, certreq, msiexec, mshta, rundll32, wscript, cscript, or a "?:\Users\*\Downloads\*" executable; lower suspicion only when the child is a signed installer or diagnostic tool and the parent/command shape matches a recognized browser-initiated support or install flow.
+- Is the launched child the expected binary for that workflow?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`; recover absent values from same-process events. !{investigate{"description":"","label":"Events for the launched process on this host","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the path is user-writable or signer/original name mismatches the expected tool; lower identity risk when signer, original name, path, and known hash history fit, but continue command-intent checks.
+- Does the command line reveal pasted-command social engineering?
+  - Focus: `process.command_line` and `process.name`.
+  - Implication: escalate when the command hides execution before a fake path or comment, invokes PowerShell or a LOLBin to retrieve/run content, or starts a "%USERPROFILE%\Downloads" payload directly; lower suspicion only when arguments open the signed installer or diagnostic tool with no hidden command, URL, or shell operator.
+- Does a Downloads-path child look newly staged or renamed?
+  - Focus: `process.executable`, `process.Ext.relative_file_creation_time`, `process.Ext.relative_file_name_modify_time`, `process.code_signature.thumbprint_sha256`, and same-process file writes/renames; recover absent process values from same-process events. !{investigate{"description":"","label":"File events for the launched process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: for the downloaded-EXE variant, process file-age is the recovery signal; absent file provenance does not make a Downloads path benign.
+  - Implication: escalate when a Downloads or other user-profile executable runs shortly after creation or rename, especially with weak identity; lower suspicion when file age, stable signer, and path match the same recognized update or support workflow.
+- Did the launched child spawn follow-on tools?
+  - Focus: child process starts from `process.entity_id`, then descendant `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child process starts from the launched process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if entity IDs are unavailable, fall back to parent PID plus a tight alert-time window on the same host.
+  - Implication: escalate when the chain fans out into shells, script hosts, installers, archive tools, or task/scheduler utilities; no descendants keeps scope local but does not clear suspicious command intent or identity mismatch.
+- Did the launched child contact retrieval or staging destinations?
+  - Focus: same-process network events for `destination.ip`, `destination.port`, and destination ownership when available. !{investigate{"description":"","label":"Network events for the launched process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when PowerShell, curl, certutil, certreq, mshta, or another child reaches external staging, paste, storage, or command-and-control infrastructure; missing network telemetry is unresolved, not benign.
+- If local evidence remains suspicious or unresolved, does the pattern recur for this user or host?
+  - Focus: related alerts and process starts for the same `user.id` and `host.id`, comparing `process.parent.args` and child `process.command_line`.
+  - Hint: review related user alerts with !{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: review related host alerts with !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same browser-parented shell, LOLBin, or Downloads-path launch repeats for this user, host, or other users; keep the case local when it is isolated and the process evidence resolves cleanly.
+- Escalate when ancestry, child identity, command intent, file age, descendants, network, or recurrence supports user-assisted command execution or downloaded payload launch; close only when process evidence shows a signed installer or diagnostic identity, non-hidden command shape, expected file age/path, no suspicious descendants, no suspicious network where telemetry exists, and no related spread; preserve evidence and escalate when facts conflict or remain incomplete.
 
 
 *False positive analysis*
 
 
-- Legitimate administrative scripts containing the suspicious keywords such as CAPTCHA.
+- Signed browser-initiated installer/diagnostic workflows or authorized security tests can trigger. Confirm exact alignment across parent flags, child path, signer, hash, command line, user, host, timing, and absence of suspicious descendants; do not close on a ticket or owner statement if process evidence conflicts.
+- Before creating an exception, require recurrence with stable `process.parent.executable`, `process.parent.args`, `process.executable`, `process.code_signature.thumbprint_sha256`, command-line shape, `user.id`, and `host.id`. Avoid exceptions on browser parentage, `process.name`, or Downloads-path execution alone.
 
 
 *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 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.
+- If suspicious but unconfirmed, first preserve the alert event, same-process event export, descendant process timeline, command-line text, parent context, child binary copy, hash and signature details, and the affected user/host identifiers.
+- Apply reversible containment only after preservation, such as restricting the affected browser session or account, blocking the exact child hash, or quarantining the downloaded child binary. Escalate to host isolation only when command intent, identity, or descendants indicate likely payload execution.
+- If confirmed malicious, isolate the host when the launched child or descendants executed payloads, then terminate the child and descendants after recording identifiers. Do not reset credentials from this alert alone; use identity response only when separate evidence proves credential exposure or account misuse.
+- Eradicate only the downloaded executables, scripts, task utilities, or secondary payloads identified in the process timeline, then remediate the phishing page access or browser session that enabled the user-assisted execution.
+- If confirmed benign, reverse temporary containment and document the exact parent flags, child identity, command shape, user, host, and outside confirmation that proved the workflow. Create an exception only after the stable bounded pattern recurs.
+- Post-incident hardening: restrict direct execution from user download locations where feasible, warn on browser-file-picker social engineering, retain process telemetry needed for the pivots above, and document the FileFix variant observed in the case record.
+
+==== 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
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-fake-captcha-phishing-attack.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-fake-captcha-phishing-attack.asciidoc
index ef4c02bd6a..43bdd8d776 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-fake-captcha-phishing-attack.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-fake-captcha-phishing-attack.asciidoc
@@ -1,7 +1,7 @@
 [[potential-fake-captcha-phishing-attack]]
 === Potential Fake CAPTCHA Phishing Attack
 
-Identifies potential fake CAPTCHA phishing attack based on PowerShell or Cmd argument values. Adversaries employ this technique via compromised websites with browser injects, posing either as fake CAPTCHAs to access the site or as a page loading error requiring a fix to display the page. The victim is instructed to copy and past a malicious command to the Windows Run dialog box.
+Identifies potential fake CAPTCHA phishing attacks based on PowerShell, Cmd, or Mshta command-line values. Adversaries employ this technique via compromised websites with browser injects, posing either as fake CAPTCHAs to access the site or as a page loading error requiring a fix to display the page. The victim is instructed to copy and paste a malicious command to the Windows Run dialog box.
 
 *Rule type*: eql
 
@@ -42,7 +42,7 @@ Identifies potential fake CAPTCHA phishing attack based on PowerShell or Cmd arg
 * Data Source: Crowdstrike
 * Resources: Investigation Guide
 
-*Version*: 3
+*Version*: 4
 
 *Rule authors*: 
 
@@ -58,40 +58,90 @@ Identifies potential fake CAPTCHA phishing attack based on PowerShell or Cmd arg
 *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 Fake CAPTCHA Phishing Attack*
 
 
-
 *Possible investigation steps*
 
 
-- Review the process command line and arguments to identify any malicious intent.
-- Review web activity preceeding the alert to identify the initial vector.
-- Investigate any network activity or child processes from the suspected process.
-- 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.
+- What does the pasted command do after the CAPTCHA or verification text?
+  - Why: lure text is the wrapper; payload behavior separates clickfix execution from testing or inert copy text.
+  - Focus: `process.name`, `process.command_line`, `process.parent.name`, and `process.parent.command_line` for URLs, encoded content, inline script, archive handling, or handoff to "mshta.exe", "cmd.exe", or "powershell.exe".
+  - Hint: fake-update or page-fix wording is the same abuse path when the command downloads, decodes, or hands execution to another utility.
+  - Implication: escalate when the command downloads content, rebuilds a payload, invokes another script host, or hides work after CAPTCHA wording; lower suspicion only for a bounded authorized simulation or lab command with no second-stage behavior.
+
+- Is the shell or proxy binary and launch context consistent with paste-and-run clickfix?
+  - Focus: `process.executable`, `process.parent.executable`, `process.parent.command_line`, and `user.id`.
+  - Implication: escalate faster when the binary is renamed, user-writable, or launched from an unusual parent context for the user; a native shell path confirms identity but does not clear suspicious command content.
+
+- Do children from the alerting instance show payload execution or follow-on tooling?
+  - Focus: child starts where `process.parent.entity_id` maps to `process.entity_id`, reviewing child `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child process starts from the same alerting instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `process.entity_id` is absent, recover children with `host.id` + `process.pid` in a tight alert-time window and treat the match as weaker.
+  - Implication: escalate when the same shell or "mshta.exe" starts installers, script hosts, archive tools, credential tooling, or more shells; no children reduce scope only if command intent and artifact/destination evidence also stay bounded.
+
+- If file telemetry is available, did the process stage scripts, HTAs, archives, or payloads?
+  - Focus: process-scoped file events using `host.id` + `process.entity_id`, or `host.id` + `process.pid` as fallback, reviewing `file.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier`. !{investigate{"description":"","label":"File activity for the alerting instance","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"}}
+  - Implication: escalate when artifacts land in temp, downloads, desktop, public, startup, or other user-writable paths, carry internet provenance, or later execute; missing file telemetry is unresolved, not benign.
+
+- If network telemetry is available, did the process retrieve payloads or contact callbacks?
+  - Focus: process-scoped network events using `host.id` + `process.entity_id`, separating DNS `dns.question.name` from connection `destination.ip` / `destination.port`. !{investigate{"description":"","label":"Network activity for the alerting instance","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `process.entity_id` is absent, use `host.id` + `process.pid` and a tight alert-time window. Missing network telemetry is unresolved, not benign.
+  - Implication: escalate when the same process reaches rare public domains, direct IPs, paste/file hosts, or service ports fitting retrieval or callback behavior; lower suspicion only when destinations belong to the same authorized simulation or lab workflow.
+
+- Do surrounding process events explain the lure path into "explorer.exe"?
+  - Focus: same `host.id` and `user.id` process timeline, especially browser, chat, mail, archive, or download-manager starts in `process.name`, `process.parent.executable`, and `process.parent.command_line`. !{investigate{"description":"","label":"Process timeline for the host and user","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when a browser/chat/download chain immediately precedes the paste-run shell or no controlled source explains the lure; lower suspicion when the sequence matches a planned awareness platform or lab harness and the command remains bounded.
+
+- If local findings stay suspicious or unresolved, do related alerts change scope?
+  - Focus: recent alerts for the same `host.id`, then `user.id`, emphasizing reuse of the command fragment, shell/proxy binary, recovered artifact, destination, or persistence chain. !{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"}}
+  - Hint: use the user view after the host view, or when a shared host needs actor scoping for the command or lure pattern. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden response when related alerts show the same lure-driven execution pattern on this host or user; quiet alert history does not close the case without a telemetry-backed benign workflow.
+
+- Escalate on clickfix command intent plus suspicious children, staged artifacts, process-scoped destinations, delivery context, or related alerts; close only when alert-local evidence and recovery bind one authorized simulation or lab workflow with no contradiction; if evidence is mixed or visibility incomplete, preserve evidence and escalate.
 
 
 *False positive analysis*
 
 
-- Legitimate administrative scripts containing the suspicious keywords such as CAPTCHA.
+- Security-awareness, phishing-simulation, red-team, malware-analysis, browser-security, and QA labs can intentionally execute fake CAPTCHA samples. Confirm one exact workflow: stable `process.command_line` fragment, expected `process.executable` and `process.parent.name`, bounded `user.id` / `host.id`, and recovered children, artifacts, and destinations that stay inside the exercise or lab set.
+- Without exercise or lab records, close only when telemetry proves the same command fragment, parent context, `user.id`, `host.id`, and recovered evidence stayed bounded across prior alerts from this rule. Do not close when child execution, artifact staging, destination activity, or related alerts contradict the expected workflow.
+- Build exceptions only from the minimum confirmed workflow: command fragment, process identity, parent context, `user.id`, `host.id`, and any recovered artifact or destination pattern. Avoid exceptions on lure text, "explorer.exe", `process.name`, or a user alone.
 
 
 *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 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.
+- If confirmed benign, reverse temporary containment and record the command, process identity, parent context, `user.id`, `host.id`, and recovered supporting evidence that proved the authorized simulation or lab workflow. Create an exception only when that exact workflow recurs.
+- If suspicious but unconfirmed, export the alert, process tree, `process.entity_id`, `process.command_line`, child command lines, volatile state, and any recovered artifact paths, domains, IPs, or ports before containment. Apply reversible controls first, such as temporary destination blocks, browser-session reset, heightened monitoring, or endpoint isolation when retrieval, staging, or second-stage execution makes continued connectivity risky.
+- If confirmed malicious, isolate the host when command intent plus child, artifact, or destination evidence establishes compromise. Terminate the malicious shell, "mshta.exe", or follow-on children only after evidence is recorded, then block confirmed domains, IPs, hashes, or URLs and reset credentials only if the investigation shows account misuse.
+- Eradicate only the staged scripts, HTAs, archives, payloads, or persistence artifacts found during the investigation, then remediate the web, chat, mail, or download path that led the user to run the lure.
+- Post-incident hardening: retain process, file, and network telemetry needed for future clickfix triage; review browser protections, clipboard/paste execution controls, and user-awareness coverage; record the confirmed lure wording and paste-run chain in the case notes.
+
+
+==== 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
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-foxmail-exploitation.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-foxmail-exploitation.asciidoc
index 421ad199e1..3a45f1f4f2 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-foxmail-exploitation.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-foxmail-exploitation.asciidoc
@@ -1,7 +1,7 @@
 [[potential-foxmail-exploitation]]
 === Potential Foxmail Exploitation
 
-Identifies the Foxmail client spawning a child process with argument pointing to the Foxmail temp directory. This may indicate the successful exploitation of a Foxmail vulnerability for initial access and execution via a malicious email.
+Identifies the Foxmail client spawning a child process with arguments pointing to user-profile AppData paths or remote shares. This may indicate exploitation of a Foxmail vulnerability for initial access and execution via a malicious email.
 
 *Rule type*: eql
 
@@ -47,7 +47,7 @@ Identifies the Foxmail client spawning a child process with argument pointing to
 * Data Source: Crowdstrike
 * Resources: Investigation Guide
 
-*Version*: 208
+*Version*: 209
 
 *Rule authors*: 
 
@@ -63,47 +63,87 @@ Identifies the Foxmail client spawning a child process with argument pointing to
 *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 Foxmail Exploitation*
 
 
-Foxmail, a popular email client, can be exploited by adversaries to gain initial access and execute malicious payloads. Attackers may leverage vulnerabilities to spawn child processes from Foxmail, directing them to temporary directories where malicious files reside. The detection rule identifies such suspicious activities by monitoring process creation events, specifically when Foxmail spawns processes with arguments pointing to its temp directory, indicating potential exploitation attempts.
-
 
 *Possible investigation steps*
 
 
-- Review the process creation event details to confirm that Foxmail.exe is the parent process and check the specific child process that was spawned.
-- Examine the arguments of the spawned process to verify if they point to a suspicious temporary directory, as indicated by the query pattern (e.g., paths under "?:\Users\*\AppData\*").
-- Investigate the contents of the identified temporary directory for any unusual or malicious files that may have been executed.
-- Check the email logs and Foxmail client activity to identify any recent emails that could have contained malicious attachments or links leading to the exploitation attempt.
-- Correlate the event with other security alerts or logs from data sources like Elastic Defend, Sysmon, or Microsoft Defender XDR to identify any related suspicious activities or patterns.
-- Assess the risk and impact on the affected system by determining if any unauthorized changes or additional malicious processes have been initiated following the initial alert.
+- What exact Foxmail child execution did the alert capture?
+  - Why: Foxmail exploit attempts execute code in the user's client context; the child process and path argument distinguish payload execution from routine file handling.
+  - Focus: `process.parent.name`, `process.parent.executable`, child `process.executable`, `process.command_line`, and `process.args`.
+  - Implication: escalate when Foxmail.exe launches a script host, LOLBin, interpreter, archive utility, installer, or payload from a user-writable or remote-share path; lower suspicion only when the child is a recognized signed Foxmail component with the expected path, argument pattern, and no contradictory process evidence.
+
+- Does the Foxmail parent match the installed mail client and user launch context?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.code_signature.subject_name`, and `process.parent.code_signature.trusted`.
+  - Implication: escalate when Foxmail runs from a user-writable or portable path, has an unexpected signer or trust state, or appears under an abnormal launch chain; lower suspicion when parent identity and user context match a recognized installed Foxmail workflow. Parent identity never clears the child behavior by itself.
+
+- What does the child command line say it was trying to execute or open?
+  - Why: the user-writable or remote path string in `process.args` is the rule-specific payload anchor; interpret it before relying on broader pivots.
+  - Focus: `process.executable`, `process.command_line`, `process.args`, and `process.code_signature.subject_name`. !{investigate{"description":"","label":"Events for the Foxmail child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the child runs executable or scriptable content from a user-writable path, mounted archive, or remote share, especially through a LOLBin or interpreter; lower suspicion when signed child, arguments, and path pattern match a locally confirmed Foxmail file-handling action.
+
+- Did the Foxmail child launch descendants that change impact or confirm execution?
+  - Focus: process starts on the same `host.id` where `process.parent.entity_id` matches the child `process.entity_id`, or `process.parent.pid` matches `process.pid` in the alert window; review descendant `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child processes launched by the Foxmail child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: prefer entity match; use PID only inside the alert window.
+  - Implication: escalate when descendants include payload staging, scripting, installers, persistence tooling, or commands unrelated to Foxmail; lower suspicion when there are no descendants and the child command from the prior step already matches a recognized helper workflow.
+
+- What delivery clue is embedded in the user-writable or remote path argument?
+  - Focus: file name, extension, UNC host/share, and directory pattern visible in `process.args`, scoped to `host.name` and `user.id`.
+  - Implication: escalate or broaden when the path suggests executable content, a deceptive attachment-like name, or a remote share that can execute content without local provenance; lower suspicion only as corroboration when the path shape fits a recognized Foxmail file-handling workflow supported by child identity and descendant evidence.
+
+- Does related activity history show the same child/path pattern beyond this process?
+  - Focus: related records for the same `user.id`; compare child `process.executable`, parent-child pair, and distinctive `process.args` fragments. !{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: use same-asset related records to separate one user's repeat workflow from multiple users on one host. !{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 the same child binary, remote share, or path fragment appears on unrelated users or hosts; keep response local when related records are absent and local process evidence already proves one recognized workflow.
+
+- Based on the Foxmail parent, child command, argument path, descendants, and related activity, what disposition is supported?
+  - Escalate for suspicious child intent, unexplained descendants, or the same pattern on multiple users or hosts; close only when process evidence and supported recovery prove one exact recognized Foxmail workflow on this host; preserve and escalate mixed, missing, or contradictory evidence, using outside confirmation only to corroborate details telemetry cannot prove.
 
 
 *False positive analysis*
 
 
-- Routine software updates or installations may cause Foxmail to spawn child processes in the temp directory. Users can create exceptions for known update processes to prevent false alerts.
-- Legitimate plugins or extensions for Foxmail might execute processes from the temp directory. Verify the legitimacy of these plugins and exclude them if they are trusted.
-- Automated scripts or backup software interacting with Foxmail could trigger the rule. Identify these scripts and add them to an exclusion list if they are verified as safe.
-- User-initiated actions such as importing or exporting data in Foxmail might result in temporary process creation. Monitor these activities and exclude them if they are part of regular operations.
-- Security software performing scans or checks on Foxmail's temp directory can be mistaken for exploitation attempts. Confirm these activities and whitelist the security software processes involved.
+- Signed Foxmail child processes used for update or file handling and authorized internal tests are plausible benign candidates, but the label is not clearance. Confirm parent path/signer, child path/signer, `process.args`, `host.id`, and `user.id` all align with one workflow or exact test file/share, and verify no suspicious descendants; use prior alerts only to tune a durable exception, not to close the single alert by recurrence alone.
+- If test records are unavailable, use the process timeline, path shape, and user/host scope as fallback corroboration; do not close on owner confirmation alone when process evidence remains unexplained.
+- Before creating an exception, require stable anchors such as `process.parent.executable`, `process.executable`, `process.code_signature.subject_name`, the user-writable or remote path pattern in `process.args`, `host.id`, and `user.id`. Avoid exceptions on "Foxmail.exe" alone, temp-path strings alone, or `process.name` alone because exploit chains and benign components can share those surface features.
 
 
 *Response and remediation*
 
 
-- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any ongoing malicious activity.
-- Terminate any suspicious processes spawned by Foxmail that are identified in the alert to stop the execution of potentially malicious payloads.
-- Conduct a thorough scan of the affected system using an updated antivirus or endpoint detection and response (EDR) tool to identify and remove any malicious files or remnants.
-- Review and analyze email logs and quarantine any suspicious emails that may have been the source of the exploit to prevent further exploitation attempts.
-- Apply any available security patches or updates to Foxmail and the operating system to mitigate known vulnerabilities and prevent future exploitation.
-- Monitor the network and systems for any signs of lateral movement or additional compromise, using indicators of compromise (IOCs) identified during the investigation.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional actions are required based on the scope and impact of the threat.
+- If confirmed benign, reverse any temporary containment and document the recognized Foxmail component, file-handling, or test workflow, including the expected parent-child pair, signer, path pattern, `host.id`, and `user.id`. Create a narrow exception only when those anchors are stable enough to avoid suppressing lookalike exploit chains.
+- If suspicious but unconfirmed, preserve the alert record, parent and child command lines, `process.entity_id`, `process.pid`, `process.args`, referenced user-writable or remote paths, descendant process identifiers, and case records that identify the delivery path before containment. Apply reversible containment such as temporary quarantine of the referenced artifact, temporary outbound restrictions for the affected host when remote retrieval is indicated, or heightened monitoring on the affected `host.id` and `user.id`; escalate to host isolation only if follow-on execution, staging, or wider compromise appears and the host role can tolerate it.
+- If confirmed malicious, isolate the host and terminate the Foxmail child or descendant payloads only after recording the relevant process identifiers, command lines, path strings, and delivery-path evidence; if direct endpoint response is unavailable, escalate with those preserved artifacts to the team that can act. Quarantine the referenced attachment or payload, block confirmed malicious indicators, and review other recipients, hosts, and users for the same attachment, remote path, or child-process pattern before deleting evidence or resetting accounts.
+- Eradicate only the payloads, persistence mechanisms, or configuration changes identified in the same chain after scoping affected recipients and hosts. Remediate the message source, attachment workflow, or remote share that led to the Foxmail launch.
+- Post-incident hardening: update Foxmail to a current vendor-fixed release, retain endpoint process telemetry and any mail or artifact telemetry used in this case, and document adjacent exploit-chain findings for the detection engineering team.
+
+
+==== 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
 
@@ -130,10 +170,10 @@ process where host.os.type == "windows" and event.type == "start" and
 ** ID: TA0001
 ** Reference URL: https://attack.mitre.org/tactics/TA0001/
 * Technique:
-** Name: Drive-by Compromise
-** ID: T1189
-** Reference URL: https://attack.mitre.org/techniques/T1189/
-* 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/
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-macos-ssh-brute-force-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-macos-ssh-brute-force-detected.asciidoc
index 08ec85ef06..68ffa3eeae 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-macos-ssh-brute-force-detected.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-macos-ssh-brute-force-detected.asciidoc
@@ -1,7 +1,7 @@
 [[potential-macos-ssh-brute-force-detected]]
 === Potential macOS SSH Brute Force Detected
 
-Identifies a high number (20) of macOS SSH KeyGen process executions from the same host. An adversary may attempt a brute force attack to obtain unauthorized access to user accounts.
+Identifies a high number of inbound SSH login attempts on a macOS host within a short time window. On macOS, each inbound SSH authentication attempt spawns the sshd-keygen-wrapper process once, whether the login succeeds or fails. Adversaries may perform password brute force or password spraying against exposed SSH services to obtain unauthorized access.
 
 *Rule type*: threshold
 
@@ -32,7 +32,7 @@ Identifies a high number (20) of macOS SSH KeyGen process executions from the sa
 * Data Source: Elastic Defend
 * Resources: Investigation Guide
 
-*Version*: 112
+*Version*: 113
 
 *Rule authors*: 
 
@@ -55,40 +55,42 @@ Identifies a high number (20) of macOS SSH KeyGen process executions from the sa
 *Investigating Potential macOS SSH Brute Force Detected*
 
 
-SSH (Secure Shell) is a protocol used to securely access remote systems. On macOS, the `sshd-keygen-wrapper` process is involved in SSH key generation. Adversaries may exploit this by repeatedly attempting to generate keys to gain unauthorized access, a tactic known as brute force. The detection rule identifies unusual activity by monitoring for excessive executions of this process, indicating potential brute force attempts.
+SSH (Secure Shell) is a protocol used to securely access remote systems. On macOS, each inbound SSH authentication attempt spawns
+`sshd-keygen-wrapper` once before handing off to `sshd`, regardless of whether the login succeeds or fails. This rule uses that
+1:1 relationship as a proxy for high inbound SSH login attempt volume on a host. It does not detect SSH key generation or
+key-based brute force activity.
 
 
 *Possible investigation steps*
 
 
-- Review the alert details to confirm the host and process information, specifically checking for the host.os.type as macos and the process.name as sshd-keygen-wrapper.
-- Examine the frequency and timing of the sshd-keygen-wrapper process executions to determine if they align with normal user activity or if they suggest an automated brute force attempt.
-- Investigate the parent process, launchd, to ensure it is legitimate and not being used maliciously to spawn the sshd-keygen-wrapper process.
-- Check for any recent successful or failed login attempts on the affected host to identify potential unauthorized access.
-- Correlate the activity with any other alerts or logs from the same host to identify patterns or additional indicators of compromise.
-- Review user account activity on the host to determine if any accounts have been accessed or modified unexpectedly.
+- Review alert details for `host.os.type:macos`, `process.name:sshd-keygen-wrapper`, and `process.parent.name:launchd`.
+- Examine the frequency and timing of `sshd-keygen-wrapper` process starts to determine if they suggest automated login attempts.
+- Review SSH authentication logs on the affected host for failed and successful logins, source IP addresses, and targeted usernames.
+- Determine whether Remote Login is expected to be enabled on this host (for example, build servers or developer workstations).
+- Correlate the activity with other alerts or logs from the same host to identify additional indicators of compromise.
+- Review user account activity on the host to determine if any accounts were accessed or modified unexpectedly.
 
 
 *False positive analysis*
 
 
-- Legitimate administrative tasks may trigger the rule if an administrator is performing routine maintenance or updates that involve generating SSH keys. To handle this, create an exception for known administrative accounts or scheduled maintenance windows.
-- Automated scripts or applications that require frequent SSH key generation for legitimate purposes can cause false positives. Identify these scripts or applications and exclude their associated processes or hosts from the detection rule.
-- Development environments where SSH keys are frequently generated for testing purposes might trigger the rule. Consider excluding specific development machines or user accounts from the rule to prevent unnecessary alerts.
-- Continuous integration/continuous deployment (CI/CD) systems that automate SSH key generation as part of their workflow can be a source of false positives. Exclude these systems or their specific processes from the detection rule to avoid disruption.
-- If a known security tool or monitoring system is configured to test SSH key generation as part of its checks, it may trigger the rule. Verify the tool's activity and exclude its processes if deemed non-threatening.
+- Build servers, developer workstations, or CI/CD pipelines that receive many legitimate inbound SSH connections may trigger this rule. Exclude known hosts or maintenance windows if the activity is expected.
+- Automated deployment or configuration management tools that open many SSH sessions in a short period can cause false positives.
+- Internet-facing SSH services may receive high volumes of scanning or credential-stuffing traffic from unrelated sources.
+- Security scanners or health checks that repeatedly test SSH connectivity may generate elevated `sshd-keygen-wrapper` activity.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected macOS host from the network to prevent further unauthorized access attempts.
-- Terminate any suspicious or unauthorized `sshd-keygen-wrapper` processes running on the affected host to halt ongoing brute force attempts.
-- Review and reset SSH credentials for all user accounts on the affected host to ensure no unauthorized access has been achieved.
-- Implement IP blocking or rate limiting on the SSH service to prevent further brute force attempts from the same source.
-- Conduct a thorough review of the affected host's SSH configuration and logs to identify any unauthorized changes or access.
-- Escalate the incident to the security operations team for further investigation and to determine if additional hosts are affected.
-- Enhance monitoring and alerting for similar SSH brute force patterns across the network to improve early detection and response capabilities.
+- Review SSH authentication logs to identify source IPs, targeted accounts, and whether any logins succeeded.
+- If unauthorized access is suspected, isolate the affected macOS host from the network.
+- Implement IP blocking or rate limiting on the SSH service to reduce further login attempts.
+- Review and reset credentials for affected user accounts if compromise is confirmed.
+- Conduct a thorough review of the host's SSH configuration and enabled Remote Login settings.
+- Escalate to the security operations team if additional hosts show similar patterns.
+- Enhance monitoring for SSH authentication anomalies across the environment.
 
 ==== Setup
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-malicious-powershell-based-on-alert-correlation.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-malicious-powershell-based-on-alert-correlation.asciidoc
index ef3fe0c61b..57905d94a6 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-malicious-powershell-based-on-alert-correlation.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-malicious-powershell-based-on-alert-correlation.asciidoc
@@ -28,7 +28,7 @@ Identifies PowerShell script blocks linked to multiple distinct PowerShell detec
 * Rule Type: Higher-Order Rule
 * Resources: Investigation Guide
 
-*Version*: 5
+*Version*: 7
 
 *Rule authors*: 
 
@@ -44,85 +44,63 @@ Identifies PowerShell script blocks linked to multiple distinct PowerShell detec
 *Triage and analysis*
 
 
-> **Disclaimer**:
-> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.
-
 
 *Investigating Potential Malicious PowerShell Based on Alert Correlation*
 
 
-This alert groups multiple PowerShell-related detections that reference the same ScriptBlock identifier. When several independent detections fire on a single script block, it often indicates a single execution chain combining multiple suspicious behaviors. Treat the contributing alerts as the primary evidence and use this correlation to prioritize investigation and scoping.
-
-Investigation goals:
-- Identify affected endpoints and users by pivoting to the contributing alerts.
-- Recover the complete script content associated with the ScriptBlock identifier and understand its intent.
-- Identify follow-on behavior (process, network, persistence) and scope the activity across the environment.
-
-
-*Key alert fields to review*
-
 
-- `Esql.script_block_id`: The ScriptBlock identifier used to correlate multiple alerts.
-- `Esql.kibana_alert_rule_name_count_distinct`: The number of distinct PowerShell-related rule names that contributed to the correlation.
-- `Esql.kibana_alert_rule_name_values`: The contributing rule names; use this list to quickly understand what detection logic was triggered.
-- `Esql._id_values`: The contributing alert document IDs; pivot to these source alerts for full context and supporting evidence.
+*Possible investigation steps*
 
 
-*Possible investigation steps*
+- What does the ES|QL grouped alert preserve about the suspicious PowerShell mix?
+  - Focus: treat `Esql.script_block_id`, `Esql.kibana_alert_rule_name_values`, `Esql._id_values`, preserved `host.id` / `user.id`, and `Esql.kibana_alert_rule_name_count_distinct` as search clues, not evidence.
+  - Implication: escalate if rule names span obfuscation, download, execution, persistence, credential access, or defense evasion for one host/user; lower suspicion only when recovered source alerts/events show one recognized detection-validation script or controlled encoded-content automation pattern.
 
+- Do the contributing alerts bind the summary to one script execution?
+  - Focus: recover contributing alerts around grouped-alert time using preserved host/user, `Esql.kibana_alert_rule_name_values`, and script-block ID; use `Esql._id_values` only when alert search supports those IDs.
+  - Hint: recover contributing alerts before interpreting grouped behavior; ES|QL grouped alerts lack member-event Timeline pivots and reliable source-event time, PID, or entity anchors.
+  - Implication: treat as one execution chain only when source alerts and events align to one host, one user, one source-event window, and one script-block ID; keep unresolved if timestamps, script evidence, PID reuse risk, or entity scope conflict.
 
-- Understand what drove the correlation:
-  - Review `Esql.kibana_alert_rule_name_count_distinct` to gauge overall confidence and urgency.
-  - Review `Esql.kibana_alert_rule_name_values` and group the contributing detections by behavior (for example, obfuscation/encoding, suspicious execution, network retrieval, or persistence-related activity). Use this grouping to decide what evidence is most important to validate first.
+- Can you reconstruct and interpret the source PowerShell script block?
+  - Focus: using recovered source-event host, process, and time, query PowerShell 4104 or source events; match `powershell.file.script_block_id`, order `powershell.sequence` / `powershell.total`, and read script-block text.
+  - Implication: escalate when reconstructed text shows encoded/decoded stages, download cradles, reflection, hosted System.Management.Automation execution, credential access, persistence, or defense evasion; missing fragments or source PowerShell telemetry are unresolved, not benign.
 
-- Pivot to the contributing alerts and capture execution context:
-  - Use `Esql._id_values` to open each contributing alert and collect the affected host and user context, along with the earliest and latest timestamps across the set.
-  - Confirm the contributing alerts represent the same ScriptBlock ID and are not unrelated alerts that happen to share similar message content.
-  - Identify whether the activity is limited to a single endpoint or appears on multiple endpoints. Multiple endpoints can indicate script reuse, distribution, or remote execution.
+- Which process and launch chain executed the script block?
+  - Focus: use recovered time, `host.id`, and process identifiers to find the process start; collect `process.entity_id`, `process.command_line`, `process.parent.command_line`, and `process.Ext.authentication_id`.
+  - Hint: if no process start appears, expand time first; if still missing, scope later file, registry, and network review to recovered source-event host/user/process/time.
+  - Implication: escalate when the launcher is a document, browser, remote-management tool, scheduled task, unexpected script or .NET host, or command line with encoded, hidden, bypass, download, or dynamic evaluation; lower suspicion only when the same parent, command, user, and host bind to the exact recovered benign workflow.
 
-- Reconstruct the full script block content:
-  - Using `Esql.script_block_id`, locate all available records (alerts and/or underlying telemetry referenced by the contributing alerts) tied to the same identifier.
-  - If the script content is split across multiple fragments, reconstruct it in the correct order before assessing intent.
-  - Identify any decoded/deobfuscated output that the script generates during execution and capture it as evidence for scoping.
+- Did the process stage payloads, persistence, or security-impacting changes?
+  - Focus: scope file and registry events to recovered `process.entity_id` or fallback source-event host/PID/time context; review `file.path`, `file.origin_url`, `registry.path`, `registry.value`, and `registry.data.strings`.
+  - Implication: escalate when the script writes executable or scriptable content to user-writable or startup paths, leaves internet provenance, modifies persistence or security keys, or later executes staged content; lower suspicion only when artifacts stay inside the exact recovered benign workflow. Missing file or registry telemetry does not clear the alert.
 
-- Assess intent and capability based on the recovered script:
-  - Look for evidence of staged execution, such as multiple layers of decoding, dynamic code generation, or invocation of additional code.
-  - Identify indicators that can be used for scoping (for example, external destinations, file locations, created services, or suspicious child process activity referenced by the contributing alerts).
+- Did network or session evidence fit offensive PowerShell use?
+  - Focus: scope DNS/connections to recovered `process.entity_id` or source-event host/PID/time context; read `dns.question.name`, `destination.ip`, and `destination.port`; when origin matters, bridge `process.Ext.authentication_id` to `winlog.event_data.TargetLogonId`.
+  - Implication: escalate when the script reaches rare or public destinations, pulls content, contacts infrastructure unrelated to the recovered workflow, or runs from an unexpected remote session; missing network or Windows Security telemetry is unresolved, not benign.
 
-- Correlate with adjacent activity during the same timeframe:
-  - Process activity: check for unusual parent-child relationships involving PowerShell and unexpected child processes following the script block execution.
-  - Network activity: review outbound connections and DNS activity that align with the execution window, especially first-time or rare destinations.
-  - File and registry activity: look for payload staging, configuration changes, or persistence artifacts created near the execution window.
-  - Authentication activity: review for suspicious logons or account changes that coincide with the script execution, especially if activity spans multiple endpoints.
+- If local evidence is suspicious or unresolved, does the same pattern recur elsewhere enough to change scope?
+  - Focus: related alerts for preserved `user.id` over 48 hours, looking for the same `Esql.kibana_alert_rule_name_values`, reconstructed script fragment, launch context, or extracted indicators. !{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 user-scoped alerts are quiet or ambiguous, compare related alerts for preserved `host.id` over 48 hours. !{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 response when the same script body, rule-name mix, or indicators appear on unrelated hosts or users; keep scope local when recurrence stays on the host under review, but do not close from recurrence alone.
 
-- Scope and hunt for additional occurrences:
-  - Search for other alerts containing the same `Esql.script_block_id` to determine if the script was reused or executed repeatedly.
-  - Use indicators and behaviors observed in the contributing alerts to identify related activity in other alerts and telemetry sources, and establish first-seen/last-seen boundaries.
+- Weigh contributing-alert alignment, reconstructed script, launch chain, artifacts, destinations, and host/user scope; escalate for offensive tooling, unauthorized execution, staged payloads, persistence, or suspicious destinations; close only when source evidence binds to one exact benign workflow, using outside confirmation only for facts telemetry cannot prove; preserve artifacts and escalate on conflicts or missing telemetry.
 
 
 *False positive analysis*
 
 
-- Legitimate administrative automation can produce multiple detections if it uses dynamic script generation, embedded encoded content, or downloads content at runtime. Validate whether the affected hosts, users, and timing align with an approved maintenance activity.
-- If the same ScriptBlock content repeatedly maps to a known benign workflow, document the expected behavior and tune upstream detections to better distinguish that workflow, rather than suppressing this correlation rule.
+- Authorized red-team, lab, or detection-validation can trigger several PowerShell rules on one script. Confirm alert mix, reconstructed script, launch chain, `user.id`, and `host.id` match exact test scope; if records are unavailable, recurrence can support scoping but cannot close the alert.
+- Endpoint management or deployment automation can trigger multiple detections through encoded content, dynamic script generation, or controlled downloads. Confirm `powershell.file.script_block_text`, parent/child command lines, artifacts, and destinations align with one managed workflow. If script body, destinations, or follow-on artifacts diverge, do not close as benign.
+- Before an exception, validate stable benign anchors: `user.id`, `host.id`, parent/child command lines, script fragment, and destination or artifact pattern. Avoid exceptions on ES|QL summary fields or `Esql.script_block_id`; they are alert-local or execution-specific.
 
 
 *Response and remediation*
 
 
-- If the activity is confirmed or strongly suspected to be malicious:
-  - Contain impacted endpoints to prevent additional execution and follow-on actions.
-  - Restrict, reset, or rotate credentials for involved accounts as appropriate, especially for privileged or shared accounts.
-  - Remove identified artifacts and persistence mechanisms (for example, suspicious services or dropped binaries) and remediate any affected systems.
-  - Block or monitor indicators identified from the contributing alerts (external destinations, file locations, or other observable artifacts) to prevent reinfection and support hunting.
-
-- Validation and recovery:
-  - Use `Esql.script_block_id` and the contributing alert set in `Esql._id_values` to verify that the activity has ceased and to identify any additional impacted endpoints.
-  - Continue monitoring for recurrence of the same ScriptBlock ID or the contributing behaviors to confirm remediation effectiveness.
-
-- Post-incident:
-  - Preserve the recovered script content and the full set of contributing alerts as evidence.
-  - Identify and address the initial execution mechanism indicated by the contributing alerts and improve preventative controls and logging coverage to reduce recurrence.
+- If confirmed benign, document the alert mix, reconstructed script, launch chain, and recovered host/user context before reversing containment. Build exceptions from stable recovered workflow anchors, not ES|QL summary fields alone.
+- If suspicious but unconfirmed, preserve contributing alerts, `Esql._id_values`, `Esql.script_block_id`, rule-name values, reconstructed script text, recovered parent/child command lines, file/registry paths, and DNS/destination indicators before cleanup. Apply reversible containment first, such as temporary destination restrictions or heightened monitoring on recovered `host.id` and `user.id`; isolate or strengthen account action only if the script is still executing, staging payloads, or reaching suspicious destinations and host role allows.
+- If confirmed malicious, record entity IDs, command lines, and indicators, then isolate the host when lateral-movement or active-payload risk is present. Stop the PowerShell process or descendants only after preserving evidence; if direct response is unavailable, escalate with the evidence set. Block confirmed malicious destinations, URLs, hashes, and script paths; eradicate only tied files, registry changes, tasks, services, and payloads; remediate the launch path; and review related hosts/users before destructive cleanup.
+- Post-incident hardening: preserve or expand PowerShell 4104 logging, source-alert retention, endpoint process telemetry, and Windows Security logs when gaps limited recovery; where operations allow, restrict high-risk PowerShell through signed scripts, Constrained Language Mode, JEA, or WinRM controls. Document the rule-name mix, observables, and adjacent variants such as indirect System.Management.Automation execution.
 
 
 ==== Rule query
@@ -140,17 +118,24 @@ from .alerts-security.* metadata _id
 | where Esql.script_block_id is not null
 
 // keep relevant fields for further processing
-| keep kibana.alert.rule.name, Esql.script_block_id, _id
+| keep kibana.alert.rule.name, Esql.script_block_id, _id, user.id, process.pid, host.id
 
 // count distinct alerts and filter for matches above the threshold
 | stats
     Esql.kibana_alert_rule_name_count_distinct = count_distinct(kibana.alert.rule.name),
     Esql.kibana_alert_rule_name_values = values(kibana.alert.rule.name),
-    Esql._id_values = values(_id)
+    Esql._id_values = values(_id),
+    Esql.user_id_values = values(user.id),
+    Esql.process_pid_values = values(process.pid),
+    Esql.host_id_values = values(host.id)
   by Esql.script_block_id
 
 // Apply detection threshold
 | where Esql.kibana_alert_rule_name_count_distinct >= 5
+| eval user.id = MV_MIN(Esql.user_id_values),
+       process.pid = MV_MIN(Esql.process_pid_values),
+       host.id = MV_MIN(Esql.host_id_values)
+| keep host.id, user.id, process.pid, Esql.*
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-modification-of-accessibility-binaries.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-modification-of-accessibility-binaries.asciidoc
index 6d1f3b221b..0f70ab2387 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-modification-of-accessibility-binaries.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-modification-of-accessibility-binaries.asciidoc
@@ -39,7 +39,7 @@ Windows contains accessibility features that may be launched with a key combinat
 * Data Source: Sysmon
 * Data Source: Microsoft Defender XDR
 
-*Version*: 217
+*Version*: 218
 
 *Rule authors*: 
 
@@ -59,61 +59,85 @@ Windows contains accessibility features that may be launched with a key combinat
 *Investigating Potential Modification of Accessibility Binaries*
 
 
-Adversaries may establish persistence and/or elevate privileges by executing malicious content triggered by accessibility features. Windows contains accessibility features that may be launched with a key combination before a user has logged in (ex: when the user is on the Windows logon screen). An adversary can modify the way these programs are launched to get a command prompt or backdoor without logging in to the system.
+*Possible investigation steps*
 
-More details can be found https://attack.mitre.org/techniques/T1546/008/[here].
 
-This rule looks for the execution of supposed accessibility binaries that don't match any of the accessibility features binaries' original file names, which is likely a custom binary deployed by the attacker.
+- Does the alert show an accessibility-feature launch path running a different binary identity?
+  - Focus: `process.parent.name`, `user.name`, `process.args`, and `process.pe.original_file_name`.
+  - Implication: escalate when the logon accessibility path starts a SYSTEM process whose PE original name does not fit the requested feature; lower initial concern only when this exact host and binary match a narrow exception from prior verified testing. Otherwise, the mismatch stays suspicious.
 
-> **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.
+- What binary actually ran from the accessibility launch?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the executable is a shell, scripting or administration tool, user-writable copy, unsigned or unexpectedly signed binary, or rare hash for the host; stable hash or trusted signer lowers identity concern but does not clear the SYSTEM accessibility mismatch.
 
+- Did the launched binary create a SYSTEM follow-on process?
+  - Focus: process starts on the same `host.id` where `process.parent.entity_id` matches `process.entity_id`, checking `process.executable`, `process.args`, and `user.name`. !{investigate{"description":"","label":"Child process starts from the accessibility binary","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when follow-on activity opens a shell, scripting engine, remote-access tool, credential or account utility, or long-lived SYSTEM process; no children lowers follow-on severity only, not the accessibility mismatch.
+  - Hint: if `process.entity_id` is missing, use `host.id`, `process.pid`, and a tight alert-time window as a weaker fallback.
 
-*Possible investigation steps*
+- Do surrounding process starts show preparation, replacement, or cleanup?
+  - Focus: same-`host.id` process starts in a tight alert-time window, prioritizing parent or child links to the alerting process, then same `user.id`; check `process.name`, `process.args`, and `process.parent.name`. !{investigate{"description":"","label":"Process starts on the host near the alert","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when takeown, icacls, copy, robocopy, reg, PowerShell, cmd, or service-control activity surrounds the accessibility launch; absence of setup or cleanup reduces preparation evidence only, not the mismatch.
+  - Why: runtime evidence may not show whether abuse used binary replacement or IFEO/debugger redirection, so surrounding process starts can expose the setup path to preserve or restore.
 
+- If local evidence is suspicious or unresolved, is this a local one-off or repeated accessibility-hijack pattern?
+  - Focus: prior alerts and process starts for the same `host.id`, then the same `process.hash.sha256`, `process.executable`, or `process.pe.original_file_name` across other hosts.
+    - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Process events with the same SHA-256","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate scope when the same binary identity or PE mismatch appears on additional hosts, recurs after attempted cleanup, or clusters outside a recognized validation cohort; no recurrence lowers scope only. Do not close on absence or recurrence alone.
 
-- 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 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.
-- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
-- Examine the host for derived artifacts that indicate suspicious activities:
-  - Analyze the file using a private sandboxed analysis system.
-  - Observe and collect information about the following activities in both the sandbox and the alert subject host:
-    - Attempts to contact external domains and addresses.
-      - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.
-      - Examine the DNS cache for suspicious or anomalous entries.
-        - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}}
-    - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
-    - Examine the host services for suspicious or anomalous entries.
-      - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}}
-      - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}}
-      - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}}
-  - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
-- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.
+- Escalate for suspicious binary identity, SYSTEM follow-on activity, preparation or cleanup, or unexplained recurrence. Close only when process evidence matches a preexisting narrow exception for one controlled test on this host; if absent or mixed, preserve the binary, process tree, and alert records and escalate.
 
 
 *False positive analysis*
 
 
-- This activity should not happen legitimately. The security team should address any potential benign true positive (B-TP), as this configuration can put the user and the domain at risk.
+- Accessibility-feature hijacking is an operational anti-pattern. The main benign path is a preexisting, narrow security-test exception for this exact behavior. Compare the alert to stable exception anchors: `host.id`, `process.hash.sha256`, `process.executable`, `process.args`, `process.pe.original_file_name`, parent context, and child-process evidence; contradictions prevent benign closure.
+- Without a preexisting exception, do not close from recurrence alone. Treat stable recurrence as candidate exception evidence and keep the case open or escalated until the exact activity is verified.
+- Build exceptions only from stable test anchors: `process.hash.sha256`, signer identity, `process.args`, `process.pe.original_file_name`, and `host.id` or a tightly managed test cohort. Avoid exceptions on `process.name`, accessibility filenames, parent name, or `user.name` alone.
 
 
 *Response and remediation*
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Isolate the involved host to prevent further post-compromise behavior.
-- If the triage identified malware, search the environment for additional compromised hosts.
-  - Implement temporary network rules, procedures, and segmentation to contain the malware.
-  - Stop suspicious processes.
-  - Immediately block the identified indicators of compromise (IoCs).
-  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
-- Remove and block malicious artifacts identified during triage.
-- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
-- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
-- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+- If confirmed benign:
+  - Record the exact evidence that confirmed the test: host, binary hash and signer, accessibility target, parent context, and absence of suspicious child or surrounding process activity.
+  - Reverse temporary containment after the evidence record is complete.
+  - Create a narrow exception only after the same test pattern is stable across prior alerts and limited to the validated cohort.
+- If suspicious but unconfirmed:
+  - Preserve the alert record, process tree, executable copy, hash, signature details, child-process events, and surrounding process events before containment.
+  - Apply reversible containment tied to the findings, such as temporary host isolation, restricted remote access, or increased monitoring on the affected host, and avoid deleting binaries or restoring system state until evidence is preserved.
+- If confirmed malicious:
+  - Record `process.entity_id`, `process.pid`, command arguments, executable path, hash, signer, and any child process identifiers before containment, termination, or cleanup.
+  - Contain the endpoint based on the binary identity, SYSTEM lineage, follow-on process activity, and recurrence scope that established malicious use.
+  - Block confirmed malicious hashes or binaries, then terminate active shells or backdoors.
+  - Restore affected accessibility binaries to known-good state, validate the accessibility launch path no longer starts the suspicious binary, and remediate the account, deployment tool, or remote-access path that allowed the change.
+  - Reset credentials only when follow-on activity or separate identity evidence shows account misuse.
+- Post-incident hardening:
+  - Restrict local administrator paths that can replace or redirect Windows accessibility features, and enforce application control for accessibility-feature execution where feasible.
+  - Ensure Remote Desktop exposure uses gateway controls and Network Level Authentication so remote users authenticate before the login screen path can be abused.
+  - Document the confirmed test pattern or malicious artifact set so future analysts can separate repeat validation from repeat abuse.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
 
 
 ==== Rule query
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-notepad-markdown-rce-exploitation.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-notepad-markdown-rce-exploitation.asciidoc
index fb43b62d0b..3ada08d822 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-notepad-markdown-rce-exploitation.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-notepad-markdown-rce-exploitation.asciidoc
@@ -40,7 +40,7 @@ Identifies a process started by Notepad after opening a Markdown file. This may
 * Data Source: SentinelOne
 * Resources: Investigation Guide
 
-*Version*: 4
+*Version*: 5
 
 *Rule authors*: 
 
@@ -60,39 +60,92 @@ Identifies a process started by Notepad after opening a Markdown file. This may
 *Investigating Potential Notepad Markdown RCE Exploitation*
 
 
-This rule detects a new child process launched by `notepad.exe` when Notepad was opened with a Markdown (`.md`) file.
-This behavior can indicate exploitation of a Notepad remote code execution vulnerability where crafted Markdown content
-triggers unintended process execution.
-
 
 *Possible investigation steps*
 
 
-- Validate the parent-child relationship and confirm `notepad.exe` is the direct parent of the suspicious process.
-- Review the full command line of both parent and child processes, including the Markdown file path in `process.parent.args`.
-- Identify the Markdown file source (email attachment, browser download, chat client, removable media, or network share).
-- Inspect process ancestry and descendants for additional payload execution, script interpreters, or LOLBIN activity.
-- Correlate with file, registry, and network events around the same timestamp to identify follow-on behavior.
-- Determine whether the child process and its execution path are expected in your environment.
+- What exact Notepad-to-child path did the alert preserve?
+  - Why: CVE-2026-20841 abuse centers on Markdown link handling that invokes unsafe protocol handlers, so the launched child and target are decisive.
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.args`, child `process.executable`, and child `process.command_line`.
+  - Implication: escalate when Notepad opened Markdown and launched a shell, script host, downloader, browser, archive handler, installer, or custom protocol handler with a URL, UNC path, file URI, app installer URI, or staged payload; lower suspicion only when child and target match a confirmed validation workflow.
+
+- What does child binary identity add to command intent?
+  - Focus: child `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.pe.original_file_name`.
+  - Implication: escalate when the child is unsigned, user-writable, signer/name-mismatched, or unusual for Markdown link handling; reduce suspicion only when signer, path, hash history, and command target all fit the same confirmed validation workflow.
+
+- Does parent launch context point to lure delivery or controlled use?
+  - Focus: Markdown path from `process.parent.args`, `process.parent.command_line`, `user.id`, `host.id`, and `host.name`.
+  - Implication: escalate when the path is in downloads, mail or chat caches, temp, removable media, network shares, or lure-like filenames; lower suspicion only when source path and child target match a confirmed validation case for the same user or host.
+
+- Did the child start more exploit-chain processes?
+  - Focus: process events on `host.id` where `process.parent.entity_id` links to `process.entity_id`, recording descendant `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child process events for the Notepad-spawned child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: prefer entity ID-linked descendants; treat PID-only matches as candidates tightly anchored to `@timestamp`. Inspect `process.Ext.ancestry` only when direct lineage is incomplete.
+  - Implication: escalate for descendant shells, script interpreters, LOLBins, installers, payload runners, or browser-to-download chains; no descendants limits process scope but does not clear the Notepad launch.
+
+- Did the child stage artifacts for later execution?
+  - Focus: if file telemetry exists, review process-scoped `file.path`, `file.Ext.original.path`, and later `process.executable` reuse of a written path. !{investigate{"description":"","label":"File events for the same child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: recover with `host.id` + `process.entity_id`; if unavailable, use `host.id` + `process.pid` + a tight alert window. Missing file telemetry is unresolved, not benign.
+  - Implication: escalate when the child writes executables, scripts, shortcuts, archives, or renamed payloads to user-writable paths, or a written artifact later runs; clean available file telemetry means staging is not corroborated, not that the alert is benign.
+
+- Did the child contact payload-delivery destinations?
+  - Focus: if DNS or connection telemetry exists, review `dns.question.name`, `destination.ip`, and `destination.port`. !{investigate{"description":"","label":"Network events for the same child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: recover with `host.id` + `process.entity_id`; if unavailable, use `host.id` + `process.pid` + a tight alert window. Missing DNS or connection telemetry is unresolved, not benign.
+  - Implication: escalate when the child resolves or connects to rare, external, newly introduced, or delivery-oriented destinations outside its role; clean available network telemetry removes one corroborator but cannot override suspicious alert-local execution.
+
+- If local evidence is suspicious or unresolved, does the pattern change scope?
+  - Focus: related alerts for the same `user.id` over 48 hours, comparing child `process.executable`, child `process.command_line`, and source-path patterns from `process.parent.args` when present. !{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 user view is empty or ambiguous, compare related alerts for the same `host.id` over 48 hours before broadening. !{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 related alerts show the same Notepad-child pattern, source-path family, or delivery indicator across unrelated users or hosts; use recurrence for scope only, not benign closure.
+
+- Escalate when child intent, descendant lineage, artifact staging, or destinations point to payload delivery, even if one conditional telemetry family is absent; close only when source path, child identity, command target, and `user.id`/`host.id` context prove one benign workflow; preserve evidence and escalate when telemetry is missing or contradictory.
 
 
 *False positive analysis*
 
 
-- Legitimate automation or editor extensions may occasionally spawn helper processes from Notepad workflows.
-- User-driven workflows that invoke external tools from Markdown previews can trigger this behavior.
-- If benign, tune by excluding known-safe child process names, hashes, signed binaries, and approved file paths.
+- Authorized CVE validation, QA, or security lab activity can trigger this rule when controlled Markdown samples intentionally launch a stable helper. Confirm `process.parent.args`, child `process.executable`, child hash or signer, child `process.command_line`, and `user.id`/`host.id` cohort all match the same validation workflow; prior alerts support stability only after those anchors align.
+- Before creating an exception, validate stability for the same child identity, child command-target pattern, Markdown path family from `process.parent.args`, and `user.id` or `host.id` scope. Avoid exceptions on `process.parent.name`, `process.name`, or Notepad alone.
 
 
 *Response and remediation*
 
 
-- Isolate affected endpoints until scope is understood.
-- Terminate suspicious child and descendant processes initiated from `notepad.exe`.
-- Quarantine and preserve the triggering Markdown file for forensic analysis.
-- Run endpoint malware scans and collect volatile artifacts (running processes, network connections, autoruns).
-- Patch Windows/Notepad to the latest security update level addressing the vulnerability.
-- Hunt for the same parent-child pattern across other hosts to identify additional impacted systems.
+- If confirmed benign:
+  - Reverse temporary containment and record the Markdown path, child process identity, command target, and cohort evidence that confirmed the benign workflow. Build an exception only for the same stable `user.id` or `host.id` scope and child identity.
+- If suspicious but unconfirmed:
+  - Preserve the triggering Markdown file, parent `process.parent.command_line`, child `process.entity_id`, child `process.command_line`, descendant process identifiers, written artifact paths, and DNS or IP indicators before cleanup.
+  - Apply reversible containment tied to observed indicators, such as temporary restriction of the observed destination or heightened monitoring on the affected `host.id` and `user.id`.
+  - Escalate to host isolation if the child continues spawning payloads, downloading content, or contacting suspicious destinations after preservation.
+- If confirmed malicious:
+  - Isolate the host first, then stop the malicious child and descendant `process.entity_id` values after recording `process.entity_id`, `process.command_line`, the Markdown path from `process.parent.args`, and related artifact or destination indicators. If direct response is unavailable, hand off the preserved evidence set to the containment team.
+  - Block confirmed malicious domains, IPs, URLs, hashes, and child process paths identified during the investigation.
+  - Eradicate only the dropped files, startup artifacts, scheduled tasks, registry changes, and payload runners tied to the exploit chain, then quarantine the triggering Markdown file and remediate its delivery path.
+- Post-incident hardening:
+  - Update the Windows Notepad App to a version that remediates CVE-2026-20841, and restrict unsafe protocol-handler launch exposure for Markdown viewers where enterprise controls support it.
+  - Preserve or expand file and network telemetry if missing visibility prevented confirmation of Markdown source, payload staging, or destination activity.
+  - Record the Markdown delivery path, child-process pattern, and adjacent protocol-handler or payload variants in the case notes.
+
+
+==== 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
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-hacktool-script-by-author.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-hacktool-script-by-author.asciidoc
index 48d5dae5c2..52b875d70c 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-hacktool-script-by-author.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-hacktool-script-by-author.asciidoc
@@ -7,8 +7,8 @@ Identifies PowerShell script block content containing known offensive-tool autho
 
 *Rule indices*: 
 
-* winlogbeat-*
 * logs-windows.powershell*
+* winlogbeat-*
 
 *Severity*: high
 
@@ -33,7 +33,7 @@ Identifies PowerShell script block content containing known offensive-tool autho
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 109
+*Version*: 110
 
 *Rule authors*: 
 
@@ -49,83 +49,77 @@ Identifies PowerShell script block content containing known offensive-tool autho
 *Triage and analysis*
 
 
-> **Disclaimer**:
-> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.
-
 
 *Investigating Potential PowerShell HackTool Script by Author*
 
 
-This rule Detects PowerShell scripts that contains attribution strings commonly found in publicly available offensive PowerShell tooling. These artifacts are often present in headers or comment blocks but may also appear within embedded modules or minimally modified scripts. Use the script block content and metadata to reconstruct what ran, determine the likely source, and scope related activity across hosts and users.
-
 
-*Key alert fields to review*
+*Possible investigation steps*
 
 
-- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.
-- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.
-- `powershell.file.script_block_text`: Script block content that matched the detection logic.
-- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.
-- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
-- `powershell.file.script_block_length`: Script block length (size) context.
+- What did the alert-local author match show?
+  - Focus: `powershell.file.script_block_text`, `powershell.file.script_block_length`, `file.path`, and `user.id` on `host.id`.
+  - Implication: escalate when the handle appears beside executable functions, encoded strings, download, credential, discovery, remote-execution, or persistence logic; lower suspicion when it is only an inert header or comment in a recognized lab, test, or community-module path with harmless surrounding code.
 
+- Can you reconstruct the complete script block before judging intent?
+  - Focus: collect and order fragments on `host.id` with `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and `powershell.file.script_block_text`. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when reconstruction reveals hidden stages, helper functions, obfuscation, decoding, or payload logic; keep unresolved if fragments are missing because they can hide decisive code.
 
-*Possible investigation steps*
+- Was the script file-backed or fileless, and what does that say about delivery?
+  - Focus: `file.path`, `file.directory`, and `file.name` when present; absent `file.path` suggests inline, generated, or interactive execution.
+  - Implication: escalate when fileless execution, user-writable paths, shares, temp or staging folders, or suspicious names pair with hacktool code; lower suspicion when a stable repository, lab path, or community-module path matches benign content.
 
+- Can you recover the PowerShell process and explain launch?
+  - Focus: With endpoint process telemetry, recover the matching process via `host.id + process.pid` before interpreting `process.*` or `process.parent.*`. Capture `process.entity_id`, `process.command_line`, `process.parent.executable`, and `process.parent.command_line`. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: confirm timestamps to reduce PID-reuse ambiguity; if no process start event appears, expand time before falling back to `host.id`, `user.id`, and alert time.
+  - Implication: escalate when a document, browser, chat client, remote-management tool, scheduled task, service, or unexpected script host launched the code without matching lab, assessment, support, or deployment evidence; lower suspicion when lineage matches the exact workflow proven by script content.
 
-- Capture basic context and triage priority:
-  - Record `@timestamp`, `host.name`/`host.id`, and `user.name`/`user.domain`/`user.id`.
-  - Use host and identity context (asset owner, role, and expected admin activity) to determine whether this execution is likely authorized for the alerted user and endpoint.
+- What capability or observables move this beyond attribution text?
+  - Focus: reconstructed script for credential access, discovery, remote execution, payload delivery, persistence, AMSI or logging tampering, reflection, or decode-and-execute logic; extract domains, IPs, URLs, paths, accounts, registry targets, and reusable function or module names.
+  - Implication: escalate when the body implements offensive capability or yields high-signal observables; lower suspicion only when it remains benign utility logic tied to a recognized workflow.
 
-- Reconstruct the complete script block before making an assessment:
-  - Review `powershell.file.script_block_text` and identify the specific author handle or attribution string and its surrounding lines.
-  - If the content appears truncated or the event indicates multiple parts, use `powershell.file.script_block_id` together with `powershell.sequence` and `powershell.total` to assemble the full script in the correct order. Confirm all sequence parts are present.
-  - Use `powershell.file.script_block_length` as additional context (for example, to distinguish short snippets from large modules) and preserve the reconstructed content for evidence and hunting.
+- Did script-extracted file or registry targets appear on the host?
+  - Focus: With file or registry telemetry, search same-PID events around `@timestamp` for extracted `file.path`, `registry.path`, `registry.value`, or `registry.data.strings`. !{investigate{"description":"","label":"File and registry events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when extracted payload paths are created or executed, or registry targets indicate persistence or security changes; missing artifact or configuration telemetry is unresolved, not benign.
 
-- Determine the likely source of the script content:
-  - If `file.path`/`file.name` (and `file.directory`) are present, treat this as file-backed execution and note whether the location and filename align with approved script storage or deployment paths for that host.
-  - If `file.path` is a network share (UNC) or otherwise unusual for the host, treat it as higher risk until validated.
-  - If file fields are absent, treat the script block as inline, interactive, or dynamically generated content. Prioritize review for scripts that fetch, decode, or build additional code at runtime.
-  - If a file path is present, pivot on `file.path` and `file.name` to identify other executions or duplicates of the same script across users and hosts.
+- Did extracted network or identity observables confirm active offensive use?
+  - Focus: With network telemetry, search same-PID DNS and connection events for extracted domains in `dns.question.name` or `dns.resolved_ip` and IPs in `destination.ip`. !{investigate{"description":"","label":"Network and DNS events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} Review Windows 4624 or 4648 with `winlog.event_data.TargetUserName` and `winlog.event_data.SubjectUserName` for extracted accounts.
+  - Implication: escalate when the host contacts extracted infrastructure, downloads content, or shows remote, credential, or lateral-use evidence. Missing network or authentication telemetry is unresolved, not benign.
 
-- Assess intent from the content and extract observables:
-  - Determine whether the match is limited to comments/metadata or is accompanied by functional code.
-  - Look for behaviors that commonly accompany offensive PowerShell tooling, such as broad host or domain discovery, credential access helpers, privilege manipulation, remote execution primitives, persistence logic, or payload delivery mechanisms.
-  - Extract and record observables embedded in `powershell.file.script_block_text` (for example, domains, IPs, URLs, hostnames, usernames, file paths, or registry paths) and use them to pivot for additional activity.
+- If the script content or launch chain remains suspicious or unresolved, does recurrence change scope?
+  - Focus: related alerts for `user.id` in the last 48 hours, comparing author string, reconstructed script body, file source, launch pattern, and extracted observables. !{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 user view is quiet or ambiguous, compare related alerts for `host.id` in the last 48 hours. !{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 the same script body or extracted observables reach unrelated users or hosts; keep local when recurrence stays within the same lab, assessment, support, or deployment host/user cohort. Do not close on recurrence alone if script content or recovery remains unresolved.
 
-- Scope and correlate related activity:
-  - Search for additional script block events containing the same author handle within `powershell.file.script_block_text` across the environment. Start with the same `user.id` and `host.id`, then expand to other users and hosts.
-  - On the same `host.name`, review other script block events from the same `user.name` in the minutes before and after the alert to identify setup actions (module imports, function definitions) and follow-on execution.
-  - If other endpoint telemetry is available, correlate around `@timestamp` on the same host to identify:
-    - The PowerShell host process and any parent process responsible for launching it.
-    - Network connections, file writes, or registry changes consistent with the script content and extracted observables.
-    - Authentication activity for `user.name` that could explain the session context (interactive use vs remote access).
+- Escalate on reconstructed capability, unauthorized launch, follow-on evidence, or missing/conflicting required telemetry; close only when the author match, reconstructed script, source path, launch context, observables, and `user.id` or `host.id` scope bind one exact benign workflow, with outside confirmation when telemetry cannot verify it.
 
 
 *False positive analysis*
 
 
-- Legitimate administrative scripts may incorporate third-party modules that include author headers; these are typically file-backed and executed from expected locations or managed repositories.
-- False positives are more likely when the author string is isolated within comments and there is minimal additional script functionality; they are less likely when the script implements operational capabilities aligned with offensive tooling.
+- Authorized testing, red-team, malware-analysis, validation, community-module, or admin scripts can retain author strings. Confirm the reconstructed body, exact `user.id` and `host.id` scope, `file.path` or launch context, recognized test or lab records when telemetry cannot prove legitimacy, and no contradictory observables or follow-on activity.
+- Before creating an exception, validate recurrence of the same benign workflow with the same `powershell.file.script_block_text` fragment, `file.path` or launch source, and `user.id` or `host.id` scope. Avoid author-string-only exceptions because unrelated offensive scripts can reuse the same handle.
 
 
 *Response and remediation*
 
 
-- If activity is unauthorized or suspicious:
-  - Preserve the full reconstructed script content (all parts) and retain supporting context: `powershell.file.script_block_id`, `host.id`, `host.name`, `user.id`, `user.name`, `user.domain`, and `@timestamp`.
-  - Scope impact by searching for the same author handle and extracted observables across PowerShell script block logs to identify additional affected hosts and accounts.
-  - If `file.path` is present, locate and quarantine the referenced script per your procedures and review the endpoint for other copies that share the same `file.name`.
-  - Apply containment measures appropriate to the risk (for example, isolate the endpoint from the network) if the content indicates credential access, remote execution, or payload delivery.
-  - Review the initiating account for compromise and take credential and access control actions consistent with your incident response process.
-
-- If activity is authorized:
-  - Document the activity (owner, timeframe, intended hosts) and validate alignment with change management or testing approvals.
-  - Ensure the SOC has an up-to-date list of approved users and endpoints for testing. Consider environment-specific tuning to reduce recurring noise while preserving coverage elsewhere.
-
+- If confirmed benign:
+  - Reverse temporary containment and document the reconstructed script, source path, launch context, `user.id`, and `host.id` evidence confirming the legitimate workflow. Build an exception only for that exact workflow and scope.
+- If suspicious but unconfirmed:
+  - Preserve or export alert details, reconstructed script with fragment metadata, process PID, source path, extracted indicators, and recovered launch details before containment or cleanup.
+  - Apply reversible containment tied to the evidence, such as temporary restrictions for extracted destinations or heightened monitoring on affected `host.id` and `user.id`.
+  - Escalate to host isolation or stronger account action only if the script is still executing, staging payloads, reaching suspicious destinations, or showing credential or lateral-use evidence, and the host role tolerates isolation.
+- If confirmed malicious:
+  - Preserve the reconstructed script, recovered process entity ID and launch details, extracted indicators, staged artifacts, and timeline before isolation, process termination, or cleanup.
+  - Isolate the host when script capability, launch context, follow-on artifacts, or destination evidence confirms unauthorized activity and the host role tolerates isolation.
+  - Block confirmed malicious destinations, URLs, file hashes, and script paths found during triage.
+  - Eradicate only dropped files, registry changes, scheduled tasks, services, and follow-on payloads tied to this script, then remediate the path that delivered or launched it.
+  - Review related hosts and users for the same author string, reconstructed script body, or extracted indicators before destructive cleanup so scoping is complete.
 - Post-incident hardening:
-  - Verify PowerShell logging coverage and retention are sufficient to reconstruct multi-part scripts during future investigations.
-  - Use observed handles and extracted observables to perform retrospective searches for earlier executions and related activity patterns in historical script block logs.
+  - Verify PowerShell 4104 logging coverage and retention are sufficient to reconstruct multi-part scripts and preserve process recovery context.
+  - Restrict authorized testing of public offensive PowerShell tooling to controlled hosts and identities.
+  - Document matched author strings, extracted observables, and author-stripped or rebranded variants surfaced during triage for future analyst reference.
 
 
 ==== Setup
@@ -168,7 +162,8 @@ host.os.type:windows and event.category:process and
       "_nullbind" or "_tmenochet" or
       "jaredcatkinson" or "ChrisTruncer" or
       "monoxgas" or "TheRealWover" or
-      "splinter_code"
+      "splinter_code" or "samratashok" or
+      "leechristensen" or "nikhil_mitt"
   ) and
   not powershell.file.script_block_text : ("Get-UEFIDatabaseSigner" or "Posh-SSH")
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-cve-2022-38028.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-cve-2022-38028.asciidoc
index 13edfe9496..3b92c8c56e 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-cve-2022-38028.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-cve-2022-38028.asciidoc
@@ -1,7 +1,7 @@
 [[potential-privilege-escalation-via-cve-2022-38028]]
 === Potential privilege escalation via CVE-2022-38028
 
-Identifies a privilege escalation attempt via exploiting CVE-2022-38028 to hijack the print spooler service execution.
+Identifies a potential privilege escalation attempt via CVE-2022-38028 through modification of the protected Print to PDF MPDW constraints script.
 
 *Rule type*: eql
 
@@ -35,7 +35,6 @@ Identifies a privilege escalation attempt via exploiting CVE-2022-38028 to hijac
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Privilege Escalation
-* Tactic: Defense Evasion
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
 * Data Source: Sysmon
@@ -44,7 +43,7 @@ Identifies a privilege escalation attempt via exploiting CVE-2022-38028 to hijac
 * Data Source: Crowdstrike
 * Resources: Investigation Guide
 
-*Version*: 210
+*Version*: 211
 
 *Rule authors*: 
 
@@ -60,47 +59,78 @@ Identifies a privilege escalation attempt via exploiting CVE-2022-38028 to hijac
 *Triage and analysis*
 
 
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
-
 
 *Investigating Potential privilege escalation via CVE-2022-38028*
 
 
-CVE-2022-38028 targets the Windows Print Spooler service, a core component managing print jobs. Adversaries exploit this by manipulating specific JavaScript files within system directories to gain elevated privileges. The detection rule identifies unauthorized file presence in critical paths, signaling potential exploitation attempts, leveraging multiple data sources for comprehensive threat detection.
-
 
 *Possible investigation steps*
 
 
-- Review the alert details to confirm the presence of the file "MPDW-constraints.js" in the specified critical paths: "?:\\*\\Windows\\system32\\DriVerStoRe\\FiLeRePoSiToRy\\*\\MPDW-constraints.js" or "?:\\*\\Windows\\WinSxS\\amd64_microsoft-windows-printing-printtopdf_*\\MPDW-constraints.js".
-- Check the file creation and modification timestamps to determine when the file was placed or altered in the system directories.
-- Investigate the source of the file by examining recent user activity and process execution logs around the time the file appeared, focusing on any suspicious or unauthorized actions.
-- Correlate the event with other data sources such as Sysmon, Microsoft Defender XDR, or SentinelOne to identify any related suspicious activities or processes that might indicate exploitation attempts.
-- Assess the risk and impact by determining if the affected system has any sensitive roles or access that could be leveraged by an attacker through privilege escalation.
-- If malicious activity is confirmed, initiate containment measures such as isolating the affected system and conducting a full malware scan to prevent further exploitation.
+- Does the alert show protected-path MPDW-constraints.js placement outside Windows servicing?
+  - Why: the rule proves a Print to PDF constraints-script write, not Print Spooler execution of the modified script.
+  - Focus: confirm `file.path` is DriverStore or Print to PDF WinSxS for MPDW-constraints.js, then read `process.executable`, `process.command_line`, `process.parent.executable`, and `process.parent.command_line`. !{investigate{"description":"","label":"File events for the same suspicious JavaScript path","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-2h","relativeTo":"now"}}
+  - Implication: escalate when the target is protected DriverStore or WinSxS and the writer is not Windows setup, repair, or print-component servicing; lower suspicion only when path, writer, parent, and surrounding servicing files match the same recognized OS or Print to PDF repair activity.
+- Does the writer process look like GooseEgg staging rather than servicing?
+  - Why: Microsoft observed GooseEgg launchers and batch scripts before Print Spooler redirection; writer identity and parentage separate servicing from exploit staging.
+  - Focus: recover the writer start event with `process.entity_id`; compare `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.parent.executable`, and `process.parent.command_line`.
+  - Implication: escalate when writer or parent is a batch/script host, user-writable or renamed binary, known GooseEgg launcher, or unsigned/unrecognized executable; lower suspicion when identity and lineage remain signed Windows servicing or recognized print-management tooling.
+- Did the same writer stage GooseEgg files or copied driver-store content?
+  - Why: published GooseEgg examples stage batch files, wayzgoose*.dll, and copied print-driver directories under version-like C:\ProgramData\<vendor>\v#.#.# paths.
+  - Focus: same `host.id` and `process.entity_id` file events: `file.path`, `file.name`, `file.Ext.original.path`, and `file.Ext.header_bytes` for staging, rename, or content clues. !{investigate{"description":"","label":"File events from the writer process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-2h","relativeTo":"now"}}
+  - Implication: escalate when those filenames, ProgramData version paths, copied driver-store directories, .save / .zip hive outputs, or rename chains appear around the writer; lower suspicion when the same-process file set is limited to recognized servicing content and no GooseEgg artifact family appears.
+- If registry telemetry is available, did the writer create GooseEgg protocol or CLSID redirection?
+  - Focus: same `host.id` and `process.entity_id` registry events, especially `registry.path`, `registry.value`, `registry.data.strings`, and `process.executable` for rogue protocol handler, CLSID, or wayzgoose*.dll paths. !{investigate{"description":"","label":"Registry events from the writer process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-2h","relativeTo":"now"}}
+  - Hint: missing registry telemetry is unresolved, not benign; continue with file, process, and spooler evidence.
+  - Implication: escalate when registry changes register the rogue protocol or CLSID or point Print Spooler resolution to actor-controlled ProgramData content; lower suspicion only when available registry data remains recognized print-component configuration and file/process evidence is also clean.
+- Did activation or spooler follow-on show SYSTEM-level execution?
+  - Focus: process starts after the write on `host.id`: `process.name`, `process.parent.name`, `process.parent.executable`, `process.command_line`, and `process.Ext.token.integrity_level_name` for scheduled-task launch, spoolsv.exe, PrintIsolationHost.exe, or SYSTEM command tests. !{investigate{"description":"","label":"Process events after the protected file write","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}}
+  - Hint: with library telemetry, check `dll.name` and `dll.path` for wayzgoose*.dll or loads from the written driver-store path; missing library telemetry is unresolved for load proof, not benign.
+  - Implication: escalate when the host shows scheduled-task activation as SYSTEM, spooler or print isolation child processes, a SYSTEM whoami test, or a wayzgoose*.dll load after the write; absence is no execution proof, not proof the write was benign.
+- Does the suspicious artifact set recur enough to change scope?
+  - Focus: after suspicious or unresolved local evidence, review recent alerts for `host.id`, then search `file.path`, suspicious `process.hash.sha256`, and GooseEgg filenames across hosts. !{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 containment and hunting when the same writer hash, ProgramData version path, wayzgoose*.dll, or protected MPDW-constraints.js placement appears on other hosts or pairs with spooler/privilege-escalation alerts; keep scope local when recurrence is absent and local evidence resolves to one recognized workflow.
+- Escalate when protected-path placement aligns with non-servicing lineage or any GooseEgg, registry, scheduled-task, or spooler corroborator; close only when path, writer, parent, file set, user/host scope, and recovery bind to one recognized servicing or print workflow; preserve artifacts and escalate when evidence is mixed, missing, or contradictory.
 
 
 *False positive analysis*
 
 
-- Legitimate software updates or installations may place JavaScript files in the monitored directories. Verify the source and integrity of the software to ensure it is from a trusted vendor.
-- System administrators or automated scripts might deploy or modify JavaScript files in these paths for legitimate configuration purposes. Review change management logs to confirm authorized activities.
-- Security tools or system maintenance processes could temporarily create or modify files in these directories. Cross-reference with scheduled tasks or security tool logs to validate these actions.
-- Exclude known benign applications or processes that frequently interact with the specified file paths by creating exceptions in the detection rule to reduce noise.
-- Regularly update the detection rule to incorporate new intelligence on false positives, ensuring it remains effective and relevant.
+- Windows servicing, Print to PDF repair, printer-driver packaging, image-build, or print-management workflows can touch these paths. Confirm `file.path`, writer, parent, signer, `host.id` cohort, surrounding file set, and spooler follow-on all bind to one such workflow, with no GooseEgg artifacts, rogue registry evidence, or spooler child-process anomalies. Change records, patch windows, build records, or management tickets can corroborate; if unavailable, close only when telemetry independently proves the bounded workflow.
+- Before creating an exception, validate a stable benign workflow across prior alerts: keep writer identity, `process.parent.executable`, `file.path`, `host.id` cohort, and bounded file set stable. Avoid exceptions on MPDW-constraints.js alone, DriverStore or WinSxS paths alone, or spoolsv.exe activity alone.
 
 
 *Response and remediation*
 
 
-- Isolate the affected system from the network immediately to prevent further exploitation or lateral movement by the adversary.
-- Terminate any suspicious processes related to the Windows Print Spooler service to halt ongoing exploitation attempts.
-- Remove unauthorized JavaScript files, specifically "MPDW-constraints.js", from the identified critical paths to eliminate the immediate threat.
-- Apply the latest security patches and updates from Microsoft to address CVE-2022-38028 and ensure the system is protected against known vulnerabilities.
-- Conduct a thorough review of user accounts and privileges on the affected system to identify and revoke any unauthorized privilege escalations.
-- Monitor the network and system logs for any signs of further exploitation attempts or related suspicious activities, using enhanced detection rules.
-- Report the incident to the appropriate internal security team or external authorities if required, providing detailed information about the exploitation attempt and actions taken.
+- If confirmed benign, reverse temporary containment and record the `file.path`, writer identity, parent lineage, `host.id` cohort, and servicing or print-management file pattern that justified closure. Create an exception only for that recurring workflow.
+- If suspicious but unconfirmed, preserve the written MPDW-constraints.js, its path and hash when available, the writer `process.entity_id`, `process.executable`, `process.command_line`, parent lineage, `user.id`, GooseEgg scripts or DLLs, ProgramData staging directories, scheduled-task evidence, and any registry or library corroboration before cleanup. Apply reversible containment first, such as pausing nonessential printing, limiting print-management access, isolating the host when business impact permits, or increasing monitoring. Avoid deleting files, stopping spoolsv.exe, or restoring registry state until the evidence is preserved.
+- If confirmed malicious, preserve the same file, process, registry, library, scheduled-task, and spooler evidence first, then isolate the host through endpoint response when available and proportionate to host criticality. If direct response is unavailable, escalate with the preserved `file.path`, writer lineage, staging directory, registry redirection, and spooler follow-on evidence to the team that can act. After scope is clear, remove the malicious JavaScript, GooseEgg scripts, wayzgoose*.dll, ProgramData staging directory, scheduled task, and rogue registry/protocol state; restore affected print configuration, close the staging mechanism, and rotate credentials only for accounts or hives exposed by collected evidence.
+- Post-incident hardening: apply the Microsoft security update for CVE-2022-38028, disable Print Spooler on systems that do not need it, restrict print-management rights, retain file/process coverage plus registry or library telemetry where it limited the investigation, and document the confirmed MPDW-constraints.js, ProgramData, wayzgoose, or scheduled-task pattern 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/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
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-installerfiletakeover.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-installerfiletakeover.asciidoc
index 69503e9ced..27211c95e8 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-installerfiletakeover.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-installerfiletakeover.asciidoc
@@ -33,7 +33,7 @@ Identifies a potential exploitation of InstallerTakeOver (CVE-2021-41379) defaul
 * Use Case: Vulnerability
 * Data Source: Elastic Defend
 
-*Version*: 115
+*Version*: 116
 
 *Rule authors*: 
 
@@ -53,64 +53,49 @@ Identifies a potential exploitation of InstallerTakeOver (CVE-2021-41379) defaul
 *Investigating Potential Privilege Escalation via InstallerFileTakeOver*
 
 
-InstallerFileTakeOver is a weaponized escalation of privilege proof of concept (EoP PoC) to the CVE-2021-41379 vulnerability. Upon successful exploitation, an unprivileged user will escalate privileges to SYSTEM/NT AUTHORITY.
-
-This rule detects the default execution of the PoC, which overwrites the `elevation_service.exe` DACL and copies itself to the location to escalate privileges. An attacker is able to still take over any file that is not in use (locked), which is outside the scope of this rule.
-
-> **Note**:
-> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
-
 
 *Possible investigation steps*
 
 
-- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
-- Investigate other alerts associated with the user/host during the past 48 hours.
-- Look for additional processes spawned by the process, command lines, and network communications.
-- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
-- Examine the host for derived artifacts that indicate suspicious activities:
-  - Analyze the file using a private sandboxed analysis system.
-  - Observe and collect information about the following activities in both the sandbox and the alert subject host:
-    - Attempts to contact external domains and addresses.
-      - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.
-      - Examine the DNS cache for suspicious or anomalous entries.
-        - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}}
-    - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
-    - Examine the host services for suspicious or anomalous entries.
-      - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}}
-      - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}}
-      - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}}
-  - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
-- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.
+- Which alert path fired: a suspect service binary or a service-spawned child?
+  - Focus: alert-local `process.name`, `process.executable`, `process.command_line`, `process.parent.executable`, and `process.Ext.token.integrity_level_name`.
+  - Implication: escalate when SYSTEM "elevation_service.exe" runs outside "%ProgramFiles% or %ProgramFiles(x86)%\Microsoft\Edge\Application\<version>\elevation_service.exe" or starts "cmd.exe", "powershell.exe", or "rundll32.exe"; lower suspicion only for a genuine Edge service start with no shell child.
+- Is the elevation service binary genuine Microsoft content?
+  - Focus: compare service `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`; for child alerts, recover the parent service start on `host.id` with `process.parent.entity_id` and compare those fields there.
+  - Hint: if a child alert lacks parent hash or signer details, recover the parent service process start with entity or PID fallback. !{investigate{"description":"","label":"Parent elevation service process start","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when original filename is not "elevation_service.exe", signer is not Microsoft, trust fails, or the same hash appears from a user-writable path; lower suspicion only when path, filename, signer, trust, and hash history fit the expected Microsoft Edge service.
+- Does lineage show Windows Installer takeover rather than normal Edge servicing?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.code_signature.subject_name`, `process.parent.code_signature.trusted`, and broader process lineage when needed.
+  - Implication: escalate when an MSI, temp, or user-session chain leads to the SYSTEM service or shell; lower suspicion when Microsoft-signed Edge installer or updater lineage starts the genuine service with servicing arguments and no shell.
+- Do recovered file events show service overwrite or PoC staging artifacts?
+  - Focus: if file telemetry exists, open host-scoped file events, then filter to the recovered service or child `process.entity_id`; if entity IDs are absent, use `host.id` plus service `process.pid` or `process.parent.pid` and the alert window. Review `file.path`, `file.Ext.original.path`, and writing `process.executable`. !{investigate{"description":"","label":"File events on this host near the alert","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Range: start 30 minutes before the alert because MSI administrative-install staging can precede service execution.
+  - Implication: escalate when the Edge service path is overwritten or PoC artifacts such as the "microsoft plz" temp folder, temp MSI, or "elevation_service.exe" file creation cluster around the alert; treat those names as corroborators, not required evidence. Missing file telemetry is unresolved, not benign.
+  - Hint: modified variants may omit PoC names; keep this centered on service replacement and MSI staging when names differ.
+- What did the SYSTEM service or spawned child do next?
+  - Focus: descendant process starts on the same `host.id` from `process.entity_id` or `process.parent.entity_id`, especially `process.name`, `process.command_line`, and `process.Ext.token.integrity_level_name`. !{investigate{"description":"","label":"Child process starts from the alert process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when SYSTEM context launches credential-access, persistence, payload staging, or remote-execution tooling; keep scope near the privilege-escalation event only when the service or shell produces no follow-on SYSTEM activity.
+- If local findings remain suspicious or unresolved, do related alerts show broader exploitation?
+  - Focus: related alerts for the same `host.id` in the last 48 hours, especially service tampering, suspicious MSI, credential access, or follow-on execution. !{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"}}
+  - Hint: compare `user.id` only when it identifies a non-SYSTEM actor; otherwise keep broadened review host-scoped and use lineage to avoid over-attributing the operator. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden response when the same host or user shows privilege-escalation or post-exploitation alerts; quiet related-alert review does not close unresolved local evidence.
+- Escalate on identity mismatch, MSI/user lineage, service overwrite, SYSTEM shell, or follow-on activity; close only when all evidence fits genuine Microsoft Edge service identity with no shell behavior or verified validation/detonation; preserve artifacts and escalate when evidence is mixed or telemetry is missing.
 
 
 *False positive analysis*
 
 
-- Verify whether a digital signature exists in the executable, and if it is valid.
-
-
-*Related rules*
-
-
-- Suspicious DLL Loaded for Persistence or Privilege Escalation - bfeaf89b-a2a7-48a3-817f-e41829dc61ee
+- Authorized exploit validation, red-team work, detection-content testing, malware research, or incident-response detonation can trigger this rule on lab or disposable analysis hosts. Confirm `process.hash.sha256`, service `process.executable`, parent `process.parent.executable`, child `process.command_line`, recovered temp-artifact pattern, and bounded `host.id` cohort match the same test kit or analysis-host cohort. If change, test, or sandbox records are unavailable, require the same telemetry pattern across prior alerts from this rule before closing as benign.
+- Before creating an exception, keep `process.hash.sha256`, `process.executable`, `process.parent.executable`, child `process.command_line`, `host.id`, and the recovered temp-artifact pattern stable across prior alerts from this rule. Avoid exceptions on `process.name`, `process.parent.name`, or "elevation_service.exe" alone because those values overlap real service abuse.
 
 
 *Response and remediation*
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Isolate the involved host to prevent further post-compromise behavior.
-- If the triage identified malware, search the environment for additional compromised hosts.
-  - Implement temporary network rules, procedures, and segmentation to contain the malware.
-  - Stop suspicious processes.
-  - Immediately block the identified indicators of compromise (IoCs).
-  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
-- Remove and block malicious artifacts identified during triage.
-- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
-- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
-- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+- If confirmed benign, reverse temporary containment and record the validation or analysis workflow that matched the alert, including the stable `process.hash.sha256`, service `process.executable`, parent `process.parent.executable`, child `process.command_line`, recovered artifact pattern, and bounded `host.id` cohort. Create an exception only after the same pattern recurs across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve the case export, process tree with service and child entity IDs, service binary and hash identity, spawned-shell command line, and recovered service-overwrite or temp-artifact timeline before containment or cleanup. Apply reversible containment first, such as heightened monitoring or host isolation when the asset role permits it; terminate the spawned shell only after capture, and escalate to isolation if follow-on SYSTEM activity or spread appears.
+- If confirmed malicious, use the preserved identity, lineage, artifact, and follow-on evidence to isolate the endpoint or escalate to the team that can contain it. Before replacing or deleting files, collect the overwritten service binary, temp MSI or recovered PoC artifacts, and spawned-shell timeline. Review related hosts and users for the same hash or service-path pattern, then restore the genuine Edge elevation service binary and remove only attacker payloads, persistence, or configuration changes identified during scoping.
+- Post-incident hardening: verify Windows Installer and Edge components are patched, restrict unnecessary MSI administrative-install paths where possible, retain process and file telemetry long enough to reconstruct service replacement, and record the service-path, temp-artifact, and child-shell pattern for future response.
 
 
 ==== Setup
@@ -120,11 +105,9 @@ This rule detects the default execution of the PoC, which overwrites the `elevat
 *Setup*
 
 
-If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
-events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
-Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
-`event.ingested` to @timestamp.
-For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
+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
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-suid-sgid.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-suid-sgid.asciidoc
new file mode 100644
index 0000000000..fc4b1ec830
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-suid-sgid.asciidoc
@@ -0,0 +1,114 @@
+[[potential-privilege-escalation-via-suid-sgid]]
+=== Potential Privilege Escalation via SUID/SGID
+
+Detects potential privilege escalation under the root effective user when the real user and parent user are not root, indicative of the execution of binaries with SUID or SGID bits set.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1548/
+
+*Tags*: 
+
+* Data Source: Elastic Defend
+* Domain: Endpoint
+* OS: Linux
+* 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 Potential Privilege Escalation via SUID/SGID*
+
+
+Adversaries exploit misconfigured SUID/SGID binaries to gain elevated access or persistence. This rule identifies processes running with root privileges but initiated by non-root users, flagging potential misuse of SUID/SGID permissions.
+
+
+*Possible investigation steps*
+
+
+- Inspect `process.parent.command_line` and working directory for obfuscation or one-liners.
+- Check authentication and sudoers policy for the user.
+- Pivot on the host for additional privilege escalation or persistence in the same session.
+
+
+*Response and remediation*
+
+
+- If unauthorized, contain the session, revoke elevated access, and review sudoers and polkit policy for tampering.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
+  (process.user.id == "0" and process.real_user.id != "0" and process.parent.user.id != "0") or
+  (process.group.id == "0" and process.real_group.id != "0" and process.parent.group.id != "0")
+) and
+(
+  startsWith(process.executable, process.command_line) or
+  startsWith(process.name, process.command_line)
+) and
+(
+  process.parent.name like (".*", "python*", "perl*", "ruby*", "lua*", "php*", "node", "deno", "bun", "java") or
+  process.parent.executable like ("./*", "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/user/*", "/var/run/user/*", "/home/*/*") or
+  (
+    process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh") and
+    process.parent.args in ("-c", "-cl", "-lc", "--command", "-ic", "-ci", "-bash", "-sh", "-zsh", "-dash", "-fish", "-ksh", "-mksh") and
+    process.parent.args_count <= 4
+  )
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Abuse Elevation Control Mechanism
+** ID: T1548
+** Reference URL: https://attack.mitre.org/techniques/T1548/
+* Sub-technique:
+** Name: Setuid and Setgid
+** ID: T1548.001
+** Reference URL: https://attack.mitre.org/techniques/T1548/001/
+* Sub-technique:
+** Name: Sudo and Sudo Caching
+** ID: T1548.003
+** Reference URL: https://attack.mitre.org/techniques/T1548/003/
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-unshare-and-uid-change.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-unshare-and-uid-change.asciidoc
new file mode 100644
index 0000000000..02f33c0212
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-unshare-and-uid-change.asciidoc
@@ -0,0 +1,154 @@
+[[potential-privilege-escalation-via-unshare-and-uid-change]]
+=== Potential Privilege Escalation via unshare and UID Change
+
+Identifies potentially suspicious use of unshare to create a user namespace context followed by a UID change event indicating a transition to root. Adversaries may use unshare-based primitives as part of local privilege escalation chains. This rule is intentionally generic and can surface multiple local privesc patterns beyond a single CVE.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.wiz.io/blog/ubuntu-overlayfs-vulnerability
+* https://twitter.com/liadeliyahu/status/1684841527959273472
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Privilege Escalation
+* Use Case: Vulnerability
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 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 Potential Privilege Escalation via unshare and UID Change*
+
+
+The unshare utility can create new namespaces, including user namespaces. In some exploit chains, an attacker uses
+unshare (often with user namespace flags) as a precursor step and then achieves a transition to root. This rule detects
+a short sequence where a non-root user executes unshare with user-namespace related arguments and a subsequent uid_change
+event indicates the user became root, which can represent a successful local privilege escalation attempt.
+
+
+*Possible investigation steps*
+
+
+- Review unshare arguments in the first event to confirm user namespace related flags were used (for example -U/--user or -r).
+- Check the process tree and parent context (process.parent.entity_id) to understand what launched unshare and whether it originated from an interactive session or user-writable path.
+- Confirm whether the uid_change corresponds to the same activity and identify the first root process spawned after the uid_change event.
+- Review other host signals around the same time for exploit activity such as compilation in /tmp, suspicious downloads, or execution of unusual binaries.
+
+
+*False positive analysis*
+
+
+- Legitimate sandboxing or container tooling may use unshare and then legitimately trigger uid_change events; validate the parent process and user context.
+- Security testing, exploit validation, or developer environments may intentionally exercise namespace-related behavior; tune by users, hosts, or maintenance windows.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected host to prevent further privilege abuse or lateral movement.
+- Terminate suspicious processes and collect forensic data (process tree, binaries, and relevant files in temp locations).
+- Patch and harden the host; review policies that allow unprivileged user namespaces if not required in your environment.
+- Escalate for incident response when root access is confirmed and scope for follow-on persistence.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from Elastic Defend.
+
+
+*Elastic Defend Integration Setup*
+
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+
+
+*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide].
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide].
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by process.parent.entity_id, host.id with maxspan=60s
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+    process.name == "unshare" and process.args : ("-r", "-rm", "m", "-U", "--user") and user.id != "0"]
+  [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and
+    user.id == "0"]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Exploitation for Privilege Escalation
+** ID: T1068
+** Reference URL: https://attack.mitre.org/techniques/T1068/
+* Technique:
+** Name: Abuse Elevation Control Mechanism
+** ID: T1548
+** Reference URL: https://attack.mitre.org/techniques/T1548/
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-unshare-followed-by-root-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-unshare-followed-by-root-process.asciidoc
new file mode 100644
index 0000000000..add8706295
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-unshare-followed-by-root-process.asciidoc
@@ -0,0 +1,146 @@
+[[potential-privilege-escalation-via-unshare-followed-by-root-process]]
+=== Potential Privilege Escalation via unshare Followed by Root Process
+
+Detects a short sequence where a non-root user performs unshare-related namespace activity (often associated with user namespace privilege escalation primitives) and then a root process is executed shortly after. This can indicate a successful local privilege escalation attempt or suspicious namespace manipulation captured in Auditd Manager telemetry.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* auditbeat-*
+* logs-auditd_manager.auditd-*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.elastic.co/integrations/auditd_manager
+* https://attack.mitre.org/techniques/T1068/
+
+*Tags*: 
+
+* Data Source: Auditd Manager
+* Domain: Endpoint
+* OS: Linux
+* 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 Potential Privilege Escalation via unshare Followed by Root Process*
+
+
+Validate that the initiating user and parent process should be using unshare. Then confirm whether the subsequent root
+process aligns with an approved administrative workflow or represents an unexpected transition to root.
+
+
+*Possible investigation steps*
+
+
+- Review auditd.data.* (syscall, class, and a0) and process args to understand the unshare intent.
+- Identify the first root process spawned and its command line, then look for follow-on persistence or credential access.
+- Correlate with recent downloads/compilation in temp directories and other local privesc indicators on the host.
+
+
+*Response and remediation*
+
+
+- If unauthorized, isolate the host, capture forensic artifacts, and patch/harden user namespace settings as appropriate.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule relies on Auditd Manager (or Auditbeat) process telemetry that captures:
+
+- Process execution events (execve/execveat) to populate process.name, process.args, and process.parent.pid
+- Namespace-related activity to populate auditd.data.syscall, auditd.data.class, and auditd.data.a0 for unshare calls
+- Privilege transitions so processes started as root can be correlated after the namespace action
+
+Ensure your auditd ruleset includes coverage for unshare and exec-related syscalls and that arguments are collected. If
+your environment does not populate auditd.data.class/a0 for unshare, keep the process-based fallback branch (process.name
+== unshare with -U/--user/-r args) enabled and consider extending auditing to enrich those auditd.data fields.
+
+
+*Example auditd rules*
+
+
+The following example syscall rules are commonly used to capture the signals required by this detection. Adjust keys and
+scope to your environment (these examples are intentionally broad).
+
+- Capture unshare (namespace activity):
+  -a always,exit -F arch=b64 -S unshare -k namespace
+  -a always,exit -F arch=b32 -S unshare -k namespace
+
+- Capture process execution (argv collection depends on your auditd/auditbeat pipeline configuration):
+  -a always,exit -F arch=b64 -S execve -S execveat -k exec
+  -a always,exit -F arch=b32 -S execve -S execveat -k exec
+
+- Capture UID transition syscalls often associated with privilege changes:
+  -a always,exit -F arch=b64 -S setuid -S setreuid -S setresuid -S setfsuid -k uid_change
+  -a always,exit -F arch=b32 -S setuid -S setreuid -S setresuid -S setfsuid -k uid_change
+
+See https://docs.elastic.co/integrations/auditd_manager
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by host.id, process.parent.pid with maxspan=30s
+ [process where host.os.type == "linux" and 
+  (
+   (auditd.data.syscall == "unshare" and auditd.data.class == "namespace" and auditd.data.a0 in ("10000000", "50000000", "70000000", "10020000", "50020000", "70020000")) or 
+
+   (process.name == "unshare" and  
+    (process.args in ("--user", "--map-root-user", "--map-current-user") or process.args like ("-*U*", "-*r*")))
+   ) and user.id != "0" and user.id != null]
+ [process where host.os.type == "linux" and 
+  user.id == "0" and user.id != null and 
+  (
+   process.name in ("su", "sudo", "pkexec", "passwd", "chsh", "newgrp", "doas", "run0", "sg", "dash", "sh", "bash", "zsh", "fish", 
+                    "ksh", "csh", "tcsh", "ash", "mksh", "busybox", "rbash", "rzsh", "rksh", "tmux", "screen", "node") or 
+   process.name like ("python*", "perl*", "ruby*", "php*", "lua*")
+  )]
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privileged-escalation-via-samaccountname-spoofing.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privileged-escalation-via-samaccountname-spoofing.asciidoc
index 6b34505334..fabe71ab3e 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-privileged-escalation-via-samaccountname-spoofing.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-privileged-escalation-via-samaccountname-spoofing.asciidoc
@@ -34,7 +34,6 @@ Identifies a suspicious computer account name rename event, which may indicate a
 * Domain: Endpoint
 * OS: Windows
 * Use Case: Threat Detection
-* Tactic: Persistence
 * Tactic: Privilege Escalation
 * Use Case: Active Directory Monitoring
 * Data Source: Active Directory
@@ -42,7 +41,7 @@ Identifies a suspicious computer account name rename event, which may indicate a
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 215
+*Version*: 216
 
 *Rule authors*: 
 
@@ -58,46 +57,71 @@ Identifies a suspicious computer account name rename event, which may indicate a
 *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 Privileged Escalation via SamAccountName Spoofing*
 
 
-In Active Directory environments, the samAccountName attribute is crucial for identifying user and computer accounts. Adversaries may exploit vulnerabilities like CVE-2021-42278 to spoof this attribute, potentially elevating privileges by renaming computer accounts to mimic domain controllers. The detection rule identifies suspicious renaming events, where a machine account is altered to resemble a user account, signaling possible privilege escalation attempts.
-
 
 *Possible investigation steps*
 
 
-- Review the event logs to confirm the occurrence of a "renamed-user-account" action, focusing on entries where the OldTargetUserName ends with a "$" and the NewTargetUserName does not, indicating a potential spoofing attempt.
-- Identify the source of the rename event by examining the event logs for the user or system that initiated the change, and determine if it aligns with expected administrative activity.
-- Check the history of the NewTargetUserName to see if it has been used in any recent authentication attempts or privileged operations, which could indicate malicious intent.
-- Investigate the associated IP address and hostname from which the rename action was performed to determine if it is a known and trusted source within the network.
-- Correlate the event with other security alerts or logs to identify any patterns or additional suspicious activities that might suggest a broader attack campaign.
-- Assess the potential impact by determining if the renamed account has been granted elevated privileges or access to sensitive resources since the rename event occurred.
+- What computer-account rename did the alert capture?
+  - Focus: `winlog.event_data.OldTargetUserName`, `winlog.event_data.NewTargetUserName`, `winlog.event_data.TargetSid`, `winlog.event_data.TargetDomainName`, and `winlog.computer_name`.
+  - Implication: escalate when one `winlog.event_data.TargetSid` moves from a "$"-suffixed computer name to a name matching or imitating the logging controller or another controller-style identity; lower concern only when the object, names, domain, and controller match a lab or patch-validation object.
+
+- Which account and session initiated the rename?
+  - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, `winlog.event_data.SubjectLogonId`, and `user.id`.
+  - Hint: modifying-session authentication events. !{investigate{"description":"","label":"Authentication events for the modifying session","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate when the modifier is a standard user, non-tier-0 administrator, unexpected service account, or session unrelated to directory management; lower concern only when the SID, account, domain, and logon session match the same recognized test or repair workflow.
+
+- Was the same object restored or prepared with surrounding directory changes?
+  - Why: rename-back on the same object after ticket activity is common noPac-style tradecraft.
+  - Focus: follow-on account-management or directory-change events for `winlog.event_data.TargetSid`, `winlog.event_data.OldTargetUserName`, `winlog.event_data.NewTargetUserName`, `winlog.event_data.AttributeLDAPDisplayName`, and `winlog.event_data.AttributeValue`.
+  - Hint: look for sAMAccountName rewrites, authentication-related attribute changes, and a final return to the expected "$"-suffixed name.
+  - Implication: escalate when the object is restored after suspicious ticket activity, renamed repeatedly, or has authentication-related attribute changes around the rename; lower concern only when the restore is prompt, complete, and tied to the same recognized test or repair workflow.
+
+- Did the spoofed identity request Kerberos tickets or log on after the rename?
+  - Focus: Windows Security authentication events for the spoofed name, especially `winlog.event_data.TargetUserName`, `event.code`, `winlog.event_data.AuthenticationPackageName`, `source.ip`, and `winlog.computer_name`.
+  - Hint: use the alert `@timestamp`, `winlog.computer_name`, and `winlog.event_data.NewTargetUserName` to scope authentication review. !{investigate{"description":"","label":"Authentication events for the spoofed name","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4768","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetUserName","queryType":"phrase","value":"{{winlog.event_data.NewTargetUserName}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4769","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetUserName","queryType":"phrase","value":"{{winlog.event_data.NewTargetUserName}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetUserName","queryType":"phrase","value":"{{winlog.event_data.NewTargetUserName}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} Missing Kerberos or logon coverage is unresolved, not benign.
+  - Implication: escalate when the new name requests Kerberos tickets, authenticates from an unexpected `source.ip`, or appears in privileged access flows; lack of follow-on use lowers concern only when rename and restore evidence fit one confirmed benign workflow.
+
+- If local evidence is suspicious or unresolved, does the same modifier or object appear in related directory abuse?
+  - Focus: related Windows Security events or alerts for the same `winlog.event_data.SubjectUserSid` and `winlog.event_data.TargetSid`, especially Active Directory manipulation, Kerberos abuse, credential access, or privilege-escalation activity.
+  - Hint: modifier-SID related events. !{investigate{"description":"","label":"Events associated with the modifying account","providers":[[{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: renamed-object related events. !{investigate{"description":"","label":"Events associated with the renamed object","providers":[[{"excluded":false,"field":"winlog.event_data.TargetSid","queryType":"phrase","value":"{{winlog.event_data.TargetSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when either SID appears in related directory or privilege-abuse activity; keep localized only when related scope is clean and local evidence supports a confirmed benign workflow.
+
+- Escalate for unauthorized privileged-name spoofing, ticket use, suspicious modifier/session origin, same-object restore, directory-change setup, or related abuse; close only when all evidence binds the rename to one confirmed test or repair workflow with no contradictory Kerberos, directory-change, or related findings; preserve rename and authentication evidence and escalate when visibility is incomplete or findings conflict.
 
 
 *False positive analysis*
 
 
-- Routine administrative tasks involving legitimate renaming of computer accounts can trigger false positives. To manage this, create exceptions for known administrative activities by excluding specific administrator accounts or service accounts from the detection rule.
-- Automated processes or scripts that rename computer accounts as part of regular maintenance or deployment procedures may also cause false alerts. Identify these processes and exclude their associated accounts or event patterns from the rule.
-- Temporary renaming of computer accounts for troubleshooting or testing purposes can be mistaken for suspicious activity. Document and exclude these temporary changes by maintaining a list of authorized personnel and their activities.
-- Changes made by trusted third-party software or management tools that interact with Active Directory should be reviewed and, if deemed safe, excluded from triggering alerts by specifying the tool's account or signature in the rule exceptions.
+- Controlled CVE-2021-42278 testing, patch validation, and rare tier-0 directory repair are the realistic benign paths. Confirm that `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectLogonId`, `winlog.event_data.TargetSid`, old/new names, and `winlog.computer_name` match one test or repair path; the same `winlog.event_data.TargetSid` is restored to the expected "$"-suffixed name; and Kerberos/logon events show no spoofed-name use outside that path. Without workflow records or owner confirmation, keep unresolved rather than closing on telemetry shape alone. If the target name, modifier, restore behavior, or follow-on usage drifts, do not close as benign.
+- Before creating an exception, validate that the same subject SID, target SID, old/new names, controller, restore sequence, and no-spoofed-authentication pattern recur across prior alerts from this rule after a benign workflow has been confirmed. Build the exception from that minimum workflow pattern, not `event.action`, `winlog.event_data.NewTargetUserName`, or `winlog.event_data.TargetSid` alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected machine from the network to prevent further unauthorized access or lateral movement within the domain.
-- Revert any unauthorized changes to the samAccountName attribute by renaming the affected computer account back to its original name.
-- Conduct a thorough review of recent changes in Active Directory, focusing on user and computer account modifications, to identify any other potentially compromised accounts.
-- Reset passwords for the affected machine account and any other accounts that may have been accessed or modified during the incident.
-- Apply the latest security patches and updates to all domain controllers and critical systems to mitigate vulnerabilities like CVE-2021-42278.
-- Enhance monitoring and logging for Active Directory events, specifically focusing on account renaming activities, to detect similar threats in the future.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken.
+- If confirmed benign, preserve the evidence set that proved the workflow, then reverse any temporary containment and document the exact subject SID, target SID, old/new name sequence, controller, restore sequence, and follow-on authentication pattern. Create an exception only after the same workflow pattern recurs across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve the alert document, Windows Security rename event, related account-management and directory-change events, Kerberos/logon events for the spoofed name, and related pivots before altering the object. Apply reversible containment only after weighing AD service impact with AD owners, such as temporarily disabling the renamed computer account or restoring the original sAMAccountName after evidence capture.
+- If confirmed malicious, preserve the same rename, controller, directory-change, Kerberos, and source-origin evidence first, then disable the renamed computer object or restore its original sAMAccountName, reset the machine-account secret or re-establish the expected trust path, and contain the modifying account and suspected source host. Escalate to broader account or host containment when ticket use, rename-back staging, or related privilege abuse shows active exploitation.
+- Before destructive cleanup or final object restoration, review the same `winlog.event_data.SubjectUserSid` and `winlog.event_data.TargetSid` across domain-controller Security logs for additional renames, spoofed-name authentication, or related directory abuse so scope is known before evidence changes.
+- If the spoofed identity obtained privileged tickets or was used for directory replication, treat the case as potential domain compromise: review issued Kerberos tickets, reset exposed accounts according to ticket and access evidence, and coordinate domain-recovery actions such as krbtgt rotation only when ticket abuse or replication access is confirmed.
+- Post-incident hardening: patch domain controllers for CVE-2021-42278 and related Kerberos fixes, retain account-management, directory-change, and Kerberos auditing on controllers, and record the final subject SID / target SID / old-new name / restore / follow-on-authentication pattern for future triage.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Audit User Account Management must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-user-account-management
+
 
 ==== Rule query
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-ransomware-note-file-dropped-via-smb.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-ransomware-note-file-dropped-via-smb.asciidoc
index 1c73e3f5e2..4fb652ec8a 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-ransomware-note-file-dropped-via-smb.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-ransomware-note-file-dropped-via-smb.asciidoc
@@ -31,7 +31,7 @@ Identifies an incoming SMB connection followed by the creation of a file with a
 * Resources: Investigation Guide
 * Data Source: Elastic Defend
 
-*Version*: 7
+*Version*: 8
 
 *Rule authors*: 
 
@@ -48,49 +48,71 @@ Identifies an incoming SMB connection followed by the creation of a file with a
 
 
 
-*Performance*
+*Investigating Potential Ransomware Note File Dropped via SMB*
 
 
-- This rule may cause medium to high performance impact due to logic scoping all icoming SMB network events.
-
 
 *Possible investigation steps*
 
 
-- Investigate the source.ip address connecting to port 445 on this host.
-- Identify the user account that performed the file creation via SMB.
-- If the number of files is too high and source.ip connecting over SMB is unusual isolate the host and block the used credentials.
-- Investigate other alerts associated with the user/host during the past 48 hours.
+- What do the sequence member events show about the accepted SMB session and note-file burst?
+  - Why: this sequence can omit stage-specific values from the combined alert; disposition depends on recovered source events.
+  - Focus: Timeline member events: network-stage `source.ip`, then file-stage `user.id`, `file.path`, `file.name`, and `file.extension`.
+  - Implication: escalate when one remote source is followed within one second by repeated note-like creations under user-profile paths; lower concern only when recovered source, identity, names, and paths form one bounded, neutral file-copy pattern for validation.
+  - Hint: `process.pid` value "4" is target-side kernel SMB I/O, not the remote executable; use `user.name` only as a readable label for the file-stage identity.
 
+- Do recovered `source.ip` and writing identity match a stable SMB pattern for this host?
+  - Why: the target-side kernel process does not identify the remote operator; source and SMB identity carry attribution value.
+  - Focus: surrounding and historical SMB "connection_accepted" events for `host.id` and recovered `source.ip`, plus file-stage `user.id` and `user.name`. !{investigate{"description":"","label":"SMB connection events on the host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"event.action","queryType":"phrase","value":"connection_accepted","valueType":"string"},{"excluded":false,"field":"destination.port","queryType":"phrase","value":"445","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the source is new for this host, appears only in a short burst, or pairs with an unusual SMB identity; lower concern when the same source and identity recur as one bounded backup, migration, or maintenance pattern. Missing SMB history is unresolved, not benign.
 
-*False positive analysis*
+- Do created files indicate broad ransom-note staging rather than routine instructions?
+  - Focus: recovered `file.path`, `file.name`, `file.extension`, `file.size`, and `file.Ext.header_bytes`; repeated names across multiple "C:\Users\" profile paths.
+  - Implication: escalate when identical or near-identical note files land in multiple profiles, use ".hta" or HTML variants, or are small text/HTML artifacts meant for user visibility; lower concern when files stay in one bounded application or migration folder and match stable instruction-file naming for the same source.
 
+- Does same-window SMB file activity show broader destructive or staging behavior?
+  - Why: note drops often accompany remote rename, delete, or other drop activity that this rule does not capture directly.
+  - Focus: file events in the same SMB window: `event.action`, `file.path`, `file.extension`, `file.Ext.original.path`, and `file.Ext.original.extension`. !{investigate{"description":"","label":"File events for SMB server writes on this host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the same window shows mass rename, delete, extension-change, or extra drop behavior in user or shared paths; lower concern when activity stays limited to the small note set with no follow-on churn.
 
-- Remote file creation with similar file naming convention via SMB.
+- If local SMB evidence remains suspicious or unresolved, does impact context stay local or show source fan-out?
+  - Why: ransomware may place notes apart from encryption or recovery inhibition, and SMB ransomware can fan out with valid accounts or admin shares.
+  - Focus: same-host impact alerts over 48 hours, then other SMB events keyed by recovered `source.ip` with matching note-like `file.name`, `file.path`, or impact `event.action`. !{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: escalate when the host shows rename, shadow-copy, backup-tamper, or destructive alerts, or when one source fans out to multiple hosts with matching note-drop or impact signals; keep the case local only when the source is confined to one bounded file-copy pattern. Missing cross-host SMB telemetry is unresolved, not benign.
+  - Hint: start with `source.ip` plus `destination.port` 445, then join returned hosts to note-like file creations by time.
 
+- What disposition do the recovered SMB source, identity, note pattern, file churn, and scope support?
+  - Escalate for remote note staging plus unexpected SMB identity, destructive file activity, recovery inhibition, or multi-host spread; close only for one stable bounded file-copy pattern with neutral names and no contradictory impact evidence; if purpose still depends on records, preserve artifacts until telemetry resolves it.
 
 
-*Related rules*
+*False positive analysis*
 
 
-- Third-party Backup Files Deleted via Unexpected Process - 11ea6bec-ebde-4d71-a8e9-784948f8e3e9
-- Volume Shadow Copy Deleted or Resized via VssAdmin - b5ea4bfe-a1b2-421f-9d47-22a75a6f2921
-- Volume Shadow Copy Deletion via PowerShell - d99a037b-c8e2-47a5-97b9-170d076827c4
-- Volume Shadow Copy Deletion via WMIC - dc9c1f74-dac3-48e3-b47f-eb79db358f57
-- Suspicious File Renamed via SMB - 78e9b5d5-7c07-40a7-a591-3dbbf464c386
+- Bulk backup, migration, or endpoint-management jobs can place repeated text or HTML instruction files over SMB. Confirm the same recovered `source.ip`, `user.id`, `user.name`, neutral `file.name` family, and bounded `file.path` recurs for this `host.id` without rename, delete, shadow-copy, backup-tamper, or cross-host note-drop spread. Change records can corroborate, not replace, telemetry alignment.
+- Case-driven incident response, legal-hold, or notification activity can write readme-style files remotely. Confirm recovered `source.ip`, `user.id`, `user.name`, `file.path`, and `file.extension` stay bounded to intended case or communication folders, use neutral notice/readme naming rather than decrypt, recover, lock, or payment language, and do not coincide with broader rename or delete activity from `process.pid` value "4". If case records are unavailable, require recurrence of the same source, identity, and path family without spread.
+- Before creating an exception, validate recurrence across prior alerts from this rule. Build the exception from the minimum pattern: recovered `source.ip`, `user.id` or `user.name`, representative `file.name`, bounded `file.path` family, and affected host cohort. Avoid exceptions on `file.name`, `host.id`, or `process.pid` alone.
 
 
 *Response and remediation*
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Consider isolating the involved host to prevent destructive behavior, which is commonly associated with this activity.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
-- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities.
-- If any backups were affected:
-  - Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.).
-- 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).
+- If confirmed benign, reverse temporary containment and record the confirmed `source.ip`, `user.id` or `user.name`, representative `file.name`, and bounded `file.path` pattern. Create an exception only after that same pattern recurs consistently across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve the alert, Timeline member-event export, copies or hashes of representative note files, recovered source and user identifiers, surrounding file-action evidence, and same-host alert identifiers before containment. Apply reversible containment first, such as temporarily blocking SMB from the recovered source to the target or restricting the recovered user for SMB access. Use host isolation only if note drops continue, spread to additional hosts, or the target role can tolerate interruption.
+- If confirmed malicious, isolate the recovered source host when it is managed and the source, SMB identity, note-file pattern, and impact evidence confirm active ransomware behavior. If direct endpoint response is unavailable on the source, hand off the preserved artifacts to the team that can block the SMB path or contain the source system. Before deleting files, terminating processes, or restoring data, export the member events, related impact alerts, note files, and affected host list.
+- After confirmed malicious scoping identifies affected hosts and accounts, rotate or reset the SMB credentials that were used or exposed, review other hosts touched by the same recovered `source.ip`, then remove dropped notes and restore affected data from known-good backups.
+- Post-incident hardening: restrict unnecessary SMB administrative access, protect backup and shadow-copy workflows, retain endpoint network and file telemetry needed to reconstruct remote file activity, and record the confirmed benign workflow or malicious source-and-path pattern for future cases.
+
+
+==== 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
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-remote-desktop-shadowing-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-remote-desktop-shadowing-activity.asciidoc
index 5e433cb1bb..989eaed199 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-remote-desktop-shadowing-activity.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-remote-desktop-shadowing-activity.asciidoc
@@ -43,7 +43,7 @@ Identifies the modification of the Remote Desktop Protocol (RDP) Shadow registry
 * Data Source: SentinelOne
 * Resources: Investigation Guide
 
-*Version*: 315
+*Version*: 316
 
 *Rule authors*: 
 
@@ -59,46 +59,85 @@ Identifies the modification of the Remote Desktop Protocol (RDP) Shadow registry
 *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 Remote Desktop Shadowing Activity*
 
 
-Remote Desktop Shadowing allows administrators to view or control active RDP sessions, aiding in support and troubleshooting. However, adversaries can exploit this feature to monitor or hijack user sessions without consent. The detection rule identifies suspicious modifications to RDP Shadow registry settings and the execution of specific processes linked to shadowing, signaling potential misuse.
-
 
 *Possible investigation steps*
 
 
-- Review the registry event details to confirm if there was a modification to the RDP Shadow registry path, specifically checking for changes in "HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Shadow".
-- Investigate the process events to identify if "RdpSaUacHelper.exe" or "RdpSaProxy.exe" were started by "svchost.exe", which could indicate unauthorized shadowing activity.
-- Check for any instances of "mstsc.exe" being executed with the "/shadow:*" argument, as this could signify an attempt to shadow an RDP session.
-- Correlate the identified processes and registry changes with user activity logs to determine if the actions were authorized or expected as part of legitimate administrative tasks.
-- Analyze network logs for any unusual remote connections or lateral movement patterns that coincide with the timing of the detected shadowing activity.
-- Consult endpoint security solutions like Microsoft Defender XDR or SentinelOne for additional context or alerts related to the same host or user account involved in the shadowing activity.
+- Which RDP shadowing path fired?
+  - Focus: `event.category`, `process.name`, `process.command_line`, `registry.path`, `registry.data.strings`.
+  - Implication: escalate faster for active "mstsc.exe /shadow" use or a `Shadow` policy value that removes consent; lower suspicion only when alert-local evidence matches recognized helpdesk, training, or policy-setting activity with consent retained.
+- Do process identity and lineage fit RDP shadowing components?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.command_line`.
+  - Hint: for registry alerts, recover same-process starts for lineage or command-line detail. !{investigate{"description":"","label":"Process events for the same process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when "mstsc.exe", "RdpSaUacHelper.exe", or "RdpSaProxy.exe" runs from a user-writable path, has an unexpected signer, or has a parent inconsistent with Remote Desktop Services or a support launcher. A trusted Microsoft binary confirms identity, not authorization.
+- If the `Shadow` registry value fired, did the new setting remove consent or allow control?
+  - Focus: `registry.path`, `registry.data.strings` (decimal or hex: `1`/`0x00000001` = full control with consent, `2`/`0x00000002` = full control without consent, `3`/`0x00000003` = view only with consent, `4`/`0x00000004` = view only without consent), and `process.executable`.
+  - Implication: escalate when `registry.data.strings` is `2`/`0x00000002` (full control, no consent) or `4`/`0x00000004` (view, no consent) because these allow silent shadowing; treat `1`/`0x00000001` or `3`/`0x00000003` as weaker setup evidence because the user is prompted, unless active shadowing or unexplained lineage appears.
+- If a process event fired, does it show active session shadowing?
+  - Focus: `process.name`, `process.command_line`, `process.parent.name`, `process.parent.executable`.
+  - Hint: if `process.command_line` is truncated or normalized, verify "/shadow", "/control", and "/noConsentPrompt" boundaries with `process.args` before lowering suspicion.
+  - Implication: escalate when "mstsc.exe" includes "/shadow" with "/control" or "/noConsentPrompt". Treat "RdpSaUacHelper.exe" or "RdpSaProxy.exe" under a service host as active target-side shadowing that escalates when paired with no-consent/control, unexplained lineage, or unrecognized user-host context; a plain "mstsc.exe" launch without shadowing arguments is not enough.
+- Does user, host, and session context fit recognized support or training?
+  - Focus: `user.id`, `user.name`, `user.domain`, `host.id`, `process.Ext.session_info.logon_type`.
+  - Implication: escalate when `user.id` targets an unusual workstation, privileged session, or host with no matching shadow-support pattern; lower suspicion only when user-host pairing, session type, and branch evidence match the same recognized workflow.
+- Did the same actor prepare, persist, or extend the host-side shadowing activity?
+  - Focus: `user.id`, `process.entity_id`, `process.command_line`, `registry.path`, `registry.data.strings`.
+  - Hint: start with recovered same-process events; expand to same-host process and registry events only when local capability or context remains suspicious. !{investigate{"description":"","label":"Registry events on the host near the alert","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the same user or lineage enumerates sessions, prepares alternate-token launch, changes Terminal Services or RDP state, launches admin tooling, or persists shadow settings; absent process or registry evidence narrows the case but does not clear the alert.
+- If local findings stay suspicious or unresolved, do related alerts expand scope?
+  - Focus: related alerts for the same `user.id` and `host.id`, especially remote-access, credential, remote-service, and persistence alerts.
+  - Hint: review same-user alerts when local branch and capability questions remain suspicious. !{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: review same-host alerts when host preparation or follow-on activity remains unresolved. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when related alerts show the same user or host in remote-access, credential, or persistence activity; keep scope narrow only when local evidence fits a recognized workflow and related alerts do not contradict it.
+
+- Using branch, capability, identity, lineage, user-host fit, host-side activity, and related alerts, escalate unauthorized no-consent/control shadowing or stealthy policy relaxation; close only when evidence binds to one recognized support, training, or policy workflow with no contradictions; if mixed or incomplete, preserve process and registry artifacts and escalate.
 
 
 *False positive analysis*
 
 
-- Legitimate administrative activities may trigger alerts when IT staff use RDP Shadowing for support. To manage this, create exceptions for known IT administrator accounts or specific IP addresses.
-- Scheduled maintenance or automated scripts that modify RDP Shadow registry settings can be mistaken for malicious activity. Identify and exclude these processes or scripts from the detection rule.
-- Security software or monitoring tools that interact with RDP sessions might mimic shadowing behavior. Verify these tools and whitelist their processes to prevent false alerts.
-- Training sessions or remote support tools that use RDP Shadowing features can generate alerts. Document and exclude these activities by identifying their unique process names or arguments.
+- Helpdesk support, training labs, and supervised administration can legitimately use "mstsc.exe /shadow" or target-side "RdpSa*" helpers. Confirm `process.command_line`, `process.name`, `process.parent.name`, `user.id`, `host.id`, and any `Shadow` value align with the same authorized workflow, without contradictory `process.command_line` or `registry.path` evidence. Without ticketing or support rosters, require telemetry-only recurrence of the same command pattern, user-host pairing, consent mode, and quiet follow-on profile before closing as benign.
+- Group Policy or endpoint management tooling can legitimately change `Shadow`. Confirm stable `process.executable`, `process.code_signature.subject_name`, `process.parent.command_line`, exact `registry.path`, and resulting `registry.data.strings` match the host class. Without change records or GPO inventories, require quiet recurrence of the same process and registry pattern for the same management scope before closing.
+- Before creating an exception, anchor it on the minimum confirmed workflow: `event.category`, exact `process.command_line` or `registry.path`, `registry.data.strings`, `user.id`, and `host.id`. Avoid exceptions on `process.name`, `registry.value`, or `Shadow` alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Terminate any suspicious processes identified in the alert, such as RdpSaUacHelper.exe, RdpSaProxy.exe, or mstsc.exe with shadowing arguments, to stop potential session hijacking.
-- Revert any unauthorized changes to the RDP Shadow registry settings to their default or secure state to prevent further exploitation.
-- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized changes have been made, and reset passwords for any compromised accounts.
-- 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 RDP activities across the network to detect and respond to similar threats more quickly in the future.
-- Review and update RDP access policies and configurations to ensure they align with best practices, such as enforcing multi-factor authentication and limiting RDP access to only necessary users and systems.
+- If confirmed benign, reverse temporary containment and document the exact `event.category`, `process.command_line` or `registry.path`, `registry.data.strings`, `user.id`, and `host.id` that proved the support, training, or policy workflow. Create an exception only after the same narrow pattern recurs.
+- If suspicious but unconfirmed, preserve a case export with the process tree, `process.entity_id`, `process.command_line`, `process.parent.command_line`, `registry.path`, `registry.value`, `registry.data.strings`, affected `user.id`, affected `host.id`, and surrounding preparation or follow-on evidence before changing host state.
+- Apply reversible containment next: restore the `Shadow` policy to the pre-change value, disable shadowing with `0`, require consent with `1` or `3`, or restrict the involved account on the affected `host.id`. Escalate to host isolation only when shadowing is part of broader session abuse and the host role can tolerate isolation.
+- If confirmed malicious, isolate the host when feasible, then terminate active "mstsc.exe" or "RdpSa*" shadowing processes after recording their process identifiers and command lines. Revert unauthorized `Shadow` and related Terminal Services or RDP shadow permission changes after preservation.
+- Scope other hosts and users tied to the same `user.id`, `process.command_line`, `registry.path`, or `registry.data.strings` before removing artifacts or resetting access.
+- Remove malicious helper scripts or tooling found during scoping, revert unauthorized RDP service or policy changes, and reset credentials that may have been exposed in the shadowed session.
+- Post-incident hardening: keep `Shadow` at the least permissive accepted setting, restrict who can shadow sessions, review RDP-Tcp shadow permissions, and retain process and registry telemetry needed to distinguish support use from no-consent shadowing.
+
+==== 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/sysmon-event-reg-setup[Sysmon Registry Events]
+
 
 ==== Rule query
 
@@ -119,8 +158,10 @@ any where host.os.type == "windows" and
 
   ) or
   (event.category == "process" and event.type == "start" and
-     (process.name : ("RdpSaUacHelper.exe", "RdpSaProxy.exe") and process.parent.name : "svchost.exe") or
-     (?process.pe.original_file_name : "mstsc.exe" and process.args : "/shadow:*")
+    (
+      (process.name : ("RdpSaUacHelper.exe", "RdpSaProxy.exe") and process.parent.name : "svchost.exe") or
+      (?process.pe.original_file_name : "mstsc.exe" and process.args : "/shadow:*")
+    )
   )
 )
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-java.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-java.asciidoc
index ca0fd67768..8c6032907c 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-java.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-java.asciidoc
@@ -33,7 +33,7 @@ This detection rule identifies the execution of a Linux shell process from a Jav
 * Data Source: Elastic Defend
 * Resources: Investigation Guide
 
-*Version*: 13
+*Version*: 14
 
 *Rule authors*: 
 
@@ -148,7 +148,7 @@ sequence by host.id with maxspan=5s
    and not (
      process.parent.args in (
        "/usr/lib/jenkins/jenkins.war", "/etc/remote-iot/services/remoteiot.jar", "/opt/pentaho/data-integration/launcher/launcher.jar",
-       "/usr/share/java/jenkins.war", "/opt//tomcat/statistics/statistics.jar", "/usr/lib64/NetExtender.jar",
+       "/usr/share/java/jenkins.war", "/opt/tomcat/statistics/statistics.jar", "/usr/lib64/NetExtender.jar",
        "/var/lib/jenkins/workspace/MP-QA/tc_certified_copy*/tc_certified_copy_web_ui_test/target/surefire/surefirebooter*.jar",
        "-javaagent:/opt/opentelemetry/opentelemetry-javaagent-all.jar", "./lib/pipeline-job-executor*SNAPSHOT.jar",
        "./lib/worker-launcher-agent*SNAPSHOT.jar", "/opt/Seqrite_EndPoint_Security/wildfly/jboss-modules.jar",
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-sharprdp-behavior.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-sharprdp-behavior.asciidoc
index 5b7ce7fcdd..67c4dd93e2 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-sharprdp-behavior.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-sharprdp-behavior.asciidoc
@@ -36,7 +36,7 @@ Identifies potential behavior of SharpRDP, which is a tool that can be used to p
 * Data Source: Elastic Defend
 * Resources: Investigation Guide
 
-*Version*: 112
+*Version*: 113
 
 *Rule authors*: 
 
@@ -52,46 +52,69 @@ Identifies potential behavior of SharpRDP, which is a tool that can be used to p
 *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 SharpRDP Behavior*
 
 
-Remote Desktop Protocol (RDP) enables users to connect to and control remote systems, facilitating legitimate administrative tasks. However, adversaries can exploit RDP for lateral movement within a network. SharpRDP, a tool for executing commands on remote systems via RDP, can be misused for unauthorized access. The detection rule identifies suspicious RDP activity by monitoring network connections, registry changes, and process executions, flagging potential misuse indicative of SharpRDP behavior.
-
 
 *Possible investigation steps*
 
 
-- Review the network logs to confirm the presence of incoming RDP connections on port 3389, specifically looking for connections initiated by IP addresses other than localhost (127.0.0.1 or ::1).
-- Examine the registry changes to identify any new RunMRU string values set to cmd, powershell, taskmgr, or tsclient, which could indicate command execution attempts.
-- Investigate the process execution logs to verify if any processes were started with parent processes like cmd.exe, powershell.exe, or taskmgr.exe, and ensure these are not legitimate administrative actions.
-- Correlate the timestamps of the RDP connection, registry change, and process execution to determine if they align within the 1-minute window specified by the detection rule.
-- Check the source IP address of the RDP connection against known threat intelligence feeds to assess if it is associated with any malicious activity.
-- Analyze user account activity associated with the RDP session to determine if the account was compromised or if the actions were authorized.
+- Do Timeline source events form one target-side SharpRDP chain?
+  - Focus: same-`host.id` events: inbound `source.ip`, RunMRU `registry.data.strings`, child `process.parent.name`, and child `process.command_line`.
+  - Hint: record the RunMRU time and child `process.entity_id`; the sequence alert may not preserve stage-specific process or registry fields.
+  - Implication: suspicious when non-loopback RDP to port 3389 is followed by a RunMRU shell, Task Manager, or "\\tsclient\" command and child execution; lower suspicion only when all recovered members fit one recognized interactive RDP maintenance action. Missing member events are unresolved, not benign.
+- Which RunMRU method launched execution?
+  - Focus: RunMRU `registry.path`, `registry.data.strings`, child `process.parent.name`, and child `process.command_line`.
+  - Implication: escalate when the RunMRU data selects a shell, Task Manager, or "\\tsclient\" mapped-drive payload and the child process matches that method; normal Run-dialog use is lower risk only when it launches a bounded support utility or installer without shell staging.
+- Does the source and user context fit legitimate RDP use on this target?
+  - Focus: inbound `source.ip`, launched-process `user.id`, and `user.name`.
+  - Implication: escalate when an unusual source uses an end-user or privileged account to start shells, Task Manager, or mapped-drive binaries over RDP; treat a recognized source-user pairing as context only until the RunMRU command and child identity also match the exact RDP task.
+- What ran on the target, and does its identity fit the expected RDP workflow?
+  - Focus: child `process.executable`, `process.command_line`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the command stages scripts, remote-admin tooling, credential access, or unsigned/user-writable payloads; lower suspicion only when binary identity and command line match the same bounded support or deployment workflow. A trusted signer does not clear suspicious command intent.
+- Did the launched child or its descendants create follow-on activity?
+  - Focus: same-host endpoint events scoped to recovered child `process.entity_id`: descendant `process.parent.entity_id`, persistence `registry.path`, DNS-event `dns.question.name`, and connection-event `destination.ip`.
+  - Hint: query process and registry events tied to the child ID; review DNS and connection events separately because `dns.question.name` and `destination.ip` live on different network event subtypes.
+  - Implication: escalate when descendants, registry changes, DNS lookups, or outbound connections show staging, persistence, command-and-control, or more lateral movement; absence of process-scoped DNS or connection telemetry narrows the case only when other evidence is clean. Missing network telemetry is unresolved, not benign.
+- Do related target-host alerts change scope?
+  - Focus: related RDP, remote-service, credential, and execution alerts for the same `host.id`. !{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"}}
+  - Hint: if recovered `source.ip` maps to an enrolled internal asset, follow up on outbound RDP to `destination.port` 3389 from a non-standard RDP client; missing source-host telemetry is unresolved, not benign.
+  - Implication: broaden scope when target-host alerts or caveated source-host follow-up show lateral movement beyond one recovered session; keep local only when the suspicious pattern stays confined to this target and the recovered source workflow is otherwise clean.
+- Using RDP source, RunMRU command, child lineage and identity, user context, follow-on process/registry/network evidence, and related alerts, escalate RDP-driven command execution or "\\tsclient\" payload launch without a coherent benign workflow; close only when all categories align to one exact recognized RDP workflow and no contradictory host or source evidence remains; preserve artifacts and escalate when evidence is mixed or visibility is incomplete.
 
 
 *False positive analysis*
 
 
-- Legitimate administrative tasks using RDP may trigger the rule if they involve command execution through cmd, powershell, or taskmgr. To manage this, create exceptions for known administrative IP addresses or user accounts frequently performing these tasks.
-- Automated scripts or software updates that modify the RunMRU registry key with benign commands can be mistaken for SharpRDP behavior. Identify and exclude these processes or scripts from the detection rule.
-- Remote management tools that use RDP and execute commands as part of their normal operation might be flagged. Whitelist these tools by their process names or specific command patterns to prevent false positives.
-- Internal network scanning or monitoring tools that simulate RDP connections for security assessments could be misinterpreted. Exclude these tools by their source IP addresses or network behavior signatures.
+- Helpdesk or administrator RDP support can trigger when an operator uses Win+R, Task Manager, or a mapped drive to launch a diagnostic or installer. Confirm `source.ip`, `host.id`, `user.id`, `registry.data.strings`, `process.parent.name`, and `process.executable`/`process.command_line` match one task with no suspicious descendant activity. Without telemetry proof, require operator or ticket confirmation; do not close from historical pattern alone.
+- TSClient drive-redirection deployment can explain `\\tsclient\` execution only when a known installer or utility launches with stable `process.hash.sha256` or `process.code_signature.subject_name`, matching `process.parent.name`, `source.ip`, and `host.id`. Do not close if registry, DNS, connection, or descendant evidence contradicts it.
+- Before creating an exception, anchor on: `source.ip`, `host.id`, `user.id`, exact `registry.data.strings`, `process.parent.name`, and `process.executable` or `process.hash.sha256`. Avoid exceptions on `destination.port`, `process.name`, or RunMRU path alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected host from the network to prevent further lateral movement and unauthorized access.
-- Terminate any suspicious processes identified in the alert, such as those initiated by cmd.exe, powershell.exe, or taskmgr.exe, to halt any ongoing malicious activity.
-- Review and revert any unauthorized registry changes, particularly those related to the RunMRU registry path, to restore system integrity.
-- Conduct a thorough examination of the affected host for additional indicators of compromise, such as unauthorized user accounts or scheduled tasks, and remove any found.
-- Reset credentials for any accounts that were accessed or potentially compromised during the incident 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 RDP connections and registry changes to detect and respond to similar threats more effectively in the future.
+- If confirmed benign, reverse any temporary containment and document the exact `source.ip`, `user.id`, `registry.data.strings`, `process.executable`, and `host.id` that established the confirmed workflow. Create an exception only after the exact activity is confirmed and the exception can be pinned to the narrow workflow pattern.
+- If suspicious but unconfirmed, export the Timeline source events, capture the launched child process record and parent command line, save the RunMRU value data, and collect staged payloads, persistence key/value snapshots, DNS names, and connection destinations before containment or cleanup.
+- If suspicious but unconfirmed, after preservation apply reversible containment: end the active RDP session, temporarily restrict new RDP connections from the recovered `source.ip`, or increase monitoring on the affected `host.id`. Escalate to host isolation only when follow-on activity shows broader abuse and the host role can tolerate isolation.
+- If confirmed malicious, isolate the host when feasible, suspend or block the RDP access path or account that established the session, and terminate the launched child process plus suspicious descendants only after preserving the process and command evidence.
+- Review other hosts and users tied to the same `source.ip`, `user.id`, or distinctive `process.command_line` pattern before deleting artifacts or resetting credentials so scoping completes before evidence is destroyed.
+- Remove staged payloads, persistence changes, or follow-on tooling identified during the investigation, then reset or reissue credentials only when the process, user, and source evidence shows likely account misuse or credential exposure.
+- Post-incident hardening: restrict RDP access to controlled jump hosts, limit drive redirection where it is not required, retain process plus registry plus network telemetry on RDP targets, and document any adjacent detection gaps for the detection engineering team.
+
+
+==== 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
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-system-tampering-via-file-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-system-tampering-via-file-modification.asciidoc
index 3942152e6c..58ef1d281a 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-system-tampering-via-file-modification.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-system-tampering-via-file-modification.asciidoc
@@ -31,7 +31,6 @@ Identifies attempts to delete or modify critical files used during the boot proc
 * Domain: Endpoint
 * OS: Windows
 * Use Case: Threat Detection
-* Tactic: Defense Evasion
 * Tactic: Impact
 * Data Source: Elastic Endgame
 * Resources: Investigation Guide
@@ -39,9 +38,8 @@ Identifies attempts to delete or modify critical files used during the boot proc
 * Data Source: Sysmon
 * Data Source: Microsoft Defender XDR
 * Data Source: SentinelOne
-* Data Source: Crowdstrike
 
-*Version*: 4
+*Version*: 5
 
 *Rule authors*: 
 
@@ -61,37 +59,78 @@ Identifies attempts to delete or modify critical files used during the boot proc
 *Investigating Potential System Tampering via File Modification*
 
 
-This rule identifies attempts to delete or modify critical files used during the boot process to prevent the system from booting.
-
 
 *Possible investigation steps*
 
 
-- Investigate the process execution chain (parent process tree) for unknown processes.
-- Assess all deleted or modified system critical files and perform a complete recovery of those files to prevent system booting issues.
-- Investigate other alerts associated with the user/host during the past 48 hours.
-- Identify the user account that performed the action and whether it should perform this kind of action, if not immedialy disable the account.
+- Does the alert-local file event show modification or deletion of an active boot-critical file?
+  - Focus: `file.path`, `file.name`, `event.type`, `event.action`, and `process.executable`.
+  - Implication: escalate on deletion or active Windows System32, Windows Boot, or EFI boot paths for `winload.exe`, `winload.efi`, `ntoskrnl.exe`, or `bootmgr`; lower concern only when path normalization or surrounding file evidence shows repair content, not active boot content.
+- Is the modifying process consistent with servicing, repair, recovery, or rollback?
+  - Focus: same-process `process.executable`, `process.command_line`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. !{investigate{"description":"","label":"Events for the modifying process on this host","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}],[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if the transform is ambiguous or empty, recover the process start with `host.id`, `process.pid`, and alert time before judging identity.
+  - Implication: escalate when the binary is unsigned or untrusted, runs from a user-writable or unexpected path, or uses non-servicing commands; a trusted Microsoft or vendor identity lowers concern only when behavior and lineage also fit.
+- What launch chain led to the boot-file modification or deletion?
+  - Focus: same-host process lineage with `process.parent.executable` and `process.parent.command_line`.
+  - Implication: escalate when the chain includes script hosts, remote-management tooling, document launchers, or unexplained intermediaries before the write; lower concern when lineage resolves to a bounded same-host servicing or recovery workflow.
+- Does the user or service context fit legitimate maintenance?
+  - Focus: `user.id`, `user.name`, `user.domain`, and `process.Ext.session_info.logon_type`.
+  - Hint: read `process.Ext.session_info.logon_type` from the same process event used for identity.
+  - Implication: escalate when an interactive or remote user session modifies boot files directly, or when account context does not match repair duties; if session details are unavailable, do not close on user context alone.
+- Did the same process touch other boot, recovery, or protected OS files?
+  - Focus: same-process file telemetry on `host.id` and `process.entity_id`: `file.path`, `event.type`, `event.action`, and rename details for renames. !{investigate{"description":"","label":"File events for the modifying process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"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":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if the pivot is ambiguous, constrain it with `host.id`, `process.pid`, and alert time before interpreting file spread.
+  - Implication: escalate when the process modifies multiple boot-related or protected files, renames content into executable extensions, or spreads outside the original target; lower concern when activity stays bounded to the exact repair set.
+- Did the same process or host also inhibit recovery or show broader destructive behavior?
+  - Focus: surrounding process and file telemetry on `host.id`: `process.executable`, `process.command_line`, `file.path`, and `event.type` for shadow-copy, backup, boot-configuration, or WinRE changes. !{investigate{"description":"","label":"Process events on the host near the modification","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when boot-file tampering is paired with vssadmin, wbadmin, diskshadow, bcdedit, REAgentC, or wmic activity that disables recovery, deletes backups, or damages protected paths; lower concern only when this step finds no recovery-control change, backup deletion, or protected-path spread.
+- If the local findings remain suspicious or unresolved, is the pattern isolated or broader for the same host or user?
+  - Focus: related destructive or recovery-inhibition alerts for the same `host.id`: boot-file tampering, shadow-copy deletion, backup deletion, service disruption, or protected-file modification. !{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"}}
+  - Hint: if `user.id` remains relevant, compare related destructive alerts for that user separately. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate scope when the same host or user shows multiple destructive or recovery-control alerts in a short window; keep the case localized only when this is a single bounded event and local evidence resolves cleanly.
+
+- Escalate when file target, actor identity, lineage, session, protected-file spread, recovery-control, or related alerts point to unauthorized boot tampering; close only when evidence binds one recognized repair, recovery, servicing, or rollback workflow on this host with no contradictory spread; if mixed or incomplete, preserve artifacts and escalate.
 
 
 *False positive analysis*
 
 
-- Analysts can dismiss the alert if the administrator is aware of the activity, no other suspicious activity was identified, and there are justifications for the execution.
+- Offline repair, OEM recovery, Windows servicing, administrator-led boot remediation, or security/backup rollback can replace boot files. Confirm `process.executable`, signer, command line, user or service context, `file.path`, and `event.type` bind to one recognized workflow, stay bounded to the expected repair set, and do not branch into script hosts, unusual parents, protected-file damage, shadow-copy deletion, backup deletion, or boot-configuration tampering. Without change records, require the same signed repair or rollback binary, service or recovery context, protected path family, and no destructive or recovery-control activity on the same `host.id`.
+- Before creating an exception, anchor it on the narrowest stable pattern: `process.executable`, `process.code_signature.subject_name`, `file.path`, and the expected `user.id` or service context. Do not except on `process.name`, `file.name`, or Windows-path activity alone.
 
 
 *Response and remediation*
 
 
-- Initiate the incident response process based on the outcome of the triage.
-  - Prioritize cases involving critical servers and users.
-- Isolate the involved hosts to prevent further post-compromise behavior.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
-- If important data was encrypted, deleted, or modified, activate your data recovery plan.
-    - Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.).
-- 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.
-- Review the privileges assigned to the user to ensure that the least privilege principle is being followed.
-- 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).
+- If confirmed benign, reverse any temporary containment and record the repair, recovery, servicing, or rollback workflow that matched the process identity, signer, service context, and protected path set. Create an exception only after the same bounded pattern recurs.
+- If suspicious but unconfirmed, preserve the alert event, process-start record, Timeline or case export for the modifying process, boot-file metadata or available copies, recovered binary identity, lineage/session evidence, and any recovery-control or protected-file findings before containment or cleanup.
+- If suspicious but unconfirmed and the host is still online, avoid reboot until boot-file evidence is preserved. Apply reversible containment tied to the findings, such as blocking the remote administration path, disabling the active account session, or isolating the host if protected-file modification or recovery inhibition continues. Weigh host criticality before isolation.
+- If confirmed malicious, isolate the host through endpoint response when boot-file tampering, actor identity, lineage, or recovery-control evidence establishes unauthorized activity. Terminate the offending process only after preserving its entity ID, command line, affected path list, and recovered hashes. If direct response is unavailable, hand off the same evidence to the team that can isolate the host or disk.
+- Review related hosts and users for the same destructive pattern before restoring files so scoping finishes before evidence is destroyed.
+- Restore affected boot files only from trusted media, golden images, or known-good backups after destructive scope is understood, then repair any WinRE, shadow-copy, backup, or boot-configuration controls the attacker disabled.
+- Post-incident hardening: retain file and process telemetry for protected boot paths, restrict who can run repair tooling on critical systems, protect backups from the same account path, and record adjacent destructive behaviors in the case notes.
+
+==== 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]
+- https://ela.st/sysmon-event-23-setup[Sysmon Event ID 23 - File Delete]
 
 
 ==== Rule query
@@ -100,11 +139,12 @@ This rule identifies attempts to delete or modify critical files used during the
 [source, js]
 ----------------------------------
 file where host.os.type == "windows" and event.type in ("change", "deletion") and
-  file.name : ("winload.exe", "winlod.efi", "ntoskrnl.exe", "bootmgr") and
+  file.name : ("winload.exe", "winload.efi", "ntoskrnl.exe", "bootmgr") and
   file.path : ("?:\\Windows\\*", "\\Device\\HarddiskVolume*\\Windows\\*") and
   not process.executable : (
     "?:\\Windows\\System32\\poqexec.exe",
-    "?:\\Windows\\WinSxS\\amd64_microsoft-windows-servicingstack_*\\tiworker.exe"
+    "?:\\Windows\\System32\\wbengine.exe",
+    "?:\\Windows\\WinSxS\\???64_microsoft-windows-servicingstack_*\\tiworker.exe"
   ) and
   not file.path : (
     "?:\\Windows\\WinSxS\\Temp\\InFlight\\*",
@@ -112,7 +152,9 @@ file where host.os.type == "windows" and event.type in ("change", "deletion") an
     "?:\\Windows\\WinSxS\\amd64_microsoft-windows*",
     "?:\\Windows\\SystemTemp\\*",
     "?:\\Windows\\Temp\\????????.???\\*",
-    "?:\\Windows\\Temp\\*\\amd64_microsoft-windows-*"
+    "?:\\Windows\\Temp\\*\\amd64_microsoft-windows-*",
+    "\\Device\\HarddiskVolume*\\Windows\\SoftwareDistribution\\Download*",
+    "?:\\Windows\\Temp\\BootImages\\{*}\\mount\\Windows\\*"
   )
 
 ----------------------------------
diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-psreflect-script.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-psreflect-script.asciidoc
index 942e09671a..cef3d12609 100644
--- a/docs/detections/prebuilt-rules/rule-details/powershell-psreflect-script.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/powershell-psreflect-script.asciidoc
@@ -1,14 +1,14 @@
 [[powershell-psreflect-script]]
 === PowerShell PSReflect Script
 
-Detects PowerShell scripts that implements PSReflect-style helpers (for example, Add-Win32Type, New-InMemoryModule, or DllImport patterns) for dynamic Win32 API invocation. Attackers use PSReflect to call native APIs from PowerShell for execution, injection, or privilege manipulation.
+Detects PowerShell script block content containing PSReflect-style helper indicators, such as Add-Win32Type, New-InMemoryModule, or DllImport patterns, that may support dynamic Win32 API invocation from PowerShell.
 
 *Rule type*: query
 
 *Rule indices*: 
 
-* winlogbeat-*
 * logs-windows.powershell*
+* winlogbeat-*
 
 *Severity*: high
 
@@ -34,7 +34,7 @@ Detects PowerShell scripts that implements PSReflect-style helpers (for example,
 * Resources: Investigation Guide
 * Data Source: PowerShell Logs
 
-*Version*: 317
+*Version*: 318
 
 *Rule authors*: 
 
@@ -50,86 +50,66 @@ Detects PowerShell scripts that implements PSReflect-style helpers (for example,
 *Triage and analysis*
 
 
-> **Disclaimer**:
-> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.
-
 
 *Investigating PowerShell PSReflect Script*
 
 
-This rule detects PowerShell scripts consistent with PSReflect-style helpers used to dynamically define in-memory .NET types and invoke Win32 APIs via interop (for example, Add-Win32Type, New-InMemoryModule, and DllImport patterns). This technique can be used for legitimate administration and development, but it is also commonly used by adversaries to access native capabilities from PowerShell.
-
-
-*Key alert fields to review*
-
-
-- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.
-- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.
-- `powershell.file.script_block_text`: Script block content that matched the detection logic.
-- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.
-- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
-- `powershell.file.script_block_length`: Script block length (size) context.
-
-
 *Possible investigation steps*
 
 
-- Review the alert context to prioritize the investigation:
-  - Identify the affected host (`host.name`, `host.id`) and the execution context (`user.name`, `user.domain`, `user.id`).
-  - Use `@timestamp` to scope a short timeline around the activity and identify related alerts on the same host or user.
-  - Treat activity as higher risk when the executing account is unexpected for PowerShell development/administration or when the host is not typically used for scripting.
+- Does the reconstructed script block show active PSReflect native-API wiring?
+  - Why: script block logging can split one script; PSReflect is meaningful only after imports and follow-on logic are visible.
+  - Focus: reconstruct with `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`, then read `powershell.file.script_block_text` in `host.id` / `user.id` scope. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the full script defines New-InMemoryModule, Add-Win32Type, psenum, Reflection.Emit, DefineDynamicAssembly, DefineDynamicModule, or DllImportAttribute and calls wrapped APIs; lower suspicion when it is inert reference text, repository content, or a bounded lab example.
 
-- Reconstruct the complete script block content before assessing intent:
-  - Pivot on `powershell.file.script_block_id` to locate all related events.
-  - Order events by `powershell.sequence` and confirm whether the observed sequence aligns with `powershell.total`.
-  - Combine the fragments into a single script view to avoid misinterpreting partial content.
+- What native API objective does the script express?
+  - Focus: Imported DLL/function pairs and call sites in reconstructed `powershell.file.script_block_text`.
+  - Hint: renamed wrappers or helper-free variants can show the same behavior when DllImportAttribute, Reflection.Emit, VirtualAlloc, WriteProcessMemory, CreateRemoteThread, OpenProcessToken, or AdjustTokenPrivileges reveal native-API invocation.
+  - Implication: escalate when call sites map to memory manipulation, token or privilege changes, service tampering, registry changes, or network control; lower urgency when imports stay limited to bounded diagnostics or application interop and later evidence does not contradict that use.
 
-- Analyze `powershell.file.script_block_text` to understand capability and likely intent:
-  - Identify which PSReflect artifacts are present (for example, `Add-Win32Type`, `New-InMemoryModule`, `psenum`, `DefineDynamicAssembly`, `DefineDynamicModule`, and `Runtime.InteropServices.DllImportAttribute`).
-  - Determine whether the content is primarily a helper library (type/struct/enum definitions and import scaffolding) or includes immediate API calls or operational logic.
-  - If `DllImportAttribute` is used, extract the referenced DLLs and imported function names from the script text and map them to likely objectives (for example, process/memory operations, token and privilege manipulation, registry or service interaction, or networking).
-  - Capture distinctive identifiers from the script (function names, type names, imported API names, unique strings) to support scoping and hunting.
+- If endpoint process telemetry exists, how was PowerShell launched?
+  - Why: script block events preserve deobfuscated content, not the command line or parent.
+  - Focus: Recover the matching process via `host.id + process.pid` before interpreting `process.*` or `process.parent.*`; read `process.entity_id`, `process.command_line`, `process.parent.executable`, and `process.parent.command_line`. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: expand the window if no process start appears; without process telemetry, keep later review scoped to `host.id`, `user.id`, `process.pid`, and alert time.
+  - Implication: escalate when a document, browser, chat client, remote session, scheduled task, or user-writable script path launched the helper; lower suspicion when launcher and command fit the same recognized build, admin, interop, or assessment workflow as the script.
 
-- Establish script origin and distribution:
-  - If `file.path`/`file.name` are present, treat the script as file-backed and assess whether the location and filename align with approved tooling and change control.
-  - If `file.path` is not present, consider that the script may have been executed interactively or delivered in-memory, and prioritize correlation with surrounding activity for the same `user.id` and `host.id`.
+- Does script origin fit the recovered workflow?
+  - Focus: `file.path`, `file.directory`, `file.name`, missing file-origin fields, and recovered launch context.
+  - Implication: escalate when fileless on a workstation or sourced from temp, download, mounted-share, or user-writable paths that do not fit the user; lower suspicion when it resolves to a stable repository, deployment path, or test harness matching the same workflow.
 
-- Scope the activity across time, hosts, and users:
-  - Search for additional script blocks on the same `host.id` and `user.id` around `@timestamp` to identify preceding staging activity and follow-on behavior.
-  - Hunt across the environment for the same `file.path`/`file.name` and for distinctive strings extracted from `powershell.file.script_block_text` to identify other impacted hosts.
-  - Pivot on `user.id` to determine whether the same account executed similar PSReflect content on other endpoints.
+- Do same-host effects prove the wrapped APIs were used?
+  - Why: PSReflect is a helper pattern; the decisive follow-up is whether host activity matches the imported API family.
+  - Focus: API-matched effects: child execution for process APIs, staged payloads for write/load APIs, persistence or configuration changes for service/registry APIs, and outbound activity for network APIs. Use same-PID events around `@timestamp` to reduce PID-reuse ambiguity.
+    - !{investigate{"description":"","label":"Child process events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"File and registry events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Network events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when effects appear in recovered process scope or the `host.id`, `user.id`, `process.pid`, and time fallback scope; lower suspicion only when they align with the same bounded workflow. Missing network or endpoint effect telemetry is unresolved, not benign.
 
-- Correlate with adjacent telemetry (if available) to confirm execution chain and impact:
-  - Process telemetry: identify the PowerShell host process and its parent process to understand how the script was initiated (interactive, automated, or remote execution context).
-  - Network telemetry: review DNS lookups and outbound connections near the alert time for evidence of staging, command-and-control, or lateral movement.
-  - Endpoint changes: review file, service, scheduled task, and registry activity after the script execution to identify persistence, payload delivery, or privilege changes that align with the capabilities implied by the script text.
-  - If Elastic Osquery response actions are available, collect DNS cache and service inventory to support scoping and to identify suspicious services or unsigned service binaries.
+- Does related alert scope change urgency?
+  - Focus: 48-hour alerts for the same `user.id` showing repeated PowerShell, execution, defense-evasion, privilege-escalation, or credential-access activity; use same-`host.id` alerts only to confirm repeated script substrings or the same imported API set.
+    - !{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 related activity shows repeated native-API abuse, follow-on execution, or spread outside the original host; keep scope local when repetition stays confined to one exact benign workflow already supported by local evidence.
+
+- What disposition is supported?
+  - Implication: escalate when content, origin, launch, effects, or scope align on injection, privilege manipulation, persistence, remote activity, or egress that does not fit the user; close only when same-host telemetry proves one exact benign workflow and no contradictory findings remain. Outside confirmation may corroborate but not replace telemetry; if mixed or incomplete, preserve artifacts and escalate.
 
 
 *False positive analysis*
 
 
-- False positives are possible in environments where administrators, developers, or internal tooling use PSReflect-style code to access native APIs from PowerShell.
-- Validate legitimacy by confirming that:
-  - The executing account and host are expected to run advanced PowerShell code (`user.id`, `user.name`, `host.id`, `host.name`).
-  - The script source is known and controlled when `file.path`/`file.name` are present (for example, approved repositories, deployment paths, or administrative script locations).
-  - The script content and its imported APIs are consistent with a documented operational need and do not align with common attacker objectives (for example, credential access, injection, or persistence).
-- If the activity is recurring, baseline expected frequency and approved users/hosts to distinguish routine usage from anomalous execution.
+- Internal build, admin, interop, diagnostics, compatibility, or security-testing helpers can use PSReflect-style code. Confirm only when reconstructed `powershell.file.script_block_text`, imported API set, `file.path` or fileless delivery, launcher, `user.id`, `host.id`, and same-host effects all fit one bounded workflow without injection, persistence, egress, or privilege abuse. Change records, repository history, test schedules, or recurrence can support closure but not replace telemetry.
+- Before an exception, validate recurrence of the same `user.id`, `host.id`, stable `file.path` when file-backed, recovered launcher, and distinctive `powershell.file.script_block_text` substrings. Avoid exceptions on PSReflect helper strings, `user.name`, or host alone.
 
 
 *Response and remediation*
 
 
-- If malicious activity is confirmed or suspected:
-  - Contain the affected host to prevent further execution and lateral movement, following your incident response procedures.
-  - Preserve evidence: the fully reconstructed script (`powershell.file.script_block_id` with `powershell.sequence`/`powershell.total`), the raw script content (`powershell.file.script_block_text`), and any referenced file path details (`file.path`, `file.name`).
-  - Use extracted identifiers (imported API names, helper function names, unique strings) to hunt for related activity across other hosts and users.
-  - Investigate and remediate follow-on activity identified during correlation (persistence mechanisms, suspicious services, unexpected outbound connections, and any dropped or modified files).
-  - If account compromise is suspected, reset credentials for the impacted user and review recent authentication activity to identify additional compromised assets.
-
-- If the activity is confirmed benign:
-  - Document the legitimate script/tool, expected hosts/users, and the operational purpose to speed up future triage.
-  - Where appropriate, improve controls around advanced PowerShell usage (least privilege for scripting accounts, controlled script distribution, code review, and continued logging coverage).
+- If confirmed benign, document reconstructed script text, imported DLL/function set, origin, `user.id`, `host.id`, launch context, and same-host effect review before reversing containment. Create exceptions only for recurring workflows.
+- If suspicious but unconfirmed, preserve script block IDs/sequences, reconstructed text, API list, origin, process-start evidence, and same-host effect artifacts before response. Apply reversible containment such as destination restrictions or session limits; isolate only when corroboration shows likely injection, persistence, lateral movement, or credential misuse and the host role permits. Avoid destructive cleanup until scope is clearer.
+- If confirmed malicious, preserve the same artifacts plus related child-process, file-system, persistence, credential, and destination evidence before containment. Isolate the host and terminate PowerShell or child payloads after evidence capture; if direct response is unavailable, escalate with preserved artifacts. Block malicious scripts, payload hashes, and destinations, then review related users/hosts for the same script substrings, API set, or launch chain before eradication.
+- After containment, remove only scripts or payloads identified during investigation, undo persistence or configuration changes tied to the API objective, and remediate the delivery path or automation that launched the helper. If imports or same-host effects suggest credential theft, token abuse, or remote execution, reset affected credentials and review related auth/admin sessions before cleanup.
+- Post-incident hardening: restrict PowerShell interop and unsigned script distribution to controlled build, admin, or test systems; retain script block logging and endpoint process telemetry for `host.id + process.pid` recovery; document renamed-wrapper or helper-free reflection variants.
 
 
 ==== Setup
diff --git a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-named-pipe-impersonation.asciidoc b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-named-pipe-impersonation.asciidoc
index 8653d117d6..e66d634825 100644
--- a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-named-pipe-impersonation.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-named-pipe-impersonation.asciidoc
@@ -1,7 +1,7 @@
 [[privilege-escalation-via-named-pipe-impersonation]]
 === Privilege Escalation via Named Pipe Impersonation
 
-Identifies a privilege escalation attempt via named pipe impersonation. An adversary may abuse this technique by utilizing a framework such Metasploit's meterpreter getsystem command.
+Identifies a privilege escalation attempt via named pipe impersonation. An adversary may abuse this technique by utilizing a framework such as Metasploit's meterpreter getsystem command.
 
 *Rule type*: eql
 
@@ -48,7 +48,7 @@ Identifies a privilege escalation attempt via named pipe impersonation. An adver
 * Data Source: SentinelOne
 * Data Source: Crowdstrike
 
-*Version*: 318
+*Version*: 319
 
 *Rule authors*: 
 
@@ -68,57 +68,87 @@ Identifies a privilege escalation attempt via named pipe impersonation. An adver
 *Investigating Privilege Escalation via Named Pipe Impersonation*
 
 
-A named pipe is a type of inter-process communication (IPC) mechanism used in operating systems like Windows, which allows two or more processes to communicate with each other by sending and receiving data through a well-known point.
-
-Attackers can abuse named pipes to elevate their privileges by impersonating the security context in which they execute code. Metasploit, for example, creates a service and a random pipe, and then uses the service to connect to the pipe and impersonate the service security context, which is SYSTEM.
-
-> **Note**:
-> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
-
 
 *Possible investigation steps*
 
 
-- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
-- Investigate other alerts associated with the user/host during the past 48 hours.
-- Inspect the host for suspicious or abnormal behavior in the alert timeframe.
-- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes.
-- Examine the host for derived artifacts that indicate suspicious activities:
-  - If any suspicious processes were found, examine the process executable using a private sandboxed analysis system.
-  - Observe and collect information about the following activities in both the sandbox and the alert subject host:
-    - Attempts to contact external domains and addresses.
-      - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.
-      - Examine the DNS cache for suspicious or anomalous entries.
-        - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}}
-    - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
-    - Examine the host services for suspicious or anomalous entries.
-      - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}}
-      - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}}
-      - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}}
-  - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
+- Did the alert process act as a named-pipe client for a SYSTEM-token handoff?
+  - Why: GetSystem-style abuse pairs a service-context client with a named-pipe server so the server can impersonate the client token; the shell pipe-write is the client-side marker.
+  - Focus: `process.name`, `process.pe.original_file_name`, `process.command_line`, `host.id`, and `user.id`.
+  - Implication: escalate when cmd or PowerShell sends a short marker into a named pipe before token impersonation; lower suspicion only when the same pipe name, marker, host, and user match a stable validation pattern.
+- Does the parent and token context fit a service-driven impersonation attempt?
+  - Focus: `process.parent.name`, `process.parent.command_line`, broader process lineage when needed, `process.Ext.token.integrity_level_name`, and `process.Ext.token.elevation_level`. !{investigate{"description":"","label":"Process starts on the host near the pipe write","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when services.exe, service-creation command lines, or an unexplained launcher starts the pipe write under high or SYSTEM context; absent or ambiguous token context cannot close the alert without matching identity and follow-on evidence.
+- Is the launching binary the expected Windows shell or a masqueraded copy?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the shell runs from a user-writable or deceptive path, has an untrusted signer, or mismatches its original file name; signed System32 cmd or PowerShell confirms identity only and does not clear the pipe-write behavior.
+- Did the pipe writer launch or enable follow-on SYSTEM activity?
+  - Focus: child process events from `process.entity_id`; review `process.name`, `process.command_line`, and `process.Ext.token.integrity_level_name`. !{investigate{"description":"","label":"Child process starts from the pipe writer","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when a shell, tool, service helper, or credential-access process follows under high or SYSTEM integrity; absence of child process evidence lowers only follow-on confidence when pipe syntax or service parentage remains suspicious.
+  - Hint: if `process.entity_id` is unavailable, use `host.id` plus `process.pid` in a tight alert-time window and treat matches as weaker.
+- Is this isolated, or part of repeated named-pipe impersonation behavior?
+  - Focus: process starts sharing `host.id` or `user.id`, marker behavior in `process.command_line`, and either `process.parent.name` or `process.hash.sha256`.
+    - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate scope when repeats cross hosts, users, hashes, or parent chains; keep response local only when all repeats stay inside the same process-evidenced validation pattern.
+  - Range: start with the alert window; expand only if local evidence is suspicious or unresolved.
+- Escalate on suspicious pipe-write syntax, parent/token context, binary identity, follow-on process activity, or host/user scope; close only when all evidence matches a stable validation pattern with no contradictions; preserve artifacts and escalate when evidence is mixed or incomplete.
 
 
 *False positive analysis*
 
 
-- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+- Routine administration should not require shell echo redirection into a named pipe for privilege escalation. Controlled security validation is the narrow benign path; process evidence must prove the exact pattern:
+  - **Identity**: `process.executable`, `process.hash.sha256`, signer, and `process.parent.command_line` match the validation toolchain.
+  - **Pipe syntax**: `process.command_line` shows the expected pipe name, echo value, and wrapper syntax for that test.
+  - **Scope**: `host.id` and `user.id` stay inside the known test target and operator scope.
+  - **Follow-on**: child process starts do not show unexpected high or SYSTEM activity outside the test plan.
+  - If telemetry cannot prove the test scope or toolchain, outside confirmation can corroborate the case but cannot override contradictory process evidence; otherwise preserve and escalate.
+- Build exceptions only from the minimum confirmed validation pattern: stable `process.hash.sha256`, `process.executable`, `process.parent.command_line`, constrained `host.id` or `user.id`, and the specific pipe-write shape in `process.command_line`. Avoid exceptions on `process.name`, cmd or PowerShell alone, or a pipe name alone.
 
 
 *Response and remediation*
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Isolate the involved host to prevent further post-compromise behavior.
-- If the triage identified malware, search the environment for additional compromised hosts.
-  - Implement temporary network rules, procedures, and segmentation to contain the malware.
-  - Stop suspicious processes.
-  - Immediately block the identified indicators of compromise (IoCs).
-  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
-- Remove and block malicious artifacts identified during triage.
-- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
-- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
-- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+- If confirmed benign:
+  - Reverse any temporary containment and document the evidence that confirmed the validation workflow: pipe syntax, parent/token context, binary identity, `host.id`, `user.id`, and lack of unexpected follow-on SYSTEM activity.
+- If suspicious but unconfirmed:
+  - Preserve the alert, process tree, command lines, parent and child process records, `process.entity_id`, `process.pid`, hashes, and the named-pipe string before termination, cleanup, or credential actions.
+  - Apply reversible containment tied to the findings, such as isolating the endpoint after weighing host criticality or restricting the affected account/session while investigation continues.
+  - Do not terminate cmd, PowerShell, or child processes until the process identifiers, command lines, and any volatile state needed by responders are captured.
+- If confirmed malicious:
+  - Isolate the endpoint after preservation when parent/token, identity, or follow-on process evidence confirms unauthorized SYSTEM activity.
+  - Suspend or terminate the pipe writer and follow-on processes only after recording their entity IDs, PIDs, command lines, hashes, and parent relationships.
+  - Reset credentials or revoke sessions for affected users only when process/session evidence indicates account misuse or credential exposure.
+  - Eradicate only malicious tools, service definitions, binaries, scripts, and configuration changes confirmed during the investigation, then remediate the entry vector that allowed the named-pipe impersonation attempt.
+- Post-incident hardening:
+  - Restrict local admin and service-creation rights that allow untrusted tooling to create SYSTEM service clients.
+  - Retain command-line, parent/child process, and token-integrity telemetry because those fields distinguish testing from GetSystem abuse.
+  - Document the confirmed benign validation pattern or malicious artifact set so future analysts can separate repeat testing from repeat abuse.
+
+
+==== 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
diff --git a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc
index c29cfb2e7d..1808409513 100644
--- a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc
@@ -35,7 +35,7 @@ Identifies a privilege escalation attempt via rogue named pipe impersonation. An
 * Data Source: Sysmon
 * Resources: Investigation Guide
 
-*Version*: 211
+*Version*: 212
 
 *Rule authors*: 
 
@@ -51,46 +51,55 @@ Identifies a privilege escalation attempt via rogue named pipe impersonation. An
 *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 Privilege Escalation via Rogue Named Pipe Impersonation*
 
 
-Named pipes in Windows facilitate inter-process communication, allowing data exchange between processes. Adversaries exploit this by creating rogue named pipes, tricking privileged processes into connecting and executing malicious actions under elevated privileges. The detection rule identifies suspicious named pipe creation events, focusing on patterns indicative of impersonation attempts, thus flagging potential privilege escalation activities.
-
 
 *Possible investigation steps*
 
 
-- Review the event logs for the specific named pipe creation event identified by the query, focusing on the file.name field to determine the exact named pipe path and assess its legitimacy.
-- Correlate the event with the process that created the named pipe by examining related process creation logs, identifying the process ID and executable responsible for the action.
-- Investigate the user context under which the named pipe was created to determine if it aligns with expected behavior or if it indicates potential misuse of privileges.
-- Check for any recent changes or anomalies in the system's configuration or user accounts that could suggest unauthorized access or privilege escalation attempts.
-- Analyze historical data for similar named pipe creation events to identify patterns or repeated attempts that could indicate a persistent threat or ongoing attack.
+- What rogue pipe path did the alert preserve?
+  - Why: the rule references PrintSpoofer and EfsPotato-style abuse, where a controlled pipe can be hidden inside a path that makes a privileged service connect to what appears to be its normal RPC pipe.
+  - Focus: alert-local `file.name`, `file.path`, or `winlog.event_data.PipeName`, with `event.provider` and `event.code`.
+  - Implication: escalate when the path embeds `\pipe\` after another path segment or mimics a service/RPC pipe tail; benign starts only when exact namespace, creator path, command line, account, and client evidence fit one repeated local IPC workflow on this `host.id`.
+- Which process and account created the suspicious pipe?
+  - Focus: same-host creator `process.executable`, `process.command_line`, `user.name`, and `user.domain`.
+  - Implication: escalate when a service, web worker, script host, or user-writable binary creates the pipe under a low-privileged service identity or account that should not host IPC servers; service-mimic pipe plus suspicious creator is enough while collecting client and impact evidence.
+  - Hint: pivot by `process.entity_id`; if absent, pair `process.pid` with `host.id` in a tight window. !{investigate{"description":"","label":"Events for the pipe creator 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":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+- Do surrounding events corroborate the creator or show a privileged client?
+  - Focus: same-host Sysmon or Windows records for the same `file.name` or `winlog.event_data.PipeName`, reading `event.code`; pipe-connected events, when ingested, corroborate.
+  - Hint: same pipe events on the host. !{investigate{"description":"","label":"Events for the same pipe on this host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.name","queryType":"phrase","value":"{{file.name}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.PipeName","queryType":"phrase","value":"{{winlog.event_data.PipeName}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when surrounding records show the same creator maintaining the pipe or, if pipe-connected events exist, a SYSTEM, administrator, service-host, or service/RPC client touching it. Missing pipe-connect telemetry is unresolved, not benign.
+  - Range: alert window plus +/-5 minutes; expand only if the creator lived longer.
+- Was the pipe followed by elevated execution or token/session abuse?
+  - Focus: same-host process starts after pipe creation: `process.executable`, `process.command_line`, `user.name`, and `winlog.event_data.ElevatedToken` when Windows Security has token context.
+  - Hint: process starts on the host around pipe creation. !{investigate{"description":"","label":"Process starts on the host near the pipe creation","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: elevated shell, script, service-control, SYSTEM, administrator, or elevated-token activity confirms impact; absence lowers impact only after the pipe path, creator, and client evidence fit one recognized workflow. Missing process-start or token telemetry is unresolved, not benign.
+- Does the same rogue-pipe pattern show wider tooling or repeated attempts?
+  - Focus: broaden only after suspicious or unresolved local evidence, using the suspicious `file.name` or `winlog.event_data.PipeName` pattern, creator `process.executable`, `host.id`, and `user.id`.
+  - Hint: same pipe name or creator executable across recent events. !{investigate{"description":"","label":"Events for the same pipe or creator executable","providers":[[{"excluded":false,"field":"file.name","queryType":"phrase","value":"{{file.name}}","valueType":"string"}],[{"excluded":false,"field":"winlog.event_data.PipeName","queryType":"phrase","value":"{{winlog.event_data.PipeName}}","valueType":"string"}],[{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: expand scope when the same embedded-pipe pattern, service/RPC-like tail, or creator executable appears across unrelated hosts or users; no recurrence limits scope but does not close the alert.
+- Escalate when pipe shape plus creator, client, or follow-on evidence supports impersonation; close only when available evidence aligns to one recognized IPC product or authorized test with no contradictory privileged-client or elevated-execution evidence; preserve evidence and escalate when telemetry is missing, mixed, or incomplete.
 
 
 *False positive analysis*
 
 
-- Legitimate software or system processes may create named pipes that match the detection pattern. Regularly review and whitelist known benign processes that frequently create named pipes to reduce noise.
-- System management tools and monitoring software might generate named pipe creation events as part of their normal operation. Identify these tools and exclude their events from triggering alerts.
-- Custom in-house applications that use named pipes for inter-process communication can trigger false positives. Work with development teams to document these applications and create exceptions for their activity.
-- Scheduled tasks or scripts that run with elevated privileges and create named pipes could be mistaken for malicious activity. Ensure these tasks are documented and excluded from the detection rule.
-- Security software or endpoint protection solutions may use named pipes for legitimate purposes. Verify these activities and adjust the rule to prevent unnecessary alerts.
+- Recognized local IPC products, security tools, or in-house services can trigger when they use nested pipe namespaces with `\pipe\`. Confirm the exact namespace, creator path and command line, account, client process, and host cohort align to the same product, with no elevated follow-on outside that workflow.
+- Authorized exploit validation can trigger this rule. Confirm test host, test account, time window, pipe namespace, and launched command match the test plan; privileged-client or elevated-execution evidence beyond the plan is suspicious.
+- Build exceptions from the minimum confirmed workflow: exact pipe namespace or stable prefix, creator `process.executable` plus command-line pattern, expected `user.id`, and constrained `host.id` or host group. Avoid broad exceptions on `process.name`, service-like pipe tails, or generic `\pipe\`.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
-- Terminate any suspicious processes associated with the rogue named pipe to halt any ongoing malicious activities.
-- Conduct a thorough review of the system's event logs, focusing on named pipe creation events, to identify any other potentially compromised processes or systems.
-- Reset credentials for any accounts that may have been exposed or used in the privilege escalation attempt to prevent further unauthorized access.
-- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
-- Implement enhanced monitoring for named pipe creation events across the network to detect and respond to similar threats in the future.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken.
+- If confirmed benign, reverse temporary containment and record the pipe namespace, creator process, account, client process, host scope, and absence of unexpected elevated follow-on activity.
+- If suspicious but unconfirmed, preserve the alert record, relevant Timeline events, `file.name` or `winlog.event_data.PipeName`, creator `process.entity_id` or `process.pid`, process command lines, Windows Security records, and any spawned process identifiers before containment.
+- Apply reversible containment before destructive action: isolate or restrict the affected host only when pipe, creator, client, or follow-on evidence indicates active abuse, and weigh critical host roles before isolation.
+- If confirmed malicious, contain the host and involved account, then terminate or suspend malicious processes only after preserving identifiers and command lines. Reset credentials only when Windows Security or process evidence shows account misuse or exposed privileged sessions.
+- Eradicate only the exploit tools, scripts, service changes, or payloads identified during the investigation, then address the entry vector that let the creator process run with impersonation-capable privileges.
+- Post-incident, restrict the privileged service or service account that the investigation showed was coerced or exposed to unnecessary impersonation-capable privileges.
 
 ==== Setup
 
@@ -99,14 +108,9 @@ Named pipes in Windows facilitate inter-process communication, allowing data exc
 *Setup*
 
 
-Named Pipe Creation Events need to be enabled within the Sysmon configuration by including the following settings:
-`condition equal "contains" and keyword equal "pipe"`
+This rule requires Sysmon telemetry to be enabled and ingested.
 
-If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
-events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
-Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
-`event.ingested` to @timestamp.
-For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
+Setup instructions: https://ela.st/sysmon-event-pipe-setup
 
 
 ==== Rule query
diff --git a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-windir-environment-variable.asciidoc b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-windir-environment-variable.asciidoc
index 450a7f3d4b..ca5a5d957c 100644
--- a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-windir-environment-variable.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-windir-environment-variable.asciidoc
@@ -43,7 +43,7 @@ Identifies a privilege escalation attempt via a rogue Windows directory (Windir)
 * Data Source: Crowdstrike
 * Resources: Investigation Guide
 
-*Version*: 315
+*Version*: 316
 
 *Rule authors*: 
 
@@ -59,48 +59,86 @@ Identifies a privilege escalation attempt via a rogue Windows directory (Windir)
 *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 Privilege Escalation via Windir Environment Variable*
 
 
-The Windir environment variable points to the Windows directory, crucial for system operations. Adversaries may alter this variable to redirect processes to malicious directories, gaining elevated privileges. The detection rule monitors changes to this variable in the registry, flagging deviations from expected paths like "C:\windows," thus identifying potential privilege escalation attempts.
-
 
 *Possible investigation steps*
 
 
-- Review the registry change event details to identify the specific user account associated with the altered Windir or SystemRoot environment variable. This can be done by examining the registry path and user context in the event data.
-- Check the registry data strings to determine the new path set for the Windir or SystemRoot variable. Investigate if this path points to a known malicious directory or an unexpected location.
-- Correlate the event with other recent registry changes or system events on the same host to identify any patterns or additional suspicious activities that might indicate a broader attack.
-- Investigate the process or application that initiated the registry change by reviewing process creation logs or command-line arguments around the time of the event. This can help identify the source of the change.
-- Assess the affected system for any signs of compromise or unauthorized access, such as unusual network connections, unexpected running processes, or new user accounts.
-- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns, particularly those involving privilege escalation techniques.
-- If possible, restore the Windir or SystemRoot environment variable to its expected value and monitor the system for any further unauthorized changes.
+- Does the alert show a Windir or SystemRoot override that can affect this user?
+  - Focus: `registry.path`, `registry.value`, `registry.data.strings`, `host.id`, and `user.id`.
+  - Implication: Escalate when a per-user Environment hive, such as HKEY_USERS SID or HKCU-equivalent context, changes "windir" or "systemroot" away from "C:\Windows" or "%SystemRoot%"; lower suspicion only when the same host and user recur with the same test or image-engineering value.
+
+- Does the replacement value create a redirection path?
+  - Focus: `registry.data.strings` and `registry.data.type`: user-writable roots, UNC paths, or unexpected command content.
+  - Implication: Escalate when the value can redirect a Windows-root process to attacker-controlled content or command execution; lower suspicion only when the exact replacement is bounded test or image data and no later elevated execution uses it.
+
+- Is the writing process the expected tool in an explainable launch chain?
+  - Focus: `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.parent.command_line`.
+  - Implication: Escalate when the writer is "reg.exe", a script host, unsigned or user-writable binary, browser or Office child, or renamed tool outside a recognized management chain; reduce suspicion only when signer, path, parent, and arguments match the same test or image-engineering toolchain.
+
+- Does the session and token context make a UAC-bypass path feasible?
+  - Focus: `user.id`, `user.domain`, `process.Ext.session_info.logon_type`, `process.Ext.token.integrity_level_name`, and `process.Ext.token.elevation_level`.
+  - Implication: Escalate when an interactive or remote-admin user changes a per-user value from a medium or limited token and later activity reaches high integrity; lower suspicion when a noninteractive service or repair context cannot exercise an interactive auto-elevated task.
+  - Hint: Recover session and token fields from the writer process by `process.entity_id`; if absent, use the same host plus `process.pid` and a tight time window. !{investigate{"description":"","label":"Writer process event","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+
+- Did follow-on process execution exercise the override?
+  - Focus: same-host, same-user process starts after the alert, comparing `process.executable`, `process.command_line`, `process.parent.executable`, and `process.Ext.token.integrity_level_name` to the replacement value.
+  - Implication: Escalate when follow-on execution resolves through the substituted path or higher integrity, or when command-line evidence consumes then deletes or restores the value.
+  - Hint: If no follow-on execution appears in the alert window, treat the value as staged and extend only far enough to test later starts reusing the same replacement string. !{investigate{"description":"","label":"Process events for the same user and host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+
+- If local evidence is suspicious or unresolved, do related alerts change scope?
+  - Focus: related alerts for meaningful `user.id` values, such as real users or named service accounts. For machine, local service, or generic service identities, prioritize same-host alerts.
+    - !{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 response when the same user or host has adjacent privilege-escalation, persistence, defense-evasion, credential-access, or suspicious elevated-process alerts; keep scope local when related alerts are absent and local telemetry supports the same test or image-engineering pattern.
+
+Final - Escalate when the non-default value enables redirection or command execution and writer, session, follow-on, or related-alert evidence is suspicious; close only when the registry value, writer path and parent, session, timeline, and host or user pattern fit the same test or image-engineering workflow; preserve artifacts and escalate when evidence is mixed or visibility is incomplete.
 
 
 *False positive analysis*
 
 
-- System updates or patches may temporarily alter the Windir environment variable. Monitor for these events during known maintenance windows and consider excluding them from alerts.
-- Custom scripts or applications that modify environment variables for legitimate purposes can trigger false positives. Identify these scripts and whitelist their activity in the detection rule.
-- User profile migrations or system restorations might change the Windir path. Exclude these operations if they are part of routine IT processes.
-- Virtual environments or sandboxed applications may use different Windir paths. Verify these environments and adjust the detection rule to accommodate their specific configurations.
-- Administrative tools that modify user environments for configuration management can cause alerts. Document these tools and create exceptions for their expected behavior.
+- Non-default per-user "windir" or "systemroot" values are unusual on production endpoints. Close as benign only when registry value, writer identity, parent chain, session, host and user pattern, and surrounding process or registry activity converge on one exact test or image-engineering workflow; outside confirmation can corroborate only after telemetry aligns. Recurrence can support missing records but not unresolved current telemetry.
+- Do not close if the replacement value, writer lineage, host or user pattern, or elevated-execution evidence drifts.
+- Before creating an exception, validate the minimum stable pattern: exact `registry.path`, exact or tightly bounded `registry.data.strings`, writer `process.executable`, parent `process.parent.command_line`, `host.id`, and `user.id`. Avoid exceptions on `registry.value`, process names such as "cmd.exe", or `host.id` alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Revert the Windir environment variable to its legitimate value, typically "C:\windows", to restore normal system operations.
-- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious software or scripts.
-- Review recent user activity and system logs to identify any unauthorized access or changes, focusing on the time frame around the detected registry change.
-- Reset passwords for any user accounts that may have been compromised, especially those with elevated privileges.
-- 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 on the affected system and similar endpoints to detect any further attempts to alter critical environment variables or other suspicious activities.
+- If confirmed benign, reverse temporary containment and record the exact evidence that proved the workflow: `registry.path`, `registry.data.strings`, writer `process.executable`, `process.parent.command_line`, `host.id`, and `user.id`. Create an exception only if the same bounded pattern is stable across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve a case export of the alert and registry event, the original and modified Environment values, the writer process tree anchored on `process.entity_id`, command lines, and any substituted-path binaries or scripts recovered from the host before containment or cleanup.
+- Apply reversible containment first: heightened monitoring, temporary task or execution restrictions, or removal of the rogue Environment value after evidence capture if operations permit it. Escalate to host isolation or account containment only when follow-on elevated execution, higher-integrity child processes, or related post-exploitation alerts make active misuse likely and the host role can tolerate stronger action.
+- If confirmed malicious, isolate the endpoint when the registry value, writer lineage, session context, and follow-on execution show unauthorized privilege escalation. Before terminating processes or deleting artifacts, record the writer and follow-on process entity IDs, command lines, parent chain, modified registry path and value, substituted-path artifacts, and privileged process paths.
+- After scope is preserved, restore "windir" or "systemroot" to the expected value, remove substituted-path content or execution triggers identified during triage, and review which privileged processes executed from the substituted path before cleanup.
+- If the override was exercised or related alerts show broader compromise, treat the affected user context as potentially elevated beyond its intended boundary. Scope administrator or remote-access accounts active on the host and perform credential hygiene according to exposure and role.
+- Post-incident hardening: reduce use of environment-variable-expanded paths in auto-elevated tasks where possible, retain process and registry telemetry needed for writer-lineage and follow-on execution review, and record any uncovered variant or visibility gap in the case outcome.
+
+==== 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-reg-setup[Sysmon Registry Events]
+
 
 ==== Rule query
 
diff --git a/docs/detections/prebuilt-rules/rule-details/privileges-elevation-via-parent-process-pid-spoofing.asciidoc b/docs/detections/prebuilt-rules/rule-details/privileges-elevation-via-parent-process-pid-spoofing.asciidoc
index 8683ff210d..fb1b15ca41 100644
--- a/docs/detections/prebuilt-rules/rule-details/privileges-elevation-via-parent-process-pid-spoofing.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/privileges-elevation-via-parent-process-pid-spoofing.asciidoc
@@ -22,7 +22,7 @@ Identifies parent process spoofing used to create an elevated child process. Adv
 *References*: 
 
 * https://gist.github.com/xpn/a057a26ec81e736518ee50848b9c2cd6
-* https://blog.didierstevens.com/2017/03/20/
+* https://blog.didierstevens.com/2017/03/20/that-is-not-my-child-process/
 * https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute
 * https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1134.002/T1134.002.md
 
@@ -35,7 +35,7 @@ Identifies parent process spoofing used to create an elevated child process. Adv
 * Data Source: Elastic Defend
 * Resources: Investigation Guide
 
-*Version*: 11
+*Version*: 12
 
 *Rule authors*: 
 
@@ -51,47 +51,67 @@ Identifies parent process spoofing used to create an elevated child process. Adv
 *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 Privileges Elevation via Parent Process PID Spoofing*
 
 
-Parent Process ID (PPID) spoofing is a technique where adversaries manipulate the PPID of a process to disguise its origin, often to bypass security measures or gain elevated privileges. This is particularly concerning in Windows environments where processes can inherit permissions from their parent. The detection rule identifies suspicious process creation patterns, such as unexpected PPID values and elevated user IDs, while filtering out known legitimate processes and trusted signatures, to flag potential privilege escalation attempts.
-
 
 *Possible investigation steps*
 
 
-- Review the process creation event details, focusing on the process.parent.Ext.real.pid and user.id fields to confirm if the PPID spoofing led to privilege escalation to SYSTEM.
-- Examine the process.executable and process.parent.executable paths to determine if the process is known or expected in the environment, and check against the list of excluded legitimate processes.
-- Investigate the process.code_signature fields to verify if the process is signed by a trusted entity and if the signature is valid, especially if the process is not excluded by the rule.
-- Check the historical activity of the involved user.id and process.parent.executable to identify any unusual patterns or recent changes in behavior.
-- Correlate the alert with other security events or logs to identify any related suspicious activities or potential lateral movement attempts within the network.
+- Does the alert show a SYSTEM child with a spoofed parent relationship?
+  - Focus: `user.id`, token integrity, `process.parent.pid`, `process.parent.Ext.real.pid`, and `process.parent.executable`.
+  - Implication: escalate when a SYSTEM child has a nonzero real-creator PID that differs from the reported parent, especially when that parent gives trusted system, service, or desktop cover; treat a recognized broker or authorized test as only a candidate benign path until creator and child intent are checked.
+  - Why: PPID spoofing can make process-tree views show the selected parent instead of the process that requested creation.
+- Which process actually requested the spoofed launch?
+  - Focus: recovered creator for `process.parent.Ext.real.pid`: `process.entity_id`, `process.executable`, `process.command_line`, signer, and trust state.
+  - Implication: escalate when the creator is unsigned, user-writable, a shell or script launcher, or unrelated to the reported parent; lower suspicion only for a stable signed vendor, update, accessibility, audit, or test component tied to the same workflow.
+  - Why: the Windows parent-process attribute can select a parent handle, so the recovered creator is the actor path the visible parent may hide.
+  - Hint: search the same `host.id` around `@timestamp` for `process.pid` = `process.parent.Ext.real.pid`; keep PID windows tight because PIDs are reused. !{investigate{"description":"","label":"Real creator process event","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.Ext.real.pid}}","valueType":"string"}]],"relativeFrom":"now-15m","relativeTo":"now"}}
+- Does the SYSTEM child identity and command line fit the recovered creator workflow?
+  - Focus: `process.executable`, `process.command_line`, `process.pe.original_file_name`, signer, and trust state.
+  - Implication: escalate when the child is a shell, script host, renamed binary, user-writable executable, unsigned or untrusted, or has commands that do not belong to the recovered creator; trusted signing reduces identity concern but does not clear PPID spoofing without launch-context fit.
+- Did the spoofed SYSTEM child launch follow-on activity?
+  - Focus: child process events from `process.entity_id`, reviewing `process.executable`, `process.command_line`, and `user.id`. !{investigate{"description":"","label":"Descendant process events for the spoofed child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when it spawns shells, scripting, credential, service, or lateral-movement tooling under SYSTEM; no descendants lowers immediate impact but does not clear a suspicious creator or child identity.
+  - Hint: if `process.entity_id` is unavailable, fall back to `host.id`, `process.pid`, and a tight alert-time window.
+- If escalation is likely, what is the immediate scope?
+  - Focus: prior process alerts for `host.id` and `user.id` with matching child executable or hash, reported parent, and real-creator PID.
+    - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: expand containment and scoping when the same child or creator appears on other hosts or unrelated users; keep scope local when the tuple is isolated and no descendant activity contradicts it. Do not use recurrence alone to close.
+  - Range: use a lookback that fits endpoint retention.
+
+Disposition: escalate when PPID spoofing to SYSTEM has an unrecognized creator, suspicious child, misleading parent, SYSTEM follow-on activity, or cross-host scope. Close only when alert and recovered telemetry tie the event to one exact recognized broker or authorized test and no descendant evidence contradicts it; preserve evidence and escalate when recovery is incomplete or evidence conflicts.
 
 
 *False positive analysis*
 
 
-- Processes related to Windows Error Reporting such as WerFault.exe and Wermgr.exe can trigger false positives. These are legitimate system processes and can be excluded by verifying their signatures and paths.
-- Logon utilities like Utilman.exe spawning processes such as osk.exe, Narrator.exe, or Magnify.exe may appear suspicious but are often legitimate. Exclude these by confirming their usage context and ensuring they are executed by trusted users.
-- Third-party software like TeamViewer, Cisco WebEx, and Dell Inc. may cause false positives due to their legitimate use of process creation. Verify the code signature and trust status to exclude these processes.
-- Windows Update processes involving MpSigStub.exe and wuauclt.exe can be mistakenly flagged. Confirm these are part of regular update activities and exclude them based on their known paths and parent processes.
-- Remote support and management tools such as LogMeIn, GoToAssist, and Chrome Remote Desktop may be flagged. Ensure these are installed and used by authorized personnel and exclude them by their executable paths.
-- Netwrix Corporation's processes like adcrcpy.exe may be flagged if they are part of legitimate auditing activities. Verify the code signature and exclude these processes if they are part of authorized Netwrix Auditor operations.
+- Signed broker cases require the exact telemetry tuple: child path, signer, and command; reported parent path; recovered creator path, signer, and command; and host/user cohort. Authorized PPID-spoofing tests require exact host, time, tester, test binary, parent PID, real creator PID, and child command line. Without that tie to one product or test, treat as suspicious because the rule already filters common Windows Error Reporting, update, accessibility, remote-support, and Netwrix patterns.
+- Build exceptions only from the minimum confirmed tuple: `process.hash.sha256` or `process.code_signature.thumbprint_sha256`, `process.executable`, `process.parent.executable`, recovered creator identity, `host.id` or managed host group, and the test or product command pattern. Avoid exceptions on `process.name`, `process.parent.name`, or signer alone.
 
 
 *Response and remediation*
 
 
-- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
-- Terminate any suspicious processes identified by the alert, especially those with spoofed PPIDs or elevated privileges, to stop potential malicious activities.
-- Review and revoke any unauthorized user accounts or privileges that may have been created or escalated during the incident.
-- Conduct a thorough forensic analysis of the affected system to identify any additional indicators of compromise or persistence mechanisms.
-- Restore the system from a known good backup if necessary, ensuring that all malicious artifacts are removed and system integrity is maintained.
-- Implement additional monitoring and logging on the affected system and network to detect any recurrence of similar activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist.
+- If confirmed benign: document the exact child, reported parent, real creator, signer, command line, host, and user evidence that proved the workflow; reverse any temporary containment and create only a narrow exception for the same tuple.
+- If suspicious but unconfirmed: preserve the alert, process event, recovered creator and descendant process records, process entity IDs and PIDs, command lines, hashes, signers, and current process state before containment. Use reversible containment such as host isolation or temporary policy controls based on host criticality; avoid killing the child or creator until evidence is preserved.
+- If confirmed malicious: isolate the affected host when identity, lineage, or descendant evidence shows unauthorized SYSTEM execution. Before termination, record `process.entity_id`, `process.parent.Ext.real.pid`, `process.command_line`, and `process.hash.sha256`; then terminate malicious child or descendant processes and remove only the binaries, scripts, services, or persistence found during follow-on investigation.
+- Reset or rotate credentials only for accounts, services, or remote-access paths whose misuse is confirmed by additional evidence. Do not treat SYSTEM context alone as proof that a named user credential was compromised.
+- Post-incident hardening: restrict administrative paths that can obtain parent-process creation privileges, review who can run PPID-spoofing test tools, and document the confirmed tuple or malicious artifact set so future analysts can separate repeated product behavior from repeated abuse.
+
+==== 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
 
@@ -152,10 +172,9 @@ process where host.os.type == "windows" and event.action == "start" and
                     "?:\\Program Files (x86)\\GoToAssist Remote Support Customer\\*\\g2ax_comm_customer.exe") and
  not (
     process.code_signature.trusted == true and process.code_signature.subject_name == "Netwrix Corporation" and
-    process.name : "adcrcpy.exe" and process.parent.executable : (
-      "?:\\Program Files (x86)\\Netwrix Auditor\\Active Directory Auditing\\Netwrix.ADA.EventCollector.exe",
-      "?:\\Program Files (x86)\\Netwrix Auditor\\Active Directory Auditing\\Netwrix.ADA.Analyzer.exe",
-      "?:\\Netwrix Auditor\\Active Directory Auditing\\Netwrix.ADA.EventCollector.exe"
+    process.name : "adcrcpy.exe" and process.parent.name : (
+      "Netwrix.ADA.EventCollector.exe",
+      "Netwrix.ADA.Analyzer.exe"
     )
  )
 
diff --git a/docs/detections/prebuilt-rules/rule-details/process-created-with-an-elevated-token.asciidoc b/docs/detections/prebuilt-rules/rule-details/process-created-with-an-elevated-token.asciidoc
index e65688c11e..44ac800fb7 100644
--- a/docs/detections/prebuilt-rules/rule-details/process-created-with-an-elevated-token.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/process-created-with-an-elevated-token.asciidoc
@@ -1,7 +1,7 @@
 [[process-created-with-an-elevated-token]]
 === Process Created with an Elevated Token
 
-Identifies the creation of a process running as SYSTEM and impersonating a Windows core binary privileges. Adversaries may create a new process with a different token to escalate privileges and bypass access controls.
+Identifies the creation of a process running as SYSTEM while impersonating the token context of a Windows core binary. Adversaries may create a new process with a different token to escalate privileges and bypass access controls.
 
 *Rule type*: eql
 
@@ -33,7 +33,7 @@ Identifies the creation of a process running as SYSTEM and impersonating a Windo
 * Data Source: Elastic Defend
 * Resources: Investigation Guide
 
-*Version*: 11
+*Version*: 12
 
 *Rule authors*: 
 
@@ -49,48 +49,67 @@ Identifies the creation of a process running as SYSTEM and impersonating a Windo
 *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 Process Created with an Elevated Token*
 
 
-In Windows environments, processes can be created with elevated tokens to perform tasks requiring higher privileges. Adversaries exploit this by impersonating system-level binaries to escalate privileges and bypass security controls. The detection rule identifies such activities by monitoring process creation events, focusing on those initiated by privileged binaries and excluding known benign processes. This helps in identifying unauthorized privilege escalation attempts.
-
-
 *Possible investigation steps*
 
 
-- Review the process creation event details to identify the specific executable and its parent process, focusing on the fields process.executable and process.Ext.effective_parent.executable.
-- Check the user.id field to confirm if the process was created with the SYSTEM user ID (S-1-5-18), indicating elevated privileges.
-- Investigate the parent process executable path to determine if it matches any known privileged Microsoft native binaries, which could be targets for token theft.
-- Examine the process code signature details, especially process.code_signature.trusted and process.code_signature.subject_name, to verify if the executable is signed by a trusted entity or if it matches any excluded signatures.
-- Correlate the process creation event with other security logs and alerts to identify any related suspicious activities or patterns that might indicate privilege escalation attempts.
-- Assess the context and timing of the event to determine if it aligns with legitimate administrative tasks or if it appears anomalous in the environment.
+- What SYSTEM token path did the alert record?
+  - Why: CreateProcessWithTokenW-style abuse creates a process in a supplied token context, so child, OS parent, and effective parent must be interpreted together.
+  - Focus: `user.id`, `process.executable`, `process.command_line`, `process.parent.executable`, and `process.Ext.effective_parent.executable`.
+  - Implication: escalate when a payload or unusual command runs as `S-1-5-18` through a Windows effective parent without one exact recognized workflow; lower suspicion only when child, OS parent, and effective parent all bind to the same vendor, update, accessibility, or test activity.
+- Does the OS parent explain why another token was used?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.code_signature.subject_name`, and lineage when needed.
+  - Implication: escalate when the parent is user-writable, script-driven, remote-tool initiated, unexpectedly signed, or unrelated to the effective parent; lower suspicion when it is a stable signed helper for the same component.
+- Is the created process identity consistent with that workflow?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, and `process.code_signature.subject_name`.
+  - Implication: escalate when the SYSTEM child has an unexpected signer, user-writable path, new hash, or PE-name mismatch; lower suspicion when signer, hash history, path, and parent context all fit the same component.
+- Does the token and session context explain the SYSTEM child?
+  - Why: CreateProcessWithTokenW, CreateProcessAsUserW, and runas-style abuse can look ordinary unless token/session context is compared with lineage.
+  - Focus: `process.Ext.authentication_id`, `process.Ext.session_info.logon_type`, `process.Ext.token.integrity_level_name`, `process.Ext.token.elevation_level`, and `user.id`.
+  - Implication: escalate when SYSTEM or full-integrity execution appears in a logon/session context disconnected from parent or effective parent; lower suspicion when token level and session type match the same service, update, accessibility, or test component.
+- Did the process tree show staging or immediate follow-on execution?
+  - Why: token reuse after the first child makes repeated SYSTEM children or fresh executable timing a scope-expansion trigger.
+  - Focus: same-`host.id` child process starts from `process.entity_id`; review child `process.executable`, `process.command_line`, `process.Ext.relative_file_creation_time`, and `process.Ext.relative_file_name_modify_time`. !{investigate{"description":"","label":"Child process starts from the SYSTEM process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if hash or relative-time values are empty, scope with `process.executable`, `process.command_line`, `process.parent.executable`, and `process.Ext.effective_parent.executable`; broaden only when local evidence stays suspicious or unresolved.
+    - !{investigate{"description":"","label":"Process events for the same token-creation pattern","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"},{"excluded":false,"field":"process.parent.executable","queryType":"phrase","value":"{{process.parent.executable}}","valueType":"string"},{"excluded":false,"field":"process.Ext.effective_parent.executable","queryType":"phrase","value":"{{process.Ext.effective_parent.executable}}","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"}}
+    - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate when the SYSTEM child launches shells, script interpreters, security tools, freshly created or renamed executables, or the same token-creation pattern on unrelated hosts; lower suspicion when descendants and recurrence stay inside the same component pattern.
+- What disposition is supported?
+  - Escalate on conflict across child command, parent/effective-parent pair, identity, token/session, or descendants. Close only when the same signed component explains all categories on this `host.id`; preserve and escalate when any element is missing or contradictory.
 
 
 *False positive analysis*
 
 
-- Utility Manager in Windows running in debug mode can trigger false positives. To handle this, exclude processes where both the effective parent and parent executables are Utilman.exe with the /debug argument.
-- Windows print spooler service correlated with Access Intelligent Form may cause false alerts. Exclude processes where the parent executable is spoolsv.exe and the process executable is LaunchCreate.exe under Access Intelligent Form.
-- Windows error reporting executables like WerFault.exe can be mistakenly flagged. Exclude these specific executables from the rule to prevent unnecessary alerts.
-- Windows updates initiated by TiWorker.exe running with elevated privileges can be misidentified. Exclude processes where TiWorker.exe is the parent and the process executable matches known update-related paths.
-- Additional parent executables that typically run with elevated privileges, such as AtBroker.exe and svchost.exe, can lead to false positives. Exclude these parent executables from the rule to reduce noise.
-- Trusted Windows binaries with specific signature names, such as those from TeamViewer or Cisco WebEx, may be incorrectly flagged. Exclude processes with a trusted code signature and matching subject names to avoid false alerts.
+- Treat this alert as unusual until alert-local process evidence proves one component expected to create a SYSTEM process from another token, such as an unexcluded vendor support or accessibility helper, updater/installer, print or error-reporting component, or authorized security test.
+- Confirm benign activity only when identity, parentage, token context, and scope all point to that component: `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.parent.executable`, `process.Ext.effective_parent.executable`, `user.id`, and `host.id`. A trusted signer, Windows path, or component label alone is insufficient.
+- Before adding an exception, validate that the exact child/parent/effective-parent pattern is stable for the same host or managed host group. Build from minimum stable fields, avoiding broad exceptions on `process.name`, `user.name`, or `?:\Windows\*.exe` alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
-- Terminate any suspicious processes identified by the detection rule that are running with elevated privileges, especially those not matching known benign processes.
-- Conduct a thorough review of user accounts and privileges on the affected system to identify and disable any unauthorized accounts or privilege escalations.
-- Restore the affected system from a known good backup to ensure any malicious changes are reverted, and verify the integrity of the system post-restoration.
-- Implement additional monitoring on the affected system and network to detect any further attempts at privilege escalation or token manipulation.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems.
-- Review and update endpoint protection and detection capabilities to ensure they are configured to detect similar threats in the future, leveraging the MITRE ATT&CK framework for guidance on Access Token Manipulation (T1134).
+- Preserve evidence first: export the alert, process tree, `process.entity_id`, `process.pid`, command lines, hashes, signer details, token/session fields, and any descendant process records before containment or process termination.
+- If suspicious but unconfirmed, preserve and scope first. Use reversible containment such as host isolation only when the SYSTEM child is still running, spawning descendants, or recurring beyond one validated workflow; otherwise keep the host connected for evidence collection while escalating.
+- If malicious activity is confirmed, contain the host, block or quarantine confirmed malicious hashes or executables, and suspend or terminate the SYSTEM child only after recording its identifiers and collecting needed memory or file evidence.
+- Eradicate only artifacts and configuration changes identified during investigation or incident response. Remediate the entry path that obtained or duplicated the token, and reset credentials only for accounts tied to confirmed misuse.
+- After recovery, document the confirmed benign workflow or malicious child/parent/effective-parent pattern, and keep any exception scoped to the stable fields that proved the case.
+
+==== 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
 
@@ -138,7 +157,6 @@ not (process.parent.executable : ("?:\\Windows\\System32\\spoolsv.exe", "?:\\Win
                             "?:\\Windows\\Microsoft.NET\\Framework*\\*\\ngen.exe",
                             "?:\\Windows\\Microsoft.NET\\Framework*\\*\\aspnet_regiis.exe")) and
 
-
 /* Ignores additional parent executables that run with elevated privileges */
  not process.parent.executable :
                ("?:\\Windows\\System32\\AtBroker.exe",
diff --git a/docs/detections/prebuilt-rules/rule-details/remote-computer-account-dnshostname-update.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-computer-account-dnshostname-update.asciidoc
index 907ba8c9cb..781c106116 100644
--- a/docs/detections/prebuilt-rules/rule-details/remote-computer-account-dnshostname-update.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/remote-computer-account-dnshostname-update.asciidoc
@@ -38,7 +38,7 @@ Identifies the remote update to a computer account's DnsHostName attribute. If t
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 214
+*Version*: 215
 
 *Rule authors*: 
 
@@ -54,47 +54,73 @@ Identifies the remote update to a computer account's DnsHostName attribute. If t
 *Triage and analysis*
 
 
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
-
 
 *Investigating Remote Computer Account DnsHostName Update*
 
 
-In Active Directory environments, the DnsHostName attribute links computer accounts to their DNS names, crucial for network communication. Adversaries may exploit this by altering a non-domain controller's DnsHostName to mimic a domain controller, potentially exploiting vulnerabilities like CVE-2022-26923 for privilege escalation. The detection rule identifies suspicious changes by monitoring for remote updates to this attribute, especially when the new hostname resembles a domain controller's, flagging potential exploitation attempts.
-
 
 *Possible investigation steps*
 
 
-- Review the event logs to confirm the occurrence of the "changed-computer-account" action, focusing on the user.id fields ("S-1-5-21-*", "S-1-12-1-*") to identify the user who initiated the change.
-- Verify the new DnsHostName value against the list of legitimate domain controller DNS hostnames to assess if it matches any known domain controllers.
-- Check the winlog.event_data.TargetUserName to ensure that the DnsHostName does not start with the computer name that was changed, which could indicate a false positive.
-- Investigate the account associated with the user.id to determine if it has a history of suspicious activity or if it has been compromised.
-- Examine recent changes or activities on the affected computer account to identify any unauthorized access or configuration changes.
-- Correlate this event with other security alerts or logs to identify potential patterns or coordinated activities that might indicate a broader attack.
+- What object, initiator, and DNS-name mismatch does the alert prove?
+  - Focus: `winlog.event_data.TargetUserName`, `winlog.event_data.TargetSid`, `winlog.event_data.DnsHostName`, `winlog.event_data.SubjectUserSid`, and `winlog.event_data.SubjectLogonId`.
+  - Implication: escalate or continue when the new DNS host name no longer matches the target computer account and points to another server namespace; lower suspicion only when target SID, subject SID, and logon session fit a recognized rename, promotion, re-binding, or authorized test.
+
+- Does the new DNS host name collide with a domain controller or other sensitive host?
+  - Why: Certifried abuse makes a controlled computer account look like a trusted host before requesting or using a machine certificate.
+  - Focus: `winlog.event_data.DnsHostName`, `winlog.event_data.TargetUserName`, `winlog.event_data.TargetDomainName`, and `winlog.computer_name`.
+  - Implication: high risk when the value matches a real domain controller, CA, or privileged server different from `winlog.event_data.TargetUserName`; lower risk only when it belongs to the same object transition and does not collide with a privileged asset.
+
+- Who made the update, and does the source/session context fit that account's role?
+  - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, `winlog.event_data.SubjectLogonId`, and `source.ip`.
+  - Implication: escalate when the subject is a standard user, non-tier-0 admin, unusual service account, machine account, or unexpected source for computer-account management; lower suspicion when subject, source when present, and logon session match a recognized AD management path.
+
+- Did the same object show SPN deletion, empty-SPN creation, or other preparation?
+  - Why: successful DNS-name spoofing often requires removing FQDN service principal names or creating a computer account without them so SPN uniqueness checks do not block the DNS update.
+  - Focus: Windows Security account-management and directory-change events for `winlog.event_data.TargetSid`, especially `event.code`, `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.AttributeValue`, and `winlog.event_data.ObjectDN`.
+  - Implication: escalate when the sequence removes servicePrincipalName values, creates or controls the computer object, or changes related attributes just before the DNS update; lower suspicion when the same change set follows a recognized promotion or re-binding path.
+
+- Did certificate-service or Kerberos activity use the spoofed identity after the update?
+  - Focus: post-alert Windows Security certificate enrollment and authentication events for `winlog.event_data.TargetUserName` or the spoofed host name, reading `event.code`, `winlog.event_data.AuthenticationPackageName`, `winlog.logon.type`, and `source.ip`.
+  - Hint: missing certificate-service or Kerberos telemetry leaves post-update use unresolved, not benign.
+  - Implication: escalate when the modified object requests or receives a machine certificate, uses Kerberos with the spoofed identity, authenticates from unexpected `source.ip` when present, or appears in privileged follow-on activity; absence of follow-on use lowers urgency only when object, initiator, and preparation evidence also align benignly.
+
+- If local evidence stays suspicious or unresolved, do related alerts show the same modifying user elsewhere?
+  - Focus: related alerts for modifying `user.id`, especially AD manipulation, certificate abuse, credential-access, or privilege-escalation alerts. !{investigate{"description":"","label":"Alerts associated with the modifying user in the surrounding window","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-2h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same user appears in more directory changes, certificate abuse, unusual authentication, or privilege escalation; keep response local only when related alerts are absent and local evidence supports one recognized workflow.
+
+- What disposition do the DNS-name mismatch, hostname collision, initiator, preparation, follow-on use, and scope support?
+  - Escalate on sensitive-host collision, suspicious initiator, SPN/object preparation, certificate/Kerberos use, or related AD abuse; close only when all evidence binds one recognized test or object-transition workflow with no contradictions; preserve evidence and escalate when answers conflict or visibility is incomplete.
 
 
 *False positive analysis*
 
 
-- Routine maintenance or updates to computer accounts may trigger the rule if the DnsHostName is temporarily set to a domain controller-like name. To manage this, create exceptions for known maintenance periods or specific administrative accounts performing these updates.
-- Automated scripts or tools that update computer account attributes might inadvertently match the rule's conditions. Identify and exclude these scripts or tools by their user IDs or specific patterns in their operations.
-- Legitimate changes in network architecture, such as the promotion of a server to a domain controller, could be flagged. Ensure that such changes are documented and create exceptions for the involved accounts or systems during the transition period.
-- Temporary testing environments where non-domain controllers are configured with domain controller-like hostnames for testing purposes can cause false positives. Exclude these environments by their specific hostnames or network segments.
-- Regularly review and update the list of known domain controller hostnames to ensure that legitimate changes in the network are not mistakenly flagged as suspicious.
+- Benign matches are uncommon because changing a computer account DNS host name to another host namespace is an AD identity anti-pattern. Authorized CVE-2022-26923 testing or patch validation explains the alert only when subject SID/logon, target SID/name, spoofed host name, event-origin controller, SPN/object-change sequence, and follow-on certificate or authentication events all match the same test scope. Without a test plan, close only when telemetry proves a bounded lab pattern; drift in initiator, hostname, or follow-on use keeps the alert suspicious.
+- Rare promotion, rename, migration, or re-binding explains the alert only when the same computer object intentionally assumes the new DNS identity, no privileged-host collision exists, and subject, target SID, new host name, controller, and bounded follow-on authentication path all align. Do not close if telemetry leaves object identity, collision, or follow-on use unresolved.
+- Build exceptions from the minimum confirmed workflow: stable `winlog.event_data.SubjectUserSid`, `winlog.event_data.TargetSid`, `winlog.event_data.TargetUserName`, `winlog.event_data.DnsHostName`, `winlog.computer_name`, and bounded follow-on `source.ip` or `event.code`. Avoid exceptions on `event.action`, `winlog.event_data.DnsHostName`, or `winlog.event_data.TargetSid` alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected computer from the network to prevent further unauthorized changes or potential exploitation.
-- Verify the legitimacy of the DnsHostName change by cross-referencing with known domain controller hostnames and authorized change requests.
-- Revert any unauthorized changes to the DnsHostName attribute to its original state to restore proper network communication and prevent misuse.
-- Conduct a thorough review of recent account activities and permissions for the user account involved in the change to identify any unauthorized access or privilege escalation attempts.
-- Escalate the incident to the security operations team for further investigation and to assess potential exploitation of CVE-2022-26923 or other vulnerabilities.
-- Implement additional monitoring on the affected system and similar systems to detect any further suspicious activities or attempts to exploit vulnerabilities.
-- Review and update access controls and permissions for computer accounts in Active Directory to ensure only authorized personnel can make changes to critical attributes like DnsHostName.
+- If confirmed benign, document the exact workflow evidence first: subject SID/logon, target SID/name, DNS host name, event-origin controller, SPN/object-change context, and bounded follow-on authentication or certificate pattern. Then reverse temporary containment. Create an exception only after the same pattern is stable enough to avoid suppressing lookalike spoofing.
+- If suspicious but unconfirmed, export the alert and surrounding Windows Security records first, preserving the target object, spoofed host name, subject identity/logon, event-origin controller, SPN/object changes, certificate/authentication events, source IPs, and related alerts. Then use reversible containment, such as restoring the prior DNS host name or temporarily disabling the modified computer account with AD owner coordination. Escalate to account or host containment only when certificate issuance, Kerberos use, or related privilege abuse shows active use.
+- If confirmed malicious, preserve the same AD object-change and follow-on authentication/certificate evidence before restoration. Disable or restore the modified computer object, reset the machine-account secret or trust path, revoke or map affected certificates when issued, and contain the modifying account and suspected source host. Use broader domain recovery only when certificate or Kerberos abuse extends beyond the single object.
+- Before final object restoration, search the same subject SID and target SID across Windows Security logs for additional DNS host name, SPN, certificate, or privilege-abuse events so scope is complete before evidence changes.
+- Post-incident hardening: apply CVE-2022-26923 domain controller and AD CS fixes, reduce ms-DS-MachineAccountQuota where feasible, restrict computer-account creation and validated writes, retain computer-account and 5136 directory-service auditing, and record the confirmed subject/target/hostname/follow-on-authentication pattern for future triage.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Audit Computer Account Management must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-computer-account-management
+
 
 ==== Rule query
 
@@ -130,7 +156,3 @@ iam where host.os.type == "windows" and event.action == "changed-computer-accoun
 ** Name: Domain Accounts
 ** ID: T1078.002
 ** Reference URL: https://attack.mitre.org/techniques/T1078/002/
-* Technique:
-** Name: Account Manipulation
-** ID: T1098
-** Reference URL: https://attack.mitre.org/techniques/T1098/
diff --git a/docs/detections/prebuilt-rules/rule-details/screenconnect-server-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/rule-details/screenconnect-server-spawning-suspicious-processes.asciidoc
index 1068513c33..f942a3b89a 100644
--- a/docs/detections/prebuilt-rules/rule-details/screenconnect-server-spawning-suspicious-processes.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/screenconnect-server-spawning-suspicious-processes.asciidoc
@@ -37,7 +37,6 @@ Identifies suspicious processes being spawned by the ScreenConnect server proces
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Initial Access
-* Tactic: Execution
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
 * Data Source: Sysmon
@@ -47,7 +46,7 @@ Identifies suspicious processes being spawned by the ScreenConnect server proces
 * Data Source: Crowdstrike
 * Resources: Investigation Guide
 
-*Version*: 210
+*Version*: 211
 
 *Rule authors*: 
 
@@ -63,47 +62,89 @@ Identifies suspicious processes being spawned by the ScreenConnect server proces
 *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 ScreenConnect Server Spawning Suspicious Processes*
 
 
-ScreenConnect, a remote support tool, allows administrators to control systems remotely. Adversaries may exploit this by executing unauthorized commands or scripts, potentially using it as a backdoor. The detection rule identifies unusual child processes like command shells spawned by the ScreenConnect service, signaling possible exploitation or web shell activity, thus aiding in early threat detection.
-
 
 *Possible investigation steps*
 
 
-- Review the alert details to confirm the parent process is ScreenConnect.Service.exe and identify the suspicious child process name, such as cmd.exe or powershell.exe.
-- Check the timestamp of the process start event to determine when the suspicious activity occurred and correlate it with any other unusual activities or alerts around the same time.
-- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised.
-- Examine the command line arguments of the spawned process to identify any malicious or unauthorized commands being executed.
-- Review network logs for any unusual outbound connections initiated by the ScreenConnect service or the suspicious child process, which may indicate data exfiltration or communication with a command and control server.
-- Analyze the system for any additional indicators of compromise, such as unexpected file modifications or the presence of web shells, to assess the extent of the potential breach.
+- Does the alert prove ScreenConnect application-server execution rather than client-side remote command use?
+  - Why: the reference separates server compromise from routine client deployment; server-side abuse uses "ScreenConnect.Service.exe", while client-side commands usually involve "ScreenConnect.ClientService.exe".
+  - Focus: alert-local `process.parent.name`, `process.parent.executable`, `process.name`, `process.pe.original_file_name`, `host.id`, and `host.name`.
+  - Implication: escalate sooner when "ScreenConnect.Service.exe" on the application server spawned "cmd.exe", PowerShell, or "csc.exe"; lower suspicion only when parent or host evidence proves this is not server-side execution, then resolve the mismatch before applying this guide.
+
+- Is the spawned child the genuine Windows tool expected by its name?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the child runs from a user-writable or ScreenConnect content path, is unsigned or untrusted, or PE metadata does not match the shell, PowerShell, or compiler name; confirmed identity says what ran, not that the launch is benign.
+
+- What intent is visible in the child command line and service context?
+  - Why: ScreenConnect server exploitation often inherits the service identity, so SYSTEM or the expected service account does not reduce risk by itself.
+  - Focus: `process.command_line`, `process.parent.command_line`, and `user.id`.
+  - Implication: escalate when the command shows encoded PowerShell, download or staging, account creation, service changes, webshell-style shell use, or "csc.exe" compiling from temporary or ScreenConnect content paths; lower suspicion only for narrow maintenance, extension, or vendor-support action and later evidence agrees.
+
+- Do ScreenConnect server artifacts corroborate authentication bypass, extension traversal, or webshell staging?
+  - Why: the reference describes CVE-2024-1709 admin-user changes in "Users.xml" and CVE-2024-1708 web-accessible ASP.NET content under "App_Extensions".
+  - Focus: if file telemetry exists, query file events on `host.id` where `process.entity_id` equals server service `process.parent.entity_id`; if absent, pivot on `host.id`, service PID, and alert time, then review `file.path` and `file.name` for "Users.xml", "App_Extensions", ASP.NET files, or extension archives. !{investigate{"description":"","label":"File events for the ScreenConnect server process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if file telemetry is unavailable or empty, inspect those server paths directly; missing file telemetry is unresolved, not benign.
+  - Implication: escalate when "Users.xml" shows an unexpected admin, "App_Extensions" contains a lone ASP.NET file, or extension content appears outside GUID-scoped folders; lower suspicion only when artifacts stay inside expected extension paths and process evidence supports the same workflow.
+
+- Did the spawned child make network connections consistent with follow-on tooling or external control?
+  - Focus: if network telemetry exists, query `host.id` and child `process.entity_id`; if absent, pivot on `host.id`, `process.pid`, and alert time, separating DNS `dns.question.name` from connection `destination.ip`, `destination.port`, and `destination.as.organization.name`. !{investigate{"description":"","label":"Network events for the spawned child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: Missing network telemetry is unresolved, not benign.
+  - Implication: escalate when the shell, PowerShell, or compiler reaches a public destination with no ScreenConnect/vendor relationship, a staging domain, or any destination inconsistent with the recovered command; lower suspicion for absent destinations only after telemetry is verified and local process/artifact evidence resolve cleanly.
+
+- Do related host alerts change scope when local findings are suspicious or unresolved?
+  - Focus: child process starts, additional children from the same ScreenConnect service parent, plus related alerts for `host.id`, especially webshell, persistence, credential-access, service-creation, or secondary-RMM alerts. !{investigate{"description":"","label":"Child process events from the suspicious child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    !{investigate{"description":"","label":"Process events from the same ScreenConnect service","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","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 response scope when the ScreenConnect server also shows exploitation, persistence, credential access, or secondary remote-access activity; keep scope local only when this alert is isolated and process, artifact, and destination evidence all resolve to one exact benign workflow.
+
+- Escalate when server-side parentage combines with suspicious child identity or command intent, or artifacts, destinations, or related alerts support compromise; close only when process evidence and recovery tie to one exact ScreenConnect maintenance, extension, or vendor-support workflow with no contradictions; preserve artifacts and escalate when evidence is mixed or visibility is incomplete.
 
 
 *False positive analysis*
 
 
-- Legitimate administrative tasks using command shells or scripting tools like cmd.exe or powershell.exe may trigger the rule. To manage this, create exceptions for known administrative scripts or tasks that are regularly executed by trusted users.
-- Automated maintenance scripts that utilize ScreenConnect for legitimate purposes can be mistaken for suspicious activity. Identify these scripts and whitelist their execution paths or specific process names to prevent false alerts.
-- Software updates or installations that require command line execution through ScreenConnect might be flagged. Document these processes and exclude them from the rule by specifying the associated process names or hashes.
-- Security tools or monitoring solutions that interact with ScreenConnect for legitimate scanning or logging purposes may inadvertently trigger the rule. Verify these tools and add them to an exception list based on their process identifiers or parent-child process relationships.
-- Training or demonstration sessions using ScreenConnect to showcase command line features could be misinterpreted as threats. Schedule these sessions and temporarily adjust the rule sensitivity or disable it during the known timeframes to avoid false positives.
+- ScreenConnect server maintenance, extension installation, or vendor troubleshooting can legitimately spawn "powershell.exe", "cmd.exe", or "csc.exe". Confirm the same workflow across child identity, signer or hash, command intent, `host.id`, `user.id`, recovered server artifacts, and destinations when network telemetry exists. Use change records or vendor cases as corroboration, not a replacement for telemetry gaps.
+- Do not treat generic administrative scripting or compile activity as benign on a ScreenConnect server. Confirm only narrow recurring service workflow: same parent path, child identity, command pattern, `user.id`, and quiet artifact or destination pattern on the same `host.id` across prior alerts or source events when external records are unavailable. One-off shells, downloaders, account changes, or root-level "App_Extensions" files remain suspicious.
+- Before creating an exception, build it from the minimum confirmed workflow pattern: `process.parent.executable`, `process.executable`, a constrained `process.command_line` pattern, stable signer or hash, `host.id`, and the specific ScreenConnect maintenance or extension context. Avoid exceptions on `process.name` or "ScreenConnect.Service.exe" alone.
 
 
 *Response and remediation*
 
 
-- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
-- Terminate any suspicious processes identified as being spawned by ScreenConnect.Service.exe, such as cmd.exe or powershell.exe, to halt any ongoing malicious activity.
-- Conduct a thorough review of recent ScreenConnect session logs to identify unauthorized access or unusual activity patterns, and revoke any compromised credentials.
-- Scan the affected system for additional indicators of compromise, such as web shells or other malware, using endpoint detection and response tools.
-- Apply security patches and updates to the ScreenConnect server and any other vulnerable applications to mitigate exploitation risks.
-- Restore the system from a known good backup if evidence of compromise is confirmed, ensuring that the backup is free from malicious artifacts.
-- Report the incident to the appropriate internal security team or external authorities if required, providing them with detailed findings and evidence for further investigation.
+- Before restriction or cleanup in suspicious cases, preserve a case export of the alert process and parent records, recovered file and network events, ScreenConnect and IIS logs around the alert time, "Users.xml", the "App_Extensions" tree, suspicious extension archives or ASP.NET files, and staged payloads.
+- If confirmed benign, reverse temporary restrictions and document evidence proving the workflow: parent and child identity, command intent, server scope, expected ScreenConnect artifacts, and expected destinations if present. Build a narrow exception only after the same workflow recurs consistently.
+- If suspicious but unconfirmed, apply reversible containment tied to the findings: restrict public access to the ScreenConnect web interface, temporarily limit egress from the affected `host.id`, or suspend a newly created ScreenConnect admin account where operationally safe. Weigh server criticality before full host isolation.
+- If confirmed malicious, preserve the artifacts above before terminating processes or deleting files. Then isolate the server or disable public exposure, remove malicious admin accounts, webshells, extensions, secondary RMM services, and other persistence found during the investigation, and rotate compromised ScreenConnect, service, or domain credentials.
+- Patch ScreenConnect to a fixed version and review whether the attacker used the server to reach managed clients or create admin or service accounts.
+- After containment, retain process, file, and network telemetry needed for future ScreenConnect investigations, restrict who can manage extensions or internet exposure, and document any telemetry gaps that limited this investigation.
+
+==== 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
 
@@ -113,7 +154,7 @@ ScreenConnect, a remote support tool, allows administrators to control systems r
 process where host.os.type == "windows" and event.type == "start" and
   process.parent.name : "ScreenConnect.Service.exe" and
   (process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe", "csc.exe") or
-  ?process.pe.original_file_name in ("Cmd.Exe", "PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE"))
+  ?process.pe.original_file_name in ("Cmd.Exe", "PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE", "csc.exe"))
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/sensitive-files-compression.asciidoc b/docs/detections/prebuilt-rules/rule-details/sensitive-files-compression.asciidoc
index 34166d4993..1eaa17d875 100644
--- a/docs/detections/prebuilt-rules/rule-details/sensitive-files-compression.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/sensitive-files-compression.asciidoc
@@ -40,7 +40,7 @@ Identifies the use of a compression utility to collect known files containing se
 * Data Source: Auditd Manager
 * Resources: Investigation Guide
 
-*Version*: 214
+*Version*: 215
 
 *Rule authors*: 
 
@@ -183,8 +183,14 @@ process.args:
       /root/.aws/config or
       /home/*/.aws/credentials or
       /home/*/.aws/config or
+      /home/*/.config/gcloud/credentials.db or
+      /home/*/.config/gcloud/access_tokens.db or
+      /home/*/.azure/credentials or
+      /root/.azure/credentials or
       /root/.docker/config.json or
       /home/*/.docker/config.json or
+      /root/.kube/config or
+      /home/*/.kube/config or
       /etc/group or
       /etc/passwd or
       /etc/shadow or
diff --git a/docs/detections/prebuilt-rules/rule-details/service-creation-via-local-kerberos-authentication.asciidoc b/docs/detections/prebuilt-rules/rule-details/service-creation-via-local-kerberos-authentication.asciidoc
index 6b0fd9a5e7..7c26638815 100644
--- a/docs/detections/prebuilt-rules/rule-details/service-creation-via-local-kerberos-authentication.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/service-creation-via-local-kerberos-authentication.asciidoc
@@ -1,7 +1,7 @@
 [[service-creation-via-local-kerberos-authentication]]
 === Service Creation via Local Kerberos Authentication
 
-Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to localhost, followed by a sevice creation from the same LogonId. This may indicate an attempt to leverage a Kerberos relay attack variant that can be used to elevate privilege locally from a domain joined user to local System privileges.
+Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to localhost, followed by service creation from the same LogonId. This may indicate an attempt to leverage a Kerberos relay attack variant that can elevate privileges locally from a domain-joined user to LocalSystem privileges.
 
 *Rule type*: eql
 
@@ -34,13 +34,12 @@ Identifies a suspicious local successful logon event where the Logon Package is
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Privilege Escalation
-* Tactic: Credential Access
 * Use Case: Active Directory Monitoring
 * Data Source: Active Directory
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 213
+*Version*: 214
 
 *Rule authors*: 
 
@@ -56,45 +55,63 @@ Identifies a suspicious local successful logon event where the Logon Package is
 *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 Service Creation via Local Kerberos Authentication*
 
 
-Kerberos is a network authentication protocol designed to provide strong authentication for client/server applications. In Windows environments, it is often used for secure identity verification. Adversaries may exploit Kerberos by relaying authentication tickets locally to escalate privileges, potentially creating services with elevated rights. The detection rule identifies suspicious local logons using Kerberos, followed by service creation, indicating possible misuse. By monitoring specific logon events and service installations, it helps detect unauthorized privilege escalation attempts.
-
-
 *Possible investigation steps*
 
 
-- Review the event logs for the specific LogonId identified in the alert to gather details about the logon session, including the user account involved and the time of the logon event.
-- Examine the source IP address and port from the logon event to confirm it matches the localhost (127.0.0.1 or ::1) and determine if this aligns with expected behavior for the user or system.
-- Investigate the service creation event (event ID 4697) associated with the same LogonId to identify the service name, executable path, and any related command-line arguments to assess if it is legitimate or potentially malicious.
-- Check for any recent changes or anomalies in the system or user account, such as modifications to user privileges, group memberships, or recent software installations, that could indicate unauthorized activity.
-- Correlate the findings with other security alerts or logs from the same timeframe to identify any patterns or additional indicators of compromise that may suggest a broader attack or compromise.
+- Do the source events show a loopback Kerberos logon followed by service creation in the same session?
+  - Why: sequence alerts merge fields; recover the 4624 and 4697 Timeline source events before interpreting grouped meaning.
+  - Focus: `winlog.computer_name`: 4624 `source.ip`, `winlog.logon.type`, `winlog.event_data.AuthenticationPackageName`, `winlog.event_data.TargetLogonId`; 4697 `winlog.event_data.SubjectLogonId`.
+  - Implication: escalate when loopback Kerberos network logon and 4697 service install share the same logon ID; lower suspicion when recovery shows no matching 4697, non-loopback source, or a different session.
+- Which identity received the elevated loopback Kerberos session?
+  - Focus: 4624 `winlog.event_data.TargetUserName`, `winlog.event_data.TargetDomainName`, `winlog.event_data.TargetUserSid`, `user.id`, and `winlog.event_data.ElevatedToken`; Subject fields are the local initiator, not the authenticated identity.
+  - Implication: escalate when the authenticated identity is an unexpected admin, service, or machine-account path for this host; lower suspicion only when the same identity and lab or deployment host cohort are recognized for this validation pattern.
+- What service did the recovered 4697 install?
+  - Focus: 4697 `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceAccount`, `winlog.event_data.ServiceStartType`, and `winlog.event_data.ServiceType`.
+  - Implication: escalate when the service uses a throwaway name, shell or script command, user-writable payload, or LocalSystem execution. Public tools may use "KrbSCM" or "UACBypassedService"; lower suspicion only when stable service metadata, account, and host cohort match the same authorized validation or owner-confirmed deployment workflow.
+- Do same-session Windows Security events show credential use, privilege activation, or additional service activity?
+  - Focus: same-host Windows Security events surrounding the sequence, keyed on `winlog.event_data.SubjectLogonId`; read 4624, 4648, and additional 4697 records. !{investigate{"description":"","label":"Windows Security events for the same logon session","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: query `winlog.computer_name` plus either recovered logon ID across the alert window first; expand only if source-event ordering is unclear.
+  - Hint: Missing authentication telemetry is unresolved, not benign.
+  - Implication: escalate when the same session shows explicit credentials or multiple service installs; keep scope local when evidence remains one recovered 4624-to-4697 chain with no contradictory activity.
+- If local evidence remains suspicious or unresolved, do related alerts show the same relay-to-service chain elsewhere?
+  - Focus: related alerts for `winlog.computer_name` in the last 48 hours that reuse the same service name or command, or show Kerberos or service-install abuse on this host. !{investigate{"description":"","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":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Hint: compare `user.id` only if the host view does not show whether one operator or account cohort is involved. !{investigate{"description":"","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"}}
+  - Implication: broaden scope when related alerts show the same host or user preparing, reusing, or expanding the service-creation chain; keep response local when related-alert review is quiet and source events already resolve the case.
+- Escalate when source recovery confirms loopback Kerberos followed by suspicious LocalSystem service creation; close only when the session, identity, service metadata, and surrounding Windows Security evidence fit one exact benign activity with corroborating owner or test records when telemetry cannot prove legitimacy; preserve and escalate when evidence is mixed.
 
 
 *False positive analysis*
 
 
-- Routine administrative tasks may trigger the rule if administrators frequently log in locally using Kerberos and create services as part of their duties. To manage this, create exceptions for known administrative accounts or specific service creation activities that are part of regular maintenance.
-- Automated scripts or software updates that use Kerberos authentication and subsequently install or update services can also generate false positives. Identify these scripts or update processes and exclude their associated logon IDs from the rule.
-- Security software or monitoring tools that perform regular checks and use Kerberos for authentication might inadvertently trigger the rule. Review the behavior of these tools and whitelist their activities if they are verified as non-threatening.
-- In environments where localhost is used for testing or development purposes, developers might log in using Kerberos and create services. Consider excluding specific development machines or user accounts from the rule to prevent unnecessary alerts.
+- Authorized exploit validation, red-team work, or security research can reproduce this rule on lab systems. Confirm the 4624-to-4697 chain, `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `user.id`, and `winlog.computer_name` match test scope and timing. Without change or test records, close only when telemetry independently proves that validation scope; mark a one-off test as non-exceptionable instead of requiring recurrence.
+- Treat loopback Kerberos plus service creation as an operational anti-pattern outside authorized validation. A deployment or support claim is benign only when owner or runbook confirmation and source events prove this exact local SCM path, stable `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceAccount`, `user.id`, `winlog.computer_name`, and no relay-prerequisite or follow-on alerts.
+- Before creating an exception, pin `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceAccount`, `user.id`, and `winlog.computer_name`, and add an expiry or test-scope constraint for one-off validation. Avoid exceptions on loopback `source.ip`, event 4624, event 4697, or Kerberos alone because those conditions are broader than the confirmed workflow.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
-- Terminate any suspicious services created during the incident to halt potential malicious activities.
-- Conduct a thorough review of the affected system's event logs, focusing on the specific LogonId and service creation events to identify the scope of the compromise.
-- Reset the credentials of the compromised user account and any other accounts that may have been accessed using the relayed Kerberos tickets.
-- Apply patches and updates to the affected system and any other systems in the network to address known vulnerabilities that could be exploited in similar attacks.
-- Implement network segmentation to limit the ability of attackers to move laterally within the network, reducing the risk of privilege escalation.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken.
+- If confirmed benign, preserve the source-event chain and service evidence that proved the authorized workflow, then reverse temporary containment. Create an exception only from the pinned workflow fields, with an expiry or test-scope constraint for one-off validation.
+- If suspicious but unconfirmed, preserve the Timeline source events, recovered logon IDs, loopback source, service metadata, and surrounding `event.code` "4648" evidence before containment. Apply reversible containment first: stop and disable the new service after evidence capture, temporarily restrict the implicated account if follow-on activity indicates active misuse, or isolate the host only when active compromise and host criticality justify interruption.
+- If confirmed malicious, preserve the service record and recovered source events, then isolate the host when feasible, disable and remove the malicious service, and reset or restrict the implicated account plus any machine-account, delegation, or certificate artifacts found during scoping. If direct response is unavailable, escalate with session IDs, service metadata, `source.ip`, `user.id`, and related-alert evidence to the team that can contain the system. Scope related hosts and identities for the same service name, service command, or loopback Kerberos pattern before cleanup.
+- Post-incident hardening: enforce LDAP signing and channel binding where possible, reduce ms-DS-MachineAccountQuota, protect privileged accounts from delegation, harden ADCS web enrollment with TLS and EPA if that path exists, and retain Windows Security logs long enough to reconstruct future 4624-to-4697 chains.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+The following Windows audit policies must be enabled to generate the events used by this rule:
+- https://ela.st/audit-logon[Audit Logon]
+- https://ela.st/audit-security-system-extension[Audit Security System Extension]
+
 
 ==== Rule query
 
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-cmd-execution-via-wmi.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-cmd-execution-via-wmi.asciidoc
index 2e1f6599ac..c012746061 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-cmd-execution-via-wmi.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-cmd-execution-via-wmi.asciidoc
@@ -47,7 +47,7 @@ Identifies suspicious command execution (cmd) via Windows Management Instrumenta
 * Data Source: Crowdstrike
 * Resources: Investigation Guide
 
-*Version*: 321
+*Version*: 322
 
 *Rule authors*: 
 
@@ -63,47 +63,86 @@ Identifies suspicious command execution (cmd) via Windows Management Instrumenta
 *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 Cmd Execution via WMI*
 
 
-Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI for lateral movement by executing commands remotely, often using cmd.exe. The detection rule identifies such activity by monitoring for cmd.exe processes initiated by WmiPrvSE.exe with specific arguments, indicating potential misuse for executing commands on remote hosts.
-
 
 *Possible investigation steps*
 
 
-- Review the process details to confirm the parent-child relationship between WmiPrvSE.exe and cmd.exe, ensuring that cmd.exe was indeed initiated by WmiPrvSE.exe.
-- Examine the command-line arguments used by cmd.exe, specifically looking for the presence of "\\\\127.0.0.1\\*" and redirection operators like "2>&1" or "1>", to understand the nature of the command executed.
-- Investigate the source and destination IP addresses involved in the WMI activity to determine if the remote host is legitimate or potentially compromised.
-- Check for any related alerts or logs from the same host or user account around the same timeframe to identify any patterns or additional suspicious activities.
-- Correlate the event with user activity logs to determine if the command execution aligns with expected user behavior or if it appears anomalous.
-- Consult threat intelligence sources to see if the command or pattern matches known adversary techniques or campaigns.
+- Does the alert-local command line match the Impacket-style WMI output-capture shape?
+  - Focus: `process.command_line` for quiet execution, stdout/stderr redirection, temp or loopback admin-share output paths, `__*` names, and "-encodehex".
+  - Implication: escalate when WMI-brokered output capture writes to temp or loopback admin-share paths; lower concern only when the same exact capture shape recurs for one recognized RMM, SCCM, backup, or helpdesk workflow on this `host.id`.
+
+- Are "cmd.exe" and "WmiPrvSE.exe" the expected binaries in the expected launch context?
+  - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.executable`, and `process.parent.command_line`.
+  - Implication: escalate when either binary is unsigned, renamed, path-abnormal, or WMI broker context does not fit a management service; Microsoft-signed binaries reduce masquerade concern but do not clear output capture.
+
+- What operation does the captured command perform?
+  - Focus: `process.command_line` for nested interpreters, discovery commands, copy/archive tools, service or scheduled-task verbs, and defense-evasion tokens.
+  - Implication: escalate when the command stages execution, changes services or tasks, performs discovery at scale, invokes secondary interpreters or LOLBins, copies payloads, or hides output; lower concern for one bounded diagnostic or inventory command.
+
+- Does the user, host, and any session metadata fit controlled WMI administration?
+  - Focus: `user.id`, `user.domain`, `host.id`, `process.Ext.session_info.logon_type`, and `process.Ext.session_info.authentication_package`.
+  - Hint: when `process.Ext.authentication_id` or session details exist, pivot to same-host Windows Security 4624/4648 and match logon/session ID to recover source workstation, source IP, and account context. Missing authentication telemetry is unresolved, not benign.
+  - Hint: if session metadata is absent, decide from recurring `user.id`, `host.id`, parent executable, command line, child lineage, and related-alert pattern; missing session metadata is unresolved, not benign.
+  - Implication: escalate when a standard user, unusual domain context, network/service session, or unexpected NTLM context drives WMI command execution on this host; lower concern when the same account, host, and parent-command pattern recur as controlled administration.
+
+- Did the WMI-launched command become a launcher for follow-on execution?
+  - Focus: child process events from `process.entity_id`, reading child `process.name`, `process.executable`, and `process.command_line`. !{investigate{"description":"","label":"Child processes from WMI launched via Cmd.exe","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"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `process.entity_id` is missing, use `host.id` plus alert `process.pid` as child `process.parent.pid` in a tight alert window; treat this as weaker than entity-linked lineage.
+  - Implication: escalate when child processes include secondary interpreters, "rundll32.exe", "regsvr32.exe", "schtasks.exe", "sc.exe", copy tools, archivers, or other LOLBins; keep scope narrower when the cmd instance exits after one bounded command and no suspicious child appears.
+
+- If local process evidence stays suspicious or unresolved, do related alerts show the same user or host in lateral-movement activity?
+  - Focus: same-`user.id` alerts that reuse WMI output-capture fragments, WMI parentage, SMB, WinRM, service-install, scheduled-task, or matching command-line patterns. !{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 user view is quiet or ambiguous, compare same-`host.id` alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same user, host, or command pattern appears in adjacent remote-execution alerts; keep the case local when related alerts are absent and the local process evidence already explains the activity.
+
+- Escalate when output capture combines with suspicious identity, command intent, session, child, or related-alert evidence; close only when exact command shape, parent, user/host scope, child lineage, and recurrence bind to one recognized workflow on this `host.id`; preserve evidence and escalate when answers conflict or remain incomplete.
 
 
 *False positive analysis*
 
 
-- Legitimate administrative tasks using WMI may trigger this rule. System administrators often use WMI for remote management, which can include executing scripts or commands. To handle this, identify and whitelist known administrative accounts or specific scripts that are regularly used for maintenance.
-- Automated scripts or software that rely on WMI for legitimate operations might also cause false positives. Review and document these processes, then create exceptions for them in the detection rule to prevent unnecessary alerts.
-- Security software or monitoring tools that utilize WMI for system checks can inadvertently match the rule's criteria. Verify these tools and exclude their specific processes or arguments from the rule to reduce noise.
-- Scheduled tasks or system updates that use WMI for execution might be flagged. Regularly review scheduled tasks and update the rule to exclude these known benign activities.
-- Internal network monitoring or testing tools that simulate attacks for security assessments may trigger alerts. Ensure these activities are logged and excluded from the rule to avoid confusion during security evaluations.
+- Remote-management, software distribution, backup, and helpdesk workflows can run "cmd.exe" through WMI and capture output to temp or loopback admin-share paths. Confirm only when parent executable, command line, `user.id`, `host.id`, process-side session context, and child behavior align with one workflow. Inventories, change records, and owner confirmation can corroborate but not replace telemetry; without them, require recurrence of the same anchors across prior alerts from this rule.
+- Bounded diagnostic WMI commands can be legitimate when an admin account runs one inventory or support command and the tree ends there. Do not close on Microsoft-signed "cmd.exe" or "WmiPrvSE.exe" alone; require exact output-capture shape, account, host scope, and no suspicious child processes to match the recognized workflow.
+- Build exceptions from the minimum confirmed pattern: stable `process.parent.executable`, specific output-capture command shape, `user.id`, and `host.id`. Avoid exceptions on `process.name`, "cmd.exe", "WmiPrvSE.exe", or temp-path fragments alone.
 
 
 *Response and remediation*
 
 
-- Isolate the affected host immediately to prevent further lateral movement and potential data exfiltration. Disconnect it from the network while maintaining power to preserve volatile data for forensic analysis.
-- Terminate any suspicious cmd.exe processes initiated by WmiPrvSE.exe to halt any ongoing malicious activities.
-- Conduct a thorough review of the affected system's WMI subscriptions and scripts to identify and remove any unauthorized or malicious entries.
-- Reset credentials for any accounts that were used in the suspicious activity to prevent further unauthorized access.
-- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
-- Enhance monitoring and logging for WMI activities across the network to detect similar threats in the future, ensuring that logs are retained for an adequate period for forensic purposes.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised.
+- If confirmed benign, reverse any temporary containment and document the command, WMI broker path, account, host, session context, child-process result, and recurrence evidence that validated the workflow. Create an exception only for that same recurring pattern.
+- If suspicious but unconfirmed, export the alert, process tree, command line, parent context, child-process lineage, temp/admin-share output path fragments, and related-alert results before containment. Apply reversible containment first, such as heightened monitoring or temporary WMI restriction for the affected account or host where business impact permits; isolate the host only if child execution, destructive command intent, or related alerts suggest active compromise.
+- If confirmed malicious, isolate the host when its role can tolerate isolation, or terminate the alerting "cmd.exe" and malicious child processes only after preserving their command lines and entity IDs. Disable or rotate the affected credentials when user/session evidence or related alerts show account misuse.
+- After containment, remove only the temp outputs, staged payloads, services, scheduled tasks, or WMI persistence changes identified during the investigation, then verify no related alerts remain for the same `user.id`, `host.id`, or `process.command_line` pattern.
+- Post-incident hardening: restrict remote WMI to recognized admin hosts and accounts, reduce local administrator exposure, and retain process telemetry that distinguishes this output-capture pattern from adjacent WinRM or SMB service-based remote execution.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/crowdstrike-integration[CrowdStrike]
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+- https://ela.st/audit-process-creation[Windows Process Creation Logs]
+
 
 ==== Rule query
 
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-execution-from-a-webdav-share.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-execution-from-a-webdav-share.asciidoc
index 6bccda8d23..32d6aae15b 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-execution-from-a-webdav-share.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-execution-from-a-webdav-share.asciidoc
@@ -1,7 +1,7 @@
 [[suspicious-execution-from-a-webdav-share]]
 === Suspicious Execution from a WebDav Share
 
-Identifies attempt to execute Windows scripts from a remote WebDav Share. Adversaries may abuse this method to evade dropping malicious files to victim file system.
+Identifies attempts to execute or invoke content from remote WebDAV shares. Adversaries may abuse WebDAV paths, public tunnels, or host@port UNC paths to run tools or scripts while reducing local staging on the victim file system.
 
 *Rule type*: eql
 
@@ -44,7 +44,7 @@ Identifies attempt to execute Windows scripts from a remote WebDav Share. Advers
 * Data Source: Crowdstrike
 * Resources: Investigation Guide
 
-*Version*: 3
+*Version*: 4
 
 *Rule authors*: 
 
@@ -68,25 +68,78 @@ Identifies attempt to execute Windows scripts from a remote WebDav Share. Advers
 *Possible investigation steps*
 
 
-- Check if the remote webdav server is autorized by the organization.
-- Check all the downloaded files from the remote server and their content.
-- Investigate the process execution chain (parent process tree) to identify the initial vector.
-- Investigate other alerts associated with the user/host during the past 5 minutes.
-- Identify the user account that performed the action and whether it should perform this kind of action.
-- Identify the target computer and its role in the IT environment.
-- Investigate what commands were run, and assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
+- Does the alert command line show direct WebDAV execution, and external delivery vs internal transfer?
+  - Focus: `process.command_line`, `process.name`, and `process.executable`; separate public tunnel or tenant paths from internal host@port UNC, "@SSL", "DavWWWRoot", or high-port paths.
+  - Implication: escalate when a script host, installer, shell, transfer tool, or net.exe points to public WebDAV content or an unrelated internal transfer host; lower concern when path maps to one recognized internal tenant, vendor, or deployment namespace for that role.
+
+- Do the launcher identity and parent lineage match that exact workflow?
+  - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.executable`, and `process.parent.command_line`.
+  - Implication: escalate when a signed utility proxies execution from a browser, Office app, chat client, archive tool, or unexplained service context. Public paths from user-facing parents suggest user delivery; internal host@port paths or net.exe share activity suggest lateral transfer. Lower concern when signer, parent, path, host, and user recur as one recognized collaboration, deployment, or support workflow; identity alone does not clear remote execution.
+
+- Did the alerting process spawn follow-on execution or share-mount activity?
+  - Focus: child or sibling process starts on `host.id` where `process.parent.entity_id` matches `process.entity_id`; check shells, downloaders, installers, schedulers, net.exe, or user-writable `process.executable` paths. !{investigate{"description":"","label":"Child process events from the WebDAV launcher","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `process.entity_id` is unavailable, use `host.id`, `process.pid`, and a tight alert-time window; PID lineage is weaker because of reuse.
+  - Implication: escalate when the launcher spawns download, install, persistence, or share-mapping tied to the same path; narrow scope when the chain ends cleanly inside one recognized workflow.
+
+- Did file telemetry show local staging or later execution from the WebDAV launch?
+  - Focus: if file telemetry exists, query `host.id` plus `process.entity_id` for `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and later starts where `process.executable` matches a written path. !{investigate{"description":"","label":"File events from the WebDAV launcher","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if WebDAV content is copied locally or to a mapped drive before execution, treat it as the same delivery chain and keep original-process scope.
+  - Range: start with the alert window; expand only after a suspicious write to confirm later execution.
+  - Implication: escalate when the chain writes scripts, installers, renamed payloads, or startup material in user-writable paths. Missing file telemetry is unresolved, not benign; direct WebDAV execution may leave few local artifacts.
+
+- Did DNS or connection telemetry confirm the WebDAV endpoint or delivery infrastructure?
+  - Focus: if network telemetry exists, separate DNS events (`dns.question.name`, `dns.resolved_ip`) from connection events (`destination.ip`, `destination.port`) for the same `host.id` and `process.entity_id`. !{investigate{"description":"","label":"Network events from the WebDAV launcher","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: use DNS lookup_result events to map `dns.resolved_ip` to later `destination.ip` before tying a domain to a connection. Missing network telemetry is unresolved, not benign.
+  - Implication: escalate when the process reaches public tunnels, rare external domains, high-port WebDAV services, or destinations unrelated to the signer and parent workflow; lower concern when the endpoint matches the command line's recognized tenant, internal share, or vendor.
+
+- If local evidence is suspicious or unresolved, do related alerts show the same WebDAV delivery or transfer pattern?
+  - Focus: related alerts for `user.id` over 48 hours, checking reused WebDAV path, launcher, destination, or follow-on artifact. !{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 user scope is quiet or ambiguous, check `host.id` for whether the path stays local or appears with other execution or download alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same path, domain, launcher, or artifact pattern appears beyond one recognized workflow; keep the case local when related-alert history is confined to that workflow.
+
+- Escalate on direct remote WebDAV execution plus suspicious launcher, lineage, child, artifact, destination, or related-alert evidence; close only when process evidence and recovery align to one exact recognized workflow; preserve and escalate when answers conflict or visibility is incomplete.
+
+
+*False positive analysis*
+
+
+- Tenant collaboration portals, internal WebDAV shares, and vendor content portals can trigger when `process.command_line` namespace, `process.parent.executable`, `process.executable`, signer, `user.id`, and `host.id` converge on one recognized workflow. Close only when telemetry shows parent, path, utility, user, and host stable across prior rule alerts and no child, artifact, or destination evidence contradicts the portal workflow. Use portal allowlists or owner records as corroboration, not substitutes.
+- Deployment or remote-support tooling can run msiexec.exe, powershell.exe, cmd.exe, or bitsadmin.exe against WebDAV-hosted packages. Confirm only when a management-agent or support-console parent, utility identity, signer, package namespace, written-artifact pattern, and host/user scope fit the same workflow. Public tunnel paths, renamed payloads, unexpected children, or one-off standard-user launches remain suspicious unless externally confirmed with no telemetry contradictions.
+- Before creating an exception, use the minimum confirmed workflow pattern: stable `process.code_signature.subject_name` or `process.executable`, `process.parent.executable`, specific `process.command_line` namespace or destination pattern, and proving `user.id` or `host.id` scope. Avoid exceptions on `process.name`, `user.name`, "@SSL", or "DavWWWRoot" alone.
 
 
 *Response and remediation*
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Isolate the involved hosts to prevent further post-compromise behavior.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
-- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
-- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
-- Review the privileges assigned to the user to ensure that the least privilege principle is being followed.
-- 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).
+- If confirmed benign, reverse temporary containment and document the command-line namespace, parent launcher, utility identity, signer, available destination or artifact evidence, and `user.id` / `host.id` scope that validated the workflow. Create an exception only after the same scoped pattern is stable across prior rule alerts.
+- If suspicious but unconfirmed, preserve the alert export, process tree, `process.entity_id`, `process.command_line`, `process.parent.command_line`, remote path, staged artifacts, and destination indicators before containment. First apply reversible containment, such as temporarily blocking the confirmed WebDAV namespace or increasing monitoring on affected `host.id` and `user.id`; avoid termination or deletion until child execution, payload staging, or repeated suspicious destinations indicate active compromise.
+- If confirmed malicious, isolate the host when feasible or terminate the alerting process after evidence capture. If identity evidence suggests account misuse, contain or reset the affected account with identity owners. If direct endpoint response is unavailable, hand off preserved process, artifact, destination, host, and user evidence to the team able to contain the host or account.
+- Block confirmed malicious domains, destination IPs, hashes, executable paths, and staged artifact paths. Review other hosts and users for the same `process.parent.executable` plus `process.command_line` plus destination pattern, then remove only staged scripts, installers, startup material, or persistence changes tied to the chain.
+- Post-incident hardening: restrict unnecessary WebDAV and WebClient usage, limit direct execution from remote shares by script hosts and installers, use application control or attack surface reduction where feasible, retain file and network telemetry for this workflow, and document variants such as mapped-drive execution, copied-local execution, and alternate script-host launchers.
+
+
+==== 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
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-execution-from-inet-cache.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-execution-from-inet-cache.asciidoc
index dbe3976d9e..7a35d7381c 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-execution-from-inet-cache.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-execution-from-inet-cache.asciidoc
@@ -37,7 +37,6 @@ Identifies the execution of a process with arguments pointing to the INetCache F
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Initial Access
-* Tactic: Command and Control
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
 * Data Source: Windows Security Event Logs
@@ -47,7 +46,7 @@ Identifies the execution of a process with arguments pointing to the INetCache F
 * Data Source: Crowdstrike
 * Resources: Investigation Guide
 
-*Version*: 212
+*Version*: 213
 
 *Rule authors*: 
 
@@ -63,47 +62,88 @@ Identifies the execution of a process with arguments pointing to the INetCache F
 *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 from INET Cache*
 
 
-The INetCache folder stores temporary internet files, which can be exploited by adversaries to execute malicious payloads delivered via WININET. Attackers may disguise malware as legitimate files cached during browsing. The detection rule identifies suspicious processes initiated from this cache, especially when launched by common file explorers, signaling potential initial access or command and control activities.
-
 
 *Possible investigation steps*
 
 
-- Review the process details to confirm the executable path and arguments match the INetCache folder pattern specified in the query.
-- Identify the parent process, such as explorer.exe, winrar.exe, 7zFM.exe, or Bandizip.exe, to determine if the process launch is consistent with typical user behavior or potentially malicious activity.
-- Check the user account associated with the process to assess if the activity aligns with the user's normal behavior or if the account may be compromised.
-- Investigate the file in the INetCache directory for known malware signatures or anomalies using antivirus or endpoint detection tools.
-- Analyze network activity from the host to identify any suspicious connections that may indicate command and control communication.
-- Correlate the event with other security alerts or logs to identify patterns or additional indicators of compromise related to the initial access or command and control tactics.
+- Did the alert execute a payload from INetCache, or did another process only reference cached content?
+  - Focus: `process.executable` and `process.command_line`, checking whether `AppData\Local\Microsoft\Windows\INetCache\IE` or `\Device\HarddiskVolume*\Users\*\INetCache\IE` is the image path, loader input, or only a document/image argument.
+  - Implication: escalate faster when the image runs from cache or feeds cached script, archive, shortcut, or DLL content to a loader; lower suspicion when the cache path is only a file argument to a recognized viewer and later lineage shows no execution.
+
+- Does identity and launch context fit a recognized file-opening, archive, or installer workflow?
+  - Focus: `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.executable`, and `process.parent.command_line`.
+  - Implication: escalate when identity, signer, path, or parent command line conflicts with Explorer/archive-manager file handling; lower suspicion only when identity and launcher context fit one coherent workflow. Identity alone does not clear cache execution.
+
+- Do launcher-scoped file events show a downloaded or disguised lure chain?
+  - Why: parent-scoped provenance distinguishes routine cache use from shortcut, archive, script, or DLL handoff.
+  - Focus: file events from the parent launcher via `process.parent.entity_id`; fallback to `host.id` plus parent PID and alert time, checking `file.path`, `file.origin_url`, `file.origin_referrer_url`, `file.Ext.windows.zone_identifier`, and `file.Ext.original.extension`. !{investigate{"description":"","label":"File events for the launcher process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when provenance shows internet delivery, deceptive extensions, shortcut-to-archive/script transitions, or renamed cache payloads. Missing file telemetry is unresolved, not benign.
+
+- Do process-scoped DNS or connection events show delivery or follow-on infrastructure?
+  - Why: network evidence separates local file-opening from remote retrieval, payload transfer, or follow-on command and control.
+  - Focus: DNS and connection events from `process.entity_id`; fallback to `host.id` plus `process.pid` and alert time, checking DNS `dns.question.name` and `dns.resolved_ip` plus connection `destination.ip` and `destination.port`. !{investigate{"description":"","label":"Network events for the executed 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"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: compare `lookup_result` DNS `dns.resolved_ip` values to connection `destination.ip` before judging infrastructure.
+  - Implication: escalate when the process reaches rare external, WebDAV-like, dotted-quad, or payload-transfer destinations that do not match file provenance; lower suspicion when destinations align with the same recognized vendor workflow. Missing network telemetry is unresolved, not benign.
+
+- Did the cached content lead to script, archive, DLL, or staged executable execution?
+  - Focus: child starts where `process.parent.entity_id` matches `process.entity_id`, checking child `process.name`, `process.executable`, and `process.command_line`. !{investigate{"description":"","label":"Child process starts from the cached-content process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if entity IDs are unavailable, use parent PID plus alert time as a weaker fallback.
+  - Implication: escalate when the chain quickly launches "cmd.exe", "powershell.exe", "rundll32.exe", "mshta.exe", "wscript.exe", "cscript.exe", or another staged executable; lower suspicion when the lineage stops at the original viewer, archiver, or installer.
+
+- If local evidence remains suspicious or unresolved after lineage review, is the same user or host part of broader delivery activity?
+  - Focus: `host.id`, `user.id`, and related alerts that repeat the same cache-path role, parent launcher, child-process family, recovered destination, or provenance pattern.
+  - Hint: pivot same-user alerts. !{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: pivot same-host alerts. !{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 containment when related alerts show the same lure or delivery pattern across the user or host; skip broadening when local evidence supports a coherent benign workflow or single-host containment.
+
+- Escalate on disguised/downloaded cache execution, loader handoff, suspicious infrastructure, or broader delivery; close only when process evidence and recovery bind one coherent benign workflow with no contradictions; when evidence is mixed or visibility incomplete, preserve artifacts and escalate.
 
 
 *False positive analysis*
 
 
-- Legitimate software updates or installations may temporarily use the INetCache folder for storing executable files. Users can create exceptions for known update processes by identifying their specific executable paths and excluding them from the rule.
-- Some browser extensions or plugins might cache executable files in the INetCache folder during normal operations. Users should monitor and whitelist these extensions if they are verified as safe and frequently trigger alerts.
-- Automated scripts or tools that interact with web content might inadvertently store executables in the INetCache folder. Users can adjust the rule to exclude these scripts by specifying their parent process names or paths.
-- Certain enterprise applications may use the INetCache folder for legitimate purposes. Users should collaborate with IT departments to identify these applications and configure exceptions based on their unique process signatures.
-- Regularly review and update the list of excluded processes to ensure that only verified and non-threatening activities are exempt from triggering alerts.
+- Browser-driven installers, vendor updaters, and archive-based delivery can launch signed helpers from cache or reference cached installer content. Confirm `process.executable`, hash/signer, parent executable/command line, `user.id`, and `host.id` align with one recognized vendor workflow, and recovered provenance/destinations do not contradict it. Without deployment records, require recurring signer or hash, parent workflow, account, and host pattern without loader children or unrelated external delivery.
+- Archive preview, document viewing, or browser-open workflows can reference cached paths without executing a cached payload. Confirm `process.command_line` uses the cache path as a document, image, or shortcut argument, the parent workflow is stable for `user.id` and `host.id`, and recovered file, network, and child-process evidence lacks `.url/.lnk`, `.cmd/.bat/.js/.hta`, archive-to-script, or DLL-loader transitions.
+- Before creating an exception, validate recurrence across prior alerts from this rule with stable `process.executable`, signer or hash, `process.parent.executable`, cache-path role, `user.id`, and `host.id`. Avoid exceptions on INetCache alone, Explorer alone, archive-manager name alone, or a user alone.
 
 
 *Response and remediation*
 
 
-- Isolate the affected system from the network to prevent further communication with potential command and control servers.
-- Terminate any suspicious processes identified as originating from the INetCache folder to halt any ongoing malicious activity.
-- Delete any malicious files found within the INetCache directory to remove the immediate threat.
-- Conduct a full antivirus and antimalware scan on the affected system to identify and remove any additional threats.
-- Review and analyze recent email logs and web browsing history to identify potential phishing attempts or malicious downloads that may have led to the initial compromise.
-- 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 the INetCache directory and related processes to detect similar threats in the future.
+- If confirmed benign, reverse temporary containment and record the process identity, command line, parent workflow, account, host, and any recovered provenance or destination evidence that proved the benign workflow. Create an exception only for the recurring signer or hash, cache-path role, parent workflow, `user.id`, and `host.id` combination.
+- If suspicious but unconfirmed, preserve `process.entity_id`, `process.command_line`, parent/child lineage, runtime hash and signer, payload files, origin/referrer URLs, DNS names, destination IPs/ports, and related alert IDs before containment. Apply reversible containment first, such as temporary destination blocking or heightened monitoring for the affected `host.id` and `user.id`; isolate only when loader execution or network evidence suggests active payload delivery or command and control.
+- If confirmed malicious, preserve the same process, file, and network artifacts before destructive action. Isolate the endpoint when host criticality permits, block confirmed malicious domains, destinations, and hashes, collect suspicious payloads, then terminate processes or delete files only after scope and evidence capture are complete.
+- Eradicate only the shortcut, script, archive, DLL, extracted payload, startup item, or persistence artifact identified during the investigation. Verify the original browser-download, archive, WebDAV-like, or cache delivery path no longer reaches the host.
+- Post-incident hardening: retain the evidence set that proved the case, review SmartScreen, Mark-of-the-Web, WebDAV, archive-handling, and web-download controls for the affected host class, and record adjacent variants such as disguised `.url` lures, archive-extracted scripts, or cache-based DLL launchers in the case notes.
+
+
+==== 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
 
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-execution-with-nodejs.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-execution-with-nodejs.asciidoc
index a40caa5432..5ec12f5110 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-execution-with-nodejs.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-execution-with-nodejs.asciidoc
@@ -1,7 +1,7 @@
 [[suspicious-execution-with-nodejs]]
 === Suspicious Execution with NodeJS
 
-Identifies suspicious execution patterns using NodeJS interpeter like process path and arguments.
+Identifies suspicious Node.js execution patterns, including user-writable runtimes, preload arguments, and inline eval, decode, or child-process usage.
 
 *Rule type*: eql
 
@@ -29,7 +29,8 @@ Identifies suspicious execution patterns using NodeJS interpeter like process pa
 
 *References*: 
 
-* https://nodejs.org
+* https://nodejs.org/api/child_process.html
+* https://nodejs.org/api/globals.html#atobdata
 
 *Tags*: 
 
@@ -46,7 +47,7 @@ Identifies suspicious execution patterns using NodeJS interpeter like process pa
 * Data Source: SentinelOne
 * Data Source: Crowdstrike
 
-*Version*: 3
+*Version*: 4
 
 *Rule authors*: 
 
@@ -62,46 +63,88 @@ Identifies suspicious execution patterns using NodeJS interpeter like process pa
 *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 with NodeJS*
 
 
-Windows scripts, often used for legitimate automation tasks, can be exploited by adversaries to execute malicious code. Attackers may download scripts via browsers or file utilities, then execute them using scripting tools like wscript or mshta. The detection rule identifies such threats by monitoring script creation from internet sources and subsequent execution, focusing on unusual parent-child process relationships and script attributes.
-
 
 *Possible investigation steps*
 
 
-- Analyze the execution event of the scripting utility (node.exe) to identify the command-line arguments used, which may provide insight into the script's intended actions.
-- Review node.exe network, files and child process events for any suspicious activity.
-- Verify parent and grand parent processes to assess persence of persistence and the potential initial vector.
-- Check the user account associated with the script execution to determine if the activity is expected for that user or if it indicates a compromised account.
-- Look for any additional related alerts or logs on the host that might indicate further malicious activity or lateral movement following the script execution.
+- 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 user-writable AppData "node.exe", 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*
 
 
-- Legitimate script automation tools may trigger this rule if they download and execute scripts from the internet. Users can create exceptions for known safe tools by excluding specific file paths or process names.
-- Software updates or installations that download scripts as part of their process might be flagged. To handle this, users can whitelist specific origin URLs or referrer URLs associated with trusted software vendors.
-- Internal scripts distributed via corporate intranet sites could be misidentified as threats. Users should consider excluding scripts with known internal origin URLs or specific user IDs associated with IT operations.
-- Browser extensions or plugins that automate tasks using scripts may cause false positives. Users can exclude these by identifying and excluding the specific browser process names or file extensions involved.
-- Frequent use of file utilities like winrar or 7zFM for legitimate script handling can be excluded by specifying trusted file paths or user IDs that regularly perform these actions.
+- 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*
 
 
-- Isolate the affected system from the network to prevent further execution of potentially malicious scripts and lateral movement.
-- Terminate any suspicious processes identified in the alert, such as wscript.exe or mshta.exe, to stop the execution of the downloaded script.
-- Quarantine the downloaded script file and any associated files to prevent further execution and facilitate forensic analysis.
-- 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 files or remnants.
-- Review and analyze the origin URL and referrer URL of the downloaded script to identify potential malicious websites or compromised sources, and block these URLs at the network level.
-- 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 application whitelisting to restrict the execution of unauthorized scripts and scripting utilities, reducing the risk of similar threats in the future.
+- 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
 
@@ -113,7 +156,7 @@ 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") and
 
 (
-  (process.executable : ("?:\\Users\\*\\AppData\\*\\node.exe", "\\Device\\HarddiskVolume?\\\\Users\\*\\AppData\\*\\node.exe") and process.args : "*.js") or
+  (process.executable : ("?:\\Users\\*\\AppData\\*\\node.exe", "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\*\\node.exe") and process.args : "*.js") or
 
   (process.args : "-r" and process.parent.name : "powershell.exe") or
 
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-file-renamed-via-smb.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-file-renamed-via-smb.asciidoc
index e0bac745a2..7a3f917e39 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-file-renamed-via-smb.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-file-renamed-via-smb.asciidoc
@@ -33,7 +33,7 @@ Identifies an incoming SMB connection followed by a suspicious file rename opera
 * Resources: Investigation Guide
 * Data Source: Elastic Defend
 
-*Version*: 7
+*Version*: 8
 
 *Rule authors*: 
 
@@ -50,48 +50,65 @@ Identifies an incoming SMB connection followed by a suspicious file rename opera
 
 
 
-*Performance*
-
-
-- This rule may cause medium to high performance impact due to logic scoping all icoming SMB network events.
+*Investigating Suspicious File Renamed via SMB*
 
 
 *Possible investigation steps*
 
 
-- Investigate the source.ip address connecting to port 445 on this host.
-- Identify the user account that performed the file creation via SMB.
-- If the number of files is too high and source.ip connecting over SMB is unusual isolate the host and block the used credentials.
-- Investigate other alerts associated with the user/host during the past 48 hours.
+- What do the Timeline member events show for the SMB-to-rename sequence?
+  - Focus: use `host.id` as target context; open Investigate in Timeline to recover accepted SMB `source.ip`, rename-event `user.id`, and representative renamed `file.path`.
+  - Implication: escalate on one remote SMB source followed by repeated high-entropy user-file renames; lower concern only when member events show one bounded remote file-management job with stable source, account, path, and extension mapping. Missing member events are unresolved, not benign.
+- Does the recovered source/account pair fit a recognized remote file-management workflow?
+  - Focus: recovered `source.ip`, `user.id`, `user.name`, and `user.domain`.
+  - Implication: escalate when a rare source or privileged account remotely renames user data; lower concern when the same source/account pair recurs as a backup, migration, DLP, or conversion actor for this exact share.
+- Do rename artifacts look like encryption instead of content conversion?
+  - Focus: same target host, SMB-server context, alert window, and recovered `user.id`: `file.Ext.original.extension`, `file.extension`, `file.Ext.entropy`, and `file.size`.
+  - Implication: escalate when common documents or images move to one unfamiliar high-entropy extension family across many paths; lower concern when before/after extensions and file sizes match a recognized converter, archive, or quarantine workflow.
+- How far did the rename burst spread on the target host?
+  - Focus: file rename events from the same target host, SMB-server context, recovered `user.id`, and surrounding window; compare `file.path` roots and `file.Ext.original.extension` families.
+  - Implication: escalate when the burst crosses user profiles, share roots, or document families; lower urgency when it stays a short bounded task in one managed folder with stable extension mapping.
+- Did the target receive ransom-note or payload files around the rename burst?
+  - Why: SMB ransomware may run from the remote source while leaving note or helper files on the target share, making target-side file artifacts decisive corroboration.
+  - Focus: file events on the same `host.id` around the rename window: repeated `file.name`, `file.path`, or `file.extension` patterns for note-like files, scripts, or executables. !{investigate{"description":"","label":"Recent file activity on this host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when repeated note-like names or executable/script drops appear in impacted paths; lower concern when file activity stays limited to the explained rename workflow.
+- Did recovery inhibition or destructive behavior align with the rename burst?
+  - Focus: related alerts on the same `host.id` around the rename window naming recovery inhibition, destructive file activity, or ransomware notes. !{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: escalate and prioritize containment when these alerts align; absence reduces urgency only after source/account and rename evidence fit one exact workflow.
+- If local findings remain suspicious or unresolved, does the same SMB source or account drive similar renames elsewhere?
+  - Focus: across hosts, look for the same recovered `source.ip` or `user.id` paired with inbound SMB accept events and high-entropy rename bursts using the suspicious `file.extension`.
+  - Implication: broaden containment when the same source or account drives similar user-file rename bursts on other hosts; keep scope local only when this pivot is quiet and local evidence is otherwise resolved.
+- Escalate when SMB source/account, rename shape, target breadth, note/payload artifacts, recovery-inhibition alerts, or cross-host spread show remote encryption or destructive file handling over SMB. Close only when recovered telemetry binds one exact backup, migration, DLP, or conversion job on this host, with owner or change records as corroboration only. Preserve evidence and escalate when telemetry is mixed, incomplete, or contradicted.
 
 
 *False positive analysis*
 
 
-- Remote file rename over SMB.
+- Backup, migration, DLP quarantine, or document-conversion tooling can rename many files over SMB. Confirm that recovered `source.ip`, `user.id`, managed `file.path` scope, extension mapping, and absence of note/payload or recovery-inhibition evidence all support the same workflow on this host. Use owner confirmation or change records only as corroboration; if unavailable, close only when recovered events independently bind one exact workflow.
+- Treat recurrence of the same source/account, folder scope, and extension mapping across prior alerts as candidate tuning evidence, not a standalone benign verdict. Build exceptions from the narrowest stable pattern: recovered `source.ip`, `user.id`, managed `file.path` scope, host cohort, and extension mapping. Do not except on SMB activity, `process.pid` 4, high entropy, rename volume, or one extension alone.
 
 
-*Related rules*
+*Response and remediation*
 
 
-- Third-party Backup Files Deleted via Unexpected Process - 11ea6bec-ebde-4d71-a8e9-784948f8e3e9
-- Volume Shadow Copy Deleted or Resized via VssAdmin - b5ea4bfe-a1b2-421f-9d47-22a75a6f2921
-- Volume Shadow Copy Deletion via PowerShell - d99a037b-c8e2-47a5-97b9-170d076827c4
-- Volume Shadow Copy Deletion via WMIC - dc9c1f74-dac3-48e3-b47f-eb79db358f57
-- Potential Ransomware Note File Dropped via SMB - 02bab13d-fb14-4d7c-b6fe-4a28874d37c5
+- If confirmed benign, reverse temporary containment and document the source host, account, managed folder scope, and extension mapping that explained the rename burst. Create an exception only after the same bounded pattern recurs.
+- If suspicious but unconfirmed, preserve a Timeline export of the sequence member events, representative renamed files, any note or payload files, recovered SMB source/account details, and related alert IDs before containment that could alter evidence.
+- Apply reversible containment first: block SMB from the recovered source, suspend the recovered account session, or temporarily restrict write access to the impacted share. Isolate the source or target host only when active renaming or destructive corroborators show ongoing ransomware activity.
+- If confirmed malicious, isolate the source and impacted target or file server when the environment can tolerate it, disable and reset the recovered account, and stop active SMB sessions only after recording the source, account, renamed-file set, notes or payloads, and destructive alerts.
+- Review other hosts for the same `source.ip`, `user.id`, suspicious extension, or note pattern before restoration so the full ransomware scope is understood.
+- Restore renamed or encrypted files only from trusted backups or replicas after scope is complete, and verify backup repositories were not touched by the same source or account.
+- Post-incident hardening: restrict remote SMB write paths and administrative shares, require MFA or equivalent controls for remote access and high-privilege accounts, protect backup credentials, and retain file and network telemetry needed to recover future SMB rename sequences.
 
+==== Setup
+
+
+
+*Setup*
 
-*Response and remediation*
 
+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.
 
-- Initiate the incident response process based on the outcome of the triage.
-- Consider isolating the involved host to prevent destructive behavior, which is commonly associated with this activity.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
-- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities.
-- If any backups were affected:
-  - Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.).
-- 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 instructions: https://ela.st/install-elastic-defend
 
 
 ==== Rule query
@@ -108,7 +125,7 @@ sequence by host.id with maxspan=1s
   event.action == "rename" and process.pid == 4 and user.id : ("S-1-5-21*", "S-1-12-*") and
   file.extension != null and file.Ext.entropy >= 6 and file.path : "C:\\Users\\*" and
   file.Ext.original.name : ("*.jpg", "*.bmp", "*.png", "*.pdf", "*.doc", "*.docx", "*.xls", "*.xlsx", "*.ppt", "*.pptx", "*.lnk") and
-  not file.extension : ("jpg", "bmp", "png", "pdf", "doc", "docx", "xls", "xlsx", "ppt", "pptx", "*.lnk")] with runs=3
+  not file.extension : ("jpg", "bmp", "png", "pdf", "doc", "docx", "xls", "xlsx", "ppt", "pptx", "lnk")] with runs=3
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-imagepath-service-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-imagepath-service-creation.asciidoc
index e18a956363..dc5935e4a1 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-imagepath-service-creation.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-imagepath-service-creation.asciidoc
@@ -33,7 +33,6 @@ Identifies the creation of a suspicious ImagePath value. This could be an indica
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Persistence
-* Tactic: Defense Evasion
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
 * Data Source: Sysmon
@@ -42,7 +41,7 @@ Identifies the creation of a suspicious ImagePath value. This could be an indica
 * Data Source: Crowdstrike
 * Resources: Investigation Guide
 
-*Version*: 314
+*Version*: 315
 
 *Rule authors*: 
 
@@ -58,47 +57,86 @@ Identifies the creation of a suspicious ImagePath value. This could be an indica
 *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 ImagePath Service Creation*
 
 
-Windows services are crucial for running background processes. Adversaries exploit this by creating or modifying services with malicious ImagePath values to gain persistence or escalate privileges. The detection rule monitors registry changes to ImagePath entries, flagging unusual patterns like command shells or named pipes, which are often used in stealthy attacks. This helps identify and mitigate potential threats early.
-
 
 *Possible investigation steps*
 
 
-- Review the registry event logs to identify the specific ImagePath value that triggered the alert, focusing on entries with command shells or named pipes, such as those containing "%COMSPEC%*" or "*\\.\\pipe\\*".
-- Investigate the associated service name and description in the registry path "HKLM\\SYSTEM\\ControlSet*\\Services\\*\\ImagePath" to determine if it is a legitimate service or potentially malicious.
-- Check the creation or modification timestamp of the suspicious ImagePath entry to correlate with other system events or user activities around the same time.
-- Analyze the parent process and user account responsible for the registry change to assess if it aligns with expected behavior or if it indicates unauthorized access.
-- Search for related network activity or connections, especially those involving named pipes, to identify any lateral movement or data exfiltration attempts.
-- Cross-reference the alert with threat intelligence sources to determine if the ImagePath value or associated service is linked to known malware or adversary techniques.
+- What exact service "ImagePath" behavior did the alert preserve?
+  - Why: shell and pipe-backed service launches require different execution pivots.
+  - Focus: `registry.path`, `registry.key`, `registry.value`, `registry.data.type`, `registry.data.strings`.
+  - Implication: escalate when the value invokes the command interpreter, chains shell commands, or points to a local named pipe instead of a normal service executable; lower concern only when exact key and value match a recognized same-product service wrapper.
+
+- Who wrote the service value, and does that context fit service management?
+  - Focus: `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `user.id`.
+  - Hint: if the writer is "svchost.exe" or another broker, use `process.parent.executable` and broader lineage before attributing intent. !{investigate{"description":"","label":"Activity from this writer 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":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate for unsigned utilities, script hosts, remote-admin tools, unusual paths, or user contexts that do not fit service changes; lower concern only when signer, path, command line, and user fit a recognized installer or management agent.
+
+- Did the same writer change other values under the service key?
+  - Why: existing-service edits can preserve trust while changing start mode, account context, DLL loading, failure behavior, or security descriptor.
+  - Focus: same-`host.id` registry events scoped by service `registry.key`, reviewing `registry.value` and `registry.data.strings`. !{investigate{"description":"","label":"Registry events for the same service key","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"registry.key","queryType":"phrase","value":"{{registry.key}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when surrounding values make the service autostart, run privileged, load a DLL/parameter path, restart on failure, or become harder to enumerate; lower concern when the writer performs only one bounded product-owned service update.
+
+- Did the service path execute or spawn follow-on activity?
+  - Focus: later same-`host.id` process events where `process.executable` or `process.command_line` matches the recovered service value, plus `process.parent.executable` and lineage. !{investigate{"description":"","label":"Process starts on the host near the service change","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Range: start with the alert window; expand after `@timestamp` only to test delayed service start.
+  - Hint: for command-interpreter paths, search "cmd.exe" and recovered command fragments in `process.command_line`; for named-pipe paths, search "services.exe" lineage, helpers, or service-start failures instead of expecting a file-backed executable.
+  - Implication: escalate when service lineage launches a shell, pipe helper, or unexpected child soon after the write; do not close solely because execution is not visible, since the service may start later or fail during launch.
+
+- If execution occurred, does the launched process fit the expected service?
+  - Focus: recovered launch event: `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.pe.original_file_name`, `process.Ext.relative_file_creation_time`.
+  - Implication: escalate when the binary is unsigned, newly created, renamed, PE-mismatched, or unrelated to the writer signer; lower concern when identity, signer, age, and service value all fit the same recognized product.
+
+- What disposition do service value, writer, adjacent values, execution, and related alerts support?
+  - Hint: if local evidence remains suspicious or unresolved, review user- and host-scoped alerts.
+    - !{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: escalate when shell or named-pipe execution plus writer, adjacent value, execution, or alert context fails to fit one recognized workflow; close only when those categories converge on the exact service-management activity, using outside confirmation when telemetry cannot prove legitimacy; if evidence is mixed or incomplete, preserve registry and process evidence and escalate.
 
 
 *False positive analysis*
 
 
-- Legitimate software updates or installations may modify ImagePath values, triggering alerts. Users can create exceptions for known software update processes to reduce noise.
-- System administrators might intentionally change service configurations for maintenance or optimization. Document and exclude these planned changes to prevent false positives.
-- Some enterprise applications use named pipes for inter-process communication, which could be flagged. Identify and whitelist these applications to avoid unnecessary alerts.
-- Security tools or scripts that automate service management might alter ImagePath values. Ensure these tools are recognized and excluded from monitoring to minimize false alerts.
-- Regularly review and update the list of exceptions to ensure they align with current organizational practices and software environments.
+- Software installation, repair, agent upgrade, remote-support, or deployment tooling can rewrite service "ImagePath" values or register short-lived helper services only when a signed installer, management component, vendor behavior, or internal test plan owns the service end-to-end. Confirm `process.executable`, signer/trust, `user.id`, `registry.key`, `registry.data.strings`, and later parent/command-line activity align with that workflow, not an ad hoc shell or pipe helper.
+- Shell or pipe "ImagePath" behavior is an anti-pattern unless the vendor or test plan accounts for that exact helper. Without records, require current-case telemetry that writer, signer, service key/value, `user.id`, `host.id`, later execution, and related alerts align without contradiction.
+- Before creating an exception, use prior alerts only to prove exception stability, not to close the case. Validate consistent service value, writer, user, host, and execution behavior across the same workflow. Treat a first occurrence as a candidate exception, not a suppression. Build the exception from the minimum confirmed pattern: writer signer and path, exact service key, exact `registry.data.strings`, `user.id`, and `host.id`. Avoid exceptions on `registry.value` = "ImagePath", "services.exe", or the rule name alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Terminate any suspicious processes associated with the identified ImagePath values, such as those involving command shells or named pipes.
-- Remove or disable the malicious service by reverting the ImagePath registry entry to its legitimate state or deleting the service if it is not required.
-- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats or malware.
-- Review and restore any modified system files or configurations to their original state to ensure system integrity.
-- 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 similar registry changes and suspicious service creations to detect and respond to future threats promptly.
+- If confirmed benign, preserve the case export and document the writer identity, exact service key and value, affected `user.id` and `host.id`, and later service-start behavior that proved the recognized workflow before reversing temporary containment. Keep any exception narrow and require recurrence of the same workflow pattern.
+- If suspicious but unconfirmed, preserve a case export of the triggering registry event, exact service key/value, writer process details, launched-process details, and volatile service state before containment. Then apply reversible containment tied to those findings, such as disabling the affected service, preventing the referenced command from starting, or isolating the host only after weighing service criticality. Escalate to account or broader host action only when related alerts or later execution show wider compromise.
+- If confirmed malicious, preserve the same registry and process evidence before destructive action. Disable and remove the malicious or hijacked service, restore the expected "ImagePath", quarantine the referenced executable or command artifact when present, and review the same `process.entity_id`, `registry.key`, and service lineage for additional unauthorized service changes before cleanup. Use endpoint response tooling to contain the host or terminate the recovered malicious process when available; if direct response is unavailable, escalate with the preserved identifiers to the team that can act.
+- After containment, review other hosts for the same `registry.data.strings`, service-key pattern, signer, hash, or command fragment before deleting artifacts, then verify that no additional services reference the same shell, named pipe, or staged payload.
+- Post-incident hardening: restrict service creation and service-registry writes to trusted installers and management tools, retain registry and process telemetry needed to correlate "ImagePath" changes to later execution, and record any adjacent service-abuse variant surfaced during 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/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events]
+
 
 ==== Rule query
 
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-javascript-execution-via-deno.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-javascript-execution-via-deno.asciidoc
index fc231993fb..83471ebe56 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-javascript-execution-via-deno.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-javascript-execution-via-deno.asciidoc
@@ -46,7 +46,7 @@ Detects execution of JavaScript via Deno with suspicious command-line patterns (
 * Data Source: Elastic Endgame
 * Data Source: Windows Security Event Logs
 
-*Version*: 3
+*Version*: 4
 
 *Rule authors*: 
 
@@ -66,28 +66,83 @@ Detects execution of JavaScript via Deno with suspicious command-line patterns (
 *Investigating Suspicious JavaScript Execution via Deno*
 
 
-Deno is a legitimate JavaScript/TypeScript runtime. This rule fires when a Deno process (identified by name, PE original filename, or code signer "Deno Land Inc.") is started with a command line matching suspicious patterns: javascript with base64, eval(, http, or javascript import. Such patterns are commonly used to run inline or remote scripts and can indicate abuse.
-
 
 *Possible investigation steps*
 
 
-- Review process.command_line and process.args to see the exact script or URL being executed.
-- Identify the parent process and how Deno was launched (user, script, terminal, or other tool).
-- Check whether Deno is approved on the host; if not, treat as potential unauthorized software execution.
-- Correlate with file creation or network events around the same time (downloads, script drops).
+- What execution mode and permission scope did Deno use?
+  - Focus: `process.command_line`: inline `eval(`, `data:application/javascript;base64`, remote `http` / `https`, inline JavaScript `import`, local `.js` / `.ts` targets, and broad `-A` or `--allow-*` flags.
+  - Implication: escalate faster when inline/base64 code or remote-code strings pair with broad permissions; lower concern only for a stable local task with narrow permissions. Treat `http` alone as unresolved until later evidence shows import, callback, or benign package retrieval.
+
+- Is the runtime the expected Deno binary and path?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted` for `Deno Land Inc.`, portable copies, renamed binaries, or user-writable paths.
+  - Implication: escalate when identity, signer, path, or hash history suggests a renamed or opportunistic runtime; lower concern when signed path and hash history match a managed install. Runtime identity never clears suspicious arguments.
+
+- Does launch lineage fit development/build or social-engineered execution?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, `host.name`, and child recovery; separate terminals, IDEs, and CI runners from VBS, PowerShell, MSI, browser, chat, or document launchers.
+  - Implication: escalate when Deno follows a script host, installer, browser, chat client, or document process on a non-developer endpoint; lower concern when user, host, parent, and command pattern match a recognized developer, build, or lab host.
+
+- Did Deno start follow-on processes?
+  - Focus: child events from `process.entity_id`; if absent, use `host.id`, `process.parent.pid`, and a tight alert window. Review child `process.executable`, `process.command_line`, and `process.hash.sha256`. !{investigate{"description":"","label":"Child process events from Deno","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when Deno spawns shells, downloaders, installers, schedulers, PsExec-like tools, `klist`, or other utilities; keep scope narrower when the tree ends at Deno and no suspicious child process appears.
+
+- Do DNS/network destinations fit the Deno command mode?
+  - Focus: DNS/network events for `process.entity_id`; if absent, use `host.id`, `process.pid`, and a tight alert window. Review `dns.question.name`, `dns.resolved_ip`, `destination.ip`, and `destination.port`. !{investigate{"description":"","label":"Network events from Deno","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: separate DNS lookups from connections, then map `dns.resolved_ip` to `destination.ip` before judging module source/callback fit.
+  - Implication: escalate when Deno reaches rare user/host domains, public hosting, new module sources, S3-like staging, or polling/C2 endpoints unrelated to the task; lower concern when traffic stays with recognized internal registries, package mirrors, or vendor services. Missing network telemetry is unresolved, not benign.
+
+- Did Deno stage scripts, modules, or persistence artifacts?
+  - Focus: file events for `process.entity_id`; if absent, use `host.id`, `process.pid`, and a tight alert window. Review `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and later `process.executable` reuse of written paths. !{investigate{"description":"","label":"File events from Deno","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Range: start with the alert window; after the first suspicious write, check later execution of that artifact.
+  - Implication: escalate when Deno writes scripts, binaries, cache content, or startup material into user-writable or persistence paths, or provenance shows internet delivery; lower concern when artifacts stay inside a recognized source tree, build workspace, or Deno cache expected for the command. Missing file telemetry is unresolved, not benign.
+
+- Do related alerts change scope?
+  - Focus: related alerts for the same `user.id` in 48 hours; compare Deno path, parent launcher, command mode, permission flags, and module or destination pattern. !{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 user scope is quiet or ambiguous, compare related alerts for the same `host.id` in 48 hours to see whether the pattern stays local or recurs in execution alerts. !{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 response when the same Deno path, flags, launcher, or remote-code pattern appears in other suspicious alerts; keep the case local only when local evidence fits one recognized workflow and alert history does not contradict it.
+
+- Escalate for broad permissions, abnormal lineage, follow-on execution, remote code retrieval, staging, repeated delivery, or related-alert expansion; close only when all evidence binds to one recognized developer, build, or lab workflow; preserve evidence and escalate on conflict or incomplete visibility.
 
 
 *False positive analysis*
 
 
-- Legitimate development or automation that runs Deno with eval, http imports, or base64-encoded snippets may trigger; allowlist by host or command-line pattern where appropriate.
+- Developer workstations and CI/build runners can legitimately use Deno. Confirm only when runtime identity, parent launcher, command/permission scope, and available DNS/network evidence align with the same repository, package registry, internal module host, or build workflow, with no suspicious child process or off-workspace artifact. Require available repository metadata, build definitions, or developer-host inventory; without them, do not close on recurrence alone. Use prior alerts only after alert-local and recovered evidence bind activity to one exact workflow, and require outside confirmation where telemetry cannot prove it.
+- Authorized lab or automation testing can use inline eval, remote imports, or data URLs, but should stay on lab/automation hosts with bounded permissions. Confirm only when broad `-A` or `--allow-all` is absent or test-harness-justified, the parent launcher fits that lab, file/network evidence shows no callback or staging, and `user.id` or `host.id` scope explains the activity.
+- Build exceptions from the minimum confirmed workflow: stable `process.executable` or `process.code_signature.subject_name`, `process.parent.executable`, exact `process.command_line` permission/import pattern, and proven `user.id` or `host.id` scope. Avoid exceptions on `process.name`, `user.name`, `deno.exe`, signer, or broad permission flags alone.
 
 
 *Response and remediation*
 
 
-- If abuse is confirmed: contain the host, terminate the Deno process, and remove or block Deno if not authorized; investigate how the script was delivered and scope for similar activity.
+- If confirmed benign, reverse temporary containment and record evidence proving the workflow: runtime identity, command mode and permissions, parent launcher, `user.id` / `host.id` scope, and available destination or artifact evidence. Create an exception only after that same narrow workflow recurs across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve the alert document, process tree, exact command line, parent and child process events, Deno cache/workspace artifacts, and available file/DNS/network records before containment. Apply reversible containment first: temporary blocking of the confirmed module or callback destination, heightened monitoring on affected `host.id` and `user.id`, or host isolation only when follow-on execution, payload staging, or repeated suspicious destinations indicate active compromise and asset tolerates isolation.
+- If confirmed malicious, isolate the host when operationally tolerable or terminate Deno only after preserving volatile process evidence. Block confirmed malicious domains, IPs, hashes, executable paths, and staged artifact paths; then review hosts/users for the same parent launcher, Deno command mode, permission pattern, and destination set before removing staged scripts, unauthorized Deno runtimes, startup material, scheduled tasks, or persistence tied to the chain.
+- Post-incident hardening: restrict Deno to recognized developer, build, and lab hosts; review whether `-A` or broad `--allow-*` permissions are necessary; retain process plus file/network telemetry needed for triage; and record adjacent variants such as `data:` URLs, remote `https:` imports, `npm:` / `jsr:` modules, and Deno launched from script hosts with the case outcome.
+
+
+==== 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
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-kerberos-authentication-ticket-request.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-kerberos-authentication-ticket-request.asciidoc
index df1663f2b6..5809553bb4 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-kerberos-authentication-ticket-request.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-kerberos-authentication-ticket-request.asciidoc
@@ -27,6 +27,7 @@ Correlates network connections to the standard Kerberos port by an unusual proce
 
 * https://github.com/its-a-feature/bifrost
 * https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768
+* https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769
 
 *Tags*: 
 
@@ -34,7 +35,6 @@ Correlates network connections to the standard Kerberos port by an unusual proce
 * Domain: Identity
 * OS: Windows
 * Use Case: Threat Detection
-* Tactic: Credential Access
 * Tactic: Lateral Movement
 * Use Case: Active Directory Monitoring
 * Data Source: Active Directory
@@ -43,7 +43,7 @@ Correlates network connections to the standard Kerberos port by an unusual proce
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 4
+*Version*: 5
 
 *Rule authors*: 
 
@@ -63,43 +63,88 @@ Correlates network connections to the standard Kerberos port by an unusual proce
 *Investigating Suspicious Kerberos Authentication Ticket Request*
 
 
-Kerberos is the default authentication protocol in Active Directory, designed to provide strong authentication for client/server applications by using secret-key cryptography.
 
-Domain-joined hosts usually perform Kerberos traffic using the `lsass.exe` process. This rule detects the occurrence of traffic on the Kerberos port (88) by processes other than `lsass.exe` to detect the unusual request and usage of Kerberos tickets.
+*Possible investigation steps*
 
 
-*Possible investigation steps*
+- Which Timeline member events define this Kerberos sequence?
+  - Focus: Timeline members keyed by alert `source.ip` and `source.port`; recover source `process.executable`, Kerberos `destination.ip`, and auth `event.code`.
+  - Hint: record `host.id` and `process.entity_id`; verify auth `winlog.computer_name` is the DC.
+  - Implication: escalate when one non-"lsass.exe" source process maps to a DC "4768" or "4769" event in the sequence window; lower concern for socket reuse, a different process, or non-DC destination.
+
+- Is the recovered source process a recognized Kerberos-capable client?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Hint: open process start with recovered `host.id` and `process.entity_id`; if absent, use `host.id`, `process.pid`, and sequence window.
+  - Implication: escalate when the binary is unsigned, renamed, user-writable, signer-mismatched, or outside known AD audit, Kerberos diagnostic, or security-test tooling; lower concern only when path, signer, hash history, command, and parent converge on one known tool.
+
+- Does command-line and parentage show ticket-tool intent?
+  - Focus: recovered `process.command_line`, `process.parent.executable`, `process.parent.command_line`, and broader process lineage when needed.
+  - Implication: escalate on Bifrost-like verbs or flags such as asktgt, asktgs, s4u, ptt, kerberoast, service/SPN targets, hashes, keytabs, RC4, or base64 tickets, especially from shell or script parents; bounded diagnostics from a recognized admin tool reduce but do not clear concern.
+
+- Which ticket path and target account did the DC member event show?
+  - Focus: recovered auth `event.code`, `winlog.event_data.TargetUserName`, and `winlog.event_data.TargetDomainName`.
+  - Implication: escalate when "4769" shows service-ticket activity or "4768" shows TGT handling for privileged, service, machine, or delegation-sensitive targets from the unusual process; fan-out increases concern.
+
+- Does the source user and session context fit one bounded admin or audit source?
+  - Focus: recovered `user.id`, `user.name`, `user.domain`, and `winlog.event_data.TargetUserName`.
+  - Implication: escalate when privileged, service, or user-account tickets originate from a workstation, user session, or non-management tool; lower concern only when source host, user, process identity, command/parent, and target account recur as one bounded Kerberos diagnostic or audit pattern.
 
+- Do surrounding Kerberos events show repetition or account fan-out?
+  - Focus: same-source Kerberos network and authentication events, checking additional "4768"/"4769" events and `winlog.event_data.TargetUserName`.
+    - !{investigate{"description":"","label":"Kerberos network events from the same source IP","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"destination.port","queryType":"phrase","value":"88","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Authentication events for the same source IP","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"authentication","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when requests repeat or fan out across accounts; a single bounded request narrows scope but does not close if process identity or command intent remains suspicious. Missing network or authentication telemetry is unresolved, not benign.
 
-- 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.
-- Check if the Destination IP is related to a Domain Controller.
-- Review events ID 4769 and 4768 for suspicious ticket requests.
-- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.
+- Do later logon or explicit-credential events suggest ticket use?
+  - Focus: same-source authentication results, checking later `event.code` "4624"/"4648", `winlog.event_data.TargetUserName`, and 4648 `winlog.event_data.TargetServerName`.
+  - Implication: escalate when post-ticket logon or explicit-credential activity reaches sensitive accounts or servers from the same source; absence narrows impact but does not close if the ticket request remains suspicious. Missing same-source authentication telemetry leaves ticket use unresolved, not benign.
+
+- If local evidence remains suspicious or unresolved, does the same source show related alerts?
+  - Focus: related alerts for `source.ip`; manually pivot on recovered `process.hash.sha256` or `winlog.event_data.TargetUserName` when locally suspicious. !{investigate{"description":"","label":"Alerts associated with the same source IP","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when credential-access, Kerberoasting, relay, or lateral-movement alerts share the source, process, or target account; keep local only when related alerts are absent and recovered evidence resolves cleanly.
+
+- Escalate when sequence recovery, source-process identity, command intent, DC ticket target, account context, or surrounding ticket/logon activity show unauthorized direct Kerberos; close only when telemetry binds one recognized tool, source host, user, and target account and outside confirmation verifies exact activity when telemetry cannot; preserve and escalate when visibility is incomplete or evidence conflicts.
 
 
 *False positive analysis*
 
 
-- Active Directory audit tools.
+- AD audit tools, Kerberos diagnostics, interoperability testing, or security testing can request tickets directly instead of through "lsass.exe". Confirm only when process path, signer/hash, parent, command line, `source.ip`, `user.id`, `event.code`, and target account align with the same recognized tool on a dedicated admin, lab, or audit source; without outside records, require the same process identity, source host/user, target account, and bounded ticket pattern across prior alerts from this rule.
+- Treat partial matches as unresolved when process identity fits but the command targets unusual SPNs, privileged accounts, RC4/kerberoast behavior, or follow-on "4624"/"4648" activity. Do not close on signer, source IP, or event code alone when ticket target or command intent contradicts benign workflow.
+- Before creating an exception, anchor it to the minimum stable workflow: dedicated `source.ip` or source host, process signer/hash/path, parent workflow, `user.id`, target account, and bounded `event.code` pattern. Avoid exceptions on `source.port`, `event.code`, process name, or broad account patterns alone.
 
 
 *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.
-- 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.
-  - Ticket requests can be used to investigate potentially compromised accounts.
-- 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).
+- If confirmed benign, reverse temporary containment and document the recovered source host/IP, process identity, command line, source user, DC ticket event, and target account that proved the recognized workflow. Create an exception only after the same dedicated source and process pattern recurs consistently.
+- If suspicious but unconfirmed, preserve the alert, Timeline member events, suspicious process binary and command line, source socket, DC authentication record, and any follow-on "4624" or "4648" evidence before containment or process action.
+- Apply reversible containment next: restrict the recovered source host's Kerberos/DC access or isolate the host when its role tolerates isolation, and suspend the recovered process only after process and authentication artifacts are captured.
+- If confirmed malicious, isolate the recovered source host, terminate or suspend the recovered process after recording its `process.entity_id`, expire exposed Kerberos tickets where operationally appropriate, and reset or rotate impacted credentials, prioritizing privileged, service, machine, and delegation-capable accounts.
+- Before cleanup, search for the same source IP, recovered process hash, target account, and related credential-access, Kerberoasting, relay, or lateral-movement activity so scope is not limited to the first sequence.
+- After containment, retain DC "4768"/"4769" auditing and endpoint network telemetry, restrict direct Kerberos tooling to controlled admin/testing hosts, and document the recovered tool pattern and any logging gaps in the case record.
+
+
+==== 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-3-setup[Sysmon Event ID 3 - Network Connection]
+- https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-kerberos-authentication-service[Audit Kerberos Authentication Service]
+- https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-kerberos-service-ticket-operations[Audit Kerberos Service Ticket Operations]
 
 
 ==== Rule query
@@ -110,13 +155,20 @@ Domain-joined hosts usually perform Kerberos traffic using the `lsass.exe` proce
 sequence by source.port, source.ip with maxspan=3s
  [network where host.os.type == "windows" and destination.port == 88 and
   process.executable != null and process.pid != 4 and 
-  not process.executable : 
-              ("?:\\Windows\\system32\\lsass.exe", 
-               "\\device\\harddiskvolume*\\windows\\system32\\lsass.exe", 
-               "\\device\\harddiskvolume*\\windows\\system32\\svchost.exe") and
-  not (process.executable : ("C:\\Windows\\System32\\svchost.exe", 
-                             "C:\\Program Files\\VMware\\VMware View\\Server\\bin\\ws_TomcatService.exe", 
-                             "F:\\IGEL\\RemoteManager\\*\\bin\\tomcat10.exe") and user.id in ("S-1-5-20", "S-1-5-18")) and   
+  not process.executable : (
+        "?:\\Windows\\system32\\lsass.exe",
+        "\\device\\harddiskvolume*\\windows\\system32\\lsass.exe",
+        "\\device\\harddiskvolume*\\windows\\system32\\svchost.exe"
+  ) and
+  not (
+    process.executable : (
+      "C:\\Windows\\System32\\svchost.exe",
+      "C:\\Program Files\\VMware\\VMware View\\Server\\bin\\ws_TomcatService.exe",
+      "C:\\Program Files\\Omnissa\\Horizon\\Server\\bin\\ws_TomcatService.exe",
+      "F:\\IGEL\\RemoteManager\\*\\bin\\tomcat10.exe"
+    ) and
+    user.id in ("S-1-5-20", "S-1-5-18")
+  ) and   
   source.ip != "127.0.0.1" and destination.ip != "::1" and destination.ip != "127.0.0.1"]
  [authentication where host.os.type == "windows" and event.code in ("4768", "4769")]
 
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-macos-ms-office-child-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-macos-ms-office-child-process.asciidoc
index 3e32930cd9..ed6958762f 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-macos-ms-office-child-process.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-macos-ms-office-child-process.asciidoc
@@ -32,7 +32,7 @@ Identifies suspicious child processes of frequently targeted Microsoft Office ap
 * Data Source: Elastic Defend
 * Resources: Investigation Guide
 
-*Version*: 212
+*Version*: 213
 
 *Rule authors*: 
 
@@ -198,7 +198,16 @@ process where event.action == "exec" and host.os.type == "macos" and
         "/Library/Elastic/Agent/*",
         "/opt/jc/bin/jumpcloud-agent",
         "/usr/sbin/networksetup"
+      ) and
+    not (
+      process.name in ("sh", "bash") and
+      process.command_line like "*com.microsoft.Outlook/Data/tmp/Outlook*Temp*" and
+      process.parent.executable in (
+        "/Applications/Microsoft Outlook.app/Contents/MacOS/Microsoft Outlook",
+        "/Applications/Microsoft Outlook 2.app/Contents/MacOS/Microsoft Outlook",
+        "/Applications/Microsoft/Microsoft Outlook.app/Contents/MacOS/Microsoft Outlook"
       )
+    )
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-module-loaded-by-lsass.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-module-loaded-by-lsass.asciidoc
index cbfb37f332..a9066c987b 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-module-loaded-by-lsass.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-module-loaded-by-lsass.asciidoc
@@ -8,7 +8,6 @@ Identifies LSASS loading an unsigned or untrusted DLL. Windows Security Support
 *Rule indices*: 
 
 * logs-endpoint.events.library-*
-* endgame-*
 
 *Severity*: medium
 
@@ -32,10 +31,9 @@ Identifies LSASS loading an unsigned or untrusted DLL. Windows Security Support
 * Use Case: Threat Detection
 * Tactic: Credential Access
 * Data Source: Elastic Defend
-* Data Source: Elastic Endgame
 * Resources: Investigation Guide
 
-*Version*: 14
+*Version*: 15
 
 *Rule authors*: 
 
@@ -110,75 +108,96 @@ Setup instructions: https://ela.st/install-elastic-defend
 
 [source, js]
 ----------------------------------
-any where event.category in ("library", "driver") and host.os.type == "windows" and
+library where host.os.type == "windows" and event.action == "load" and
   process.executable : "?:\\Windows\\System32\\lsass.exe" and
-  not (dll.code_signature.subject_name :
-               ("Microsoft Windows",
-                "Microsoft Corporation",
-                "Microsoft Windows Publisher",
-                "Microsoft Windows Software Compatibility Publisher",
-                "Microsoft Windows Hardware Compatibility Publisher",
-                "McAfee, Inc.",
-                "SecMaker AB",
-                "HID Global Corporation",
-                "HID Global",
-                "Apple Inc.",
-                "Citrix Systems, Inc.",
-                "Dell Inc",
-                "Hewlett-Packard Company",
-                "Symantec Corporation",
-                "National Instruments Corporation",
-                "DigitalPersona, Inc.",
-                "Novell, Inc.",
-                "gemalto",
-                "EasyAntiCheat Oy",
-                "Entrust Datacard Corporation",
-                "AuriStor, Inc.",
-                "LogMeIn, Inc.",
-                "VMware, Inc.",
-                "Istituto Poligrafico e Zecca dello Stato S.p.A.",
-                "Nubeva Technologies Ltd",
-                "Micro Focus (US), Inc.",
-                "Yubico AB",
-                "GEMALTO SA",
-                "Secure Endpoints, Inc.",
-                "Sophos Ltd",
-                "Morphisec Information Security 2014 Ltd",
-                "Entrust, Inc.",
-                "Nubeva Technologies Ltd",
-                "Micro Focus (US), Inc.",
-                "F5 Networks Inc",
-                "Bit4id",
-                "Thales DIS CPL USA, Inc.",
-                "Micro Focus International plc",
-                "HYPR Corp",
-                "Intel(R) Software Development Products",
-                "PGP Corporation",
-                "Parallels International GmbH",
-                "FrontRange Solutions Deutschland GmbH",
-                "SecureLink, Inc.",
-                "Tidexa OU",
-                "Amazon Web Services, Inc.",
-                "SentryBay Limited",
-                "Audinate Pty Ltd",
-                "CyberArk Software Ltd.",
-                "McAfeeSysPrep",
-                "NVIDIA Corporation PE Sign v2016",
-                "Trend Micro, Inc.",
-                "Fortinet Technologies (Canada) Inc.",
-                "Carbon Black, Inc.") and
-       dll.code_signature.status : ("trusted", "errorExpired", "errorCode_endpoint*", "errorChaining")) and
-
-     not dll.hash.sha256 :
-                ("811a03a5d7c03802676d2613d741be690b3461022ea925eb6b2651a5be740a4c",
-                 "1181542d9cfd63fb00c76242567446513e6773ea37db6211545629ba2ecf26a1",
-                 "ed6e735aa6233ed262f50f67585949712f1622751035db256811b4088c214ce3",
-                 "26be2e4383728eebe191c0ab19706188f0e9592add2e0bf86b37442083ae5e12",
-                 "9367e78b84ef30cf38ab27776605f2645e52e3f6e93369c674972b668a444faa",
-                 "d46cc934765c5ecd53867070f540e8d6f7701e834831c51c2b0552aba871921b",
-                 "0f77a3826d7a5cd0533990be0269d951a88a5c277bc47cff94553330b715ec61",
-                 "4aca034d3d85a9e9127b5d7a10882c2ef4c3e0daa3329ae2ac1d0797398695fb",
-                 "86031e69914d9d33c34c2f4ac4ae523cef855254d411f88ac26684265c981d95")
+  not (
+        dll.code_signature.subject_name : (
+            "Algorithmic Research LTD.",
+            "Amazon Web Services, Inc.",
+            "Apple Inc.",
+            "Audinate Pty Ltd",
+            "AuriStor, Inc.",
+            "Bit4id",
+            "Carbon Black, Inc.",
+            "Check Point Software Technologies Ltd.",
+            "Citrix Systems, Inc.",
+            "CyberArk Software Ltd.",
+            "Dell Inc",
+            "DigitalPersona, Inc.",
+            "EasyAntiCheat Oy",
+            "Entrust Corporation",
+            "Entrust Datacard Corporation",
+            "Entrust, Inc.",
+            "F5 Networks Inc",
+            "Fortinet, Inc.",
+            "Fortinet Technologies (Canada) Inc.",
+            "FrontRange Solutions Deutschland GmbH",
+            "GEMALTO SA",
+            "gemalto",
+            "Hewlett-Packard Company",
+            "HID Global",
+            "HID Global Corporation",
+            "HYPR Corp",
+            "IDEMIA IDENTITY & SECURITY FRANCE SAS",
+            "IDEMIA France SAS",
+            "Intel(R) Software Development Products",
+            "Istituto Poligrafico e Zecca dello Stato S.p.A.",
+            "LogMeIn, Inc.",
+            "McAfee, Inc.",
+            "McAfeeSysPrep",
+            "Micro Focus (US), Inc.",
+            "Micro Focus International plc",
+            "Microsoft Corporation",
+            "Microsoft Windows",
+            "Microsoft Windows Hardware Compatibility Publisher",
+            "Microsoft Windows Publisher",
+            "Microsoft Windows Software Compatibility Publisher",
+            "Morphisec Information Security 2014 Ltd",
+            "Musarubra US LLC",
+            "National Instruments Corporation",
+            "Novell, Inc.",
+            "Nubeva Technologies Ltd",
+            "NVIDIA Corporation PE Sign v2016",
+            "Palo Alto Networks (Netherlands) B.V.",
+            "Parallels International GmbH",
+            "PGP Corporation",
+            "QUEST SOFTWARE INC.",
+            "SecMaker AB",
+            "Secure Endpoints, Inc.",
+            "SecureLink, Inc.",
+            "SentinelOne Inc.",
+            "SentryBay Limited",
+            "Sophos Ltd",
+            "Symantec Corporation",
+            "Thales DIS CPL USA, Inc.",
+            "Tidexa OU",
+            "Trend Micro, Inc.",
+            "VMware, Inc.",
+            "Yubico AB"
+        ) and
+        dll.code_signature.status : ("trusted", "errorExpired", "errorCode_endpoint*", "errorChaining")
+  ) and
+
+  not dll.hash.sha256 : (
+          "811a03a5d7c03802676d2613d741be690b3461022ea925eb6b2651a5be740a4c",
+          "1181542d9cfd63fb00c76242567446513e6773ea37db6211545629ba2ecf26a1",
+          "ed6e735aa6233ed262f50f67585949712f1622751035db256811b4088c214ce3",
+          "26be2e4383728eebe191c0ab19706188f0e9592add2e0bf86b37442083ae5e12",
+          "9367e78b84ef30cf38ab27776605f2645e52e3f6e93369c674972b668a444faa",
+          "d46cc934765c5ecd53867070f540e8d6f7701e834831c51c2b0552aba871921b",
+          "0f77a3826d7a5cd0533990be0269d951a88a5c277bc47cff94553330b715ec61",
+          "4aca034d3d85a9e9127b5d7a10882c2ef4c3e0daa3329ae2ac1d0797398695fb",
+          "86031e69914d9d33c34c2f4ac4ae523cef855254d411f88ac26684265c981d95",
+          "4af1fee3369d9a993a84f54eafb72a661633c33e9e12fb3dd151a6a2cddbd404"
+  ) and
+  not dll.path : (
+        "C:\\Windows\\System32\\CertPolEng.dll",
+        "C:\\Windows\\System32\\FWPUCLNT.DLL",
+        "C:\\Windows\\System32\\keyiso.dll",
+        "C:\\Windows\\System32\\ngcpopkeysrv.dll",
+        "C:\\Windows\\System32\\SecureTimeAggregator.dll",
+        "C:\\Windows\\System32\\vaultsvc.dll"
+  )
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-print-spooler-point-and-print-dll.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-print-spooler-point-and-print-dll.asciidoc
index 69b65ea3b9..963de71676 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-print-spooler-point-and-print-dll.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-print-spooler-point-and-print-dll.asciidoc
@@ -44,7 +44,7 @@ Detects attempts to exploit a privilege escalation vulnerability (CVE-2020-1030)
 * Data Source: SentinelOne
 * Data Source: Microsoft Defender XDR
 
-*Version*: 214
+*Version*: 215
 
 *Rule authors*: 
 
@@ -60,46 +60,78 @@ Detects attempts to exploit a privilege escalation vulnerability (CVE-2020-1030)
 *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 Print Spooler Point and Print DLL*
 
 
-The Windows Print Spooler service manages print jobs and is integral to printing operations. Adversaries exploit vulnerabilities like CVE-2020-1030 to escalate privileges by loading malicious DLLs into the spooler process, which runs with SYSTEM-level permissions. The detection rule identifies suspicious registry modifications linked to the Print Spooler, indicating potential exploitation attempts by monitoring specific registry paths and data patterns.
-
 
 *Possible investigation steps*
 
 
-- Review the registry paths specified in the alert to confirm any unauthorized modifications, focusing on the paths: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\*\SpoolDirectory and HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\*\CopyFiles\Payload\Module.
-- Check the registry data strings for any unexpected or suspicious DLLs located in C:\Windows\System32\spool\drivers\x64\4, which may indicate a malicious payload.
-- Investigate the host identified by host.id to determine if there are any other signs of compromise or unusual activity, such as unexpected processes or network connections.
-- Correlate the alert with other security events or logs from the same host to identify any related activities or patterns that could suggest a broader attack.
-- Assess the system's patch level and update status to ensure that all known vulnerabilities, including CVE-2020-1030, have been addressed and mitigated.
-- If a malicious DLL is confirmed, isolate the affected system to prevent further exploitation and begin remediation efforts, such as removing the malicious files and restoring the system to a known good state.
+- Do the source registry events describe one printer object?
+  - Why: sequence alerts joined only on `host.id` can omit stage-specific registry and writer fields; recover member events before interpreting the grouped alert.
+  - Focus: compare the printer segment in `registry.path`, `registry.value`, and `registry.data.strings`; keep `user.id` and any `process.entity_id` pivots.
+  - Implication: escalate when one printer key sets SpoolDirectory to "C:\Windows\System32\spool\drivers\x64\4" then CopyFiles\Payload\Module under that path; lower concern only when recovery breaks the same-printer chain or value match.
+
+- Which process and user wrote the values, and does context fit printer administration?
+  - Focus: source-event writer context: `user.id`, `process.executable`, `process.command_line`, `process.parent.executable`, and recovered `process.entity_id`.
+  - Implication: escalate when reg.exe, rundll32.exe, a scripting host, a user-writable binary, or an unexpected interactive user wrote the values; lower concern when writer identity, parentage, and service context match the same confirmed driver deployment.
+
+- What DLL path did Module name, and was it staged?
+  - Focus: recovered Module `registry.data.strings`; if file telemetry exists, exact-path `file.path`, `file.Ext.original.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier`. Missing file telemetry leaves staging unresolved, not benign.
+  - Implication: escalate when the path names a newly written, renamed, internet-marked, or script-staged DLL in the spool drivers tree; lower concern when the exact path is a stable signed printer-driver package tied to the recovered printer object and writer workflow.
+
+- Did Print Spooler or print isolation consume the module?
+  - Why: CVE-2020-1030 abuse becomes higher impact when the CopyFiles\Payload\Module value is loaded or spooler restart behavior forces the changed configuration into effect.
+  - Focus: in library or process telemetry, check spoolsv.exe or PrintIsolationHost.exe loading the recovered path with `dll.path`, `dll.hash.sha256`, `dll.code_signature.subject_name`, and `dll.code_signature.trusted`. !{investigate{"description":"","label":"Spooler or print isolation loads on the host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"spoolsv.exe","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"PrintIsolationHost.exe","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: pivot on the recovered Module path because the sequence alert may not preserve that value; spooler termination or restart around the writes can be a force-load clue.
+  - Implication: escalate immediately when spooler loads the recovered DLL, restarts unexpectedly, or shows abnormal child activity soon after the writes; absent load telemetry does not clear a matching registry chain.
+
+- If suspicious or unresolved, does the pattern appear beyond this alert?
+  - Focus: related alerts for `host.id`, then exact matches for recovered `registry.data.strings`, printer `registry.path`, or `dll.hash.sha256` across other hosts when available. !{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 response when the same module path, DLL hash, printer-object pattern, or spooler-abuse alert appears on unrelated hosts; keep scope local when the pattern stays confined to the same confirmed driver workflow.
+
+- What disposition do registry chain, writer, payload, spooler, and scope evidence support?
+  - Focus: decide from same-printer registry stages, writer identity, DLL staging/load, workflow fit, and scope: escalate suspicious or unresolved chains, close only when telemetry cleanly aligns with one signed driver or print-management workflow, and preserve artifacts when evidence is mixed or incomplete.
 
 
 *False positive analysis*
 
 
-- Legitimate printer driver updates or installations may trigger the rule due to registry modifications in the specified paths. Users can create exceptions for known and trusted driver update processes to prevent false alerts.
-- Custom print configurations by IT departments that modify the SpoolDirectory or CopyFiles registry paths might be flagged. Document and exclude these configurations if they are verified as safe and necessary for business operations.
-- Automated scripts or software that manage printer settings and inadvertently modify the monitored registry paths can cause false positives. Identify and whitelist these scripts or applications after confirming their legitimacy.
-- Third-party print management solutions that interact with the Print Spooler service may lead to false detections. Evaluate these solutions and exclude their known benign activities from the detection rule.
+- Recognized signed printer-driver installation, print-management, imaging, or endpoint-build workflows can update SpoolDirectory and CopyFiles\Payload\Module or stage spool-directory drivers. Confirm recovered `registry.path`, exact `registry.data.strings`, stable signed DLL identity, writer `process.executable`, parent workflow, current-case `host.id`, and any spooler follow-on all point to the same driver or management workflow without ad hoc scripting, unsigned payloads, or suspicious child processes. Change or deployment records may corroborate; prior-alert recurrence can scope exceptions but must not substitute for current-case telemetry.
+- Build exceptions only from the minimum confirmed workflow pattern: `host.id`, recovered printer object from `registry.path`, exact recovered Module path, stable DLL identity, and the confirmed writer or deployment process. Avoid exceptions on the spool drivers directory alone, the printer name alone, or spoolsv.exe activity alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
-- Terminate the Print Spooler service on the compromised system to stop any ongoing malicious activity and prevent further DLL loading.
-- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any malicious DLLs or related files.
-- Review and restore the registry paths identified in the detection query to their default values to ensure no malicious configurations remain.
-- Apply the latest security patches and updates from Microsoft to address CVE-2020-1030 and other known vulnerabilities in the Print Spooler service.
-- Monitor the network for any signs of similar exploitation attempts, focusing on the registry paths and data patterns specified in the detection rule.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.
+- If confirmed benign, record `host.id`, the recovered printer object, exact Module path, stable DLL identity, and deployment workflow that justified closure before reversing temporary containment. Create an exception only from that exact confirmed workflow pattern; use prior alerts to narrow scope, not to prove benignity.
+- If suspicious but unconfirmed, preserve the Timeline member events, exact `registry.path` and `registry.data.strings`, exported affected registry keys, recovered DLL file if present, file or library hashes, writer `process.executable`, user context, and any spoolsv.exe or PrintIsolationHost.exe follow-on evidence before containment. Apply reversible containment first, such as restricting remote printer administration, disabling Point and Print exposure, or pausing nonessential printing on the affected host.
+- If confirmed malicious, preserve the DLL if feasible, export the affected printer keys, and retain related spoolsv.exe or PrintIsolationHost.exe process and library telemetry before containment. Then use endpoint response to isolate the host when registry-chain, payload, or spooler-side evidence shows malicious activity and host criticality allows it. Review other hosts for the same recovered DLL path, DLL hash, or printer-object pattern before stopping spoolsv.exe, deleting the DLL, restoring registry values, and removing the mechanism that staged the payload.
+- Post-incident hardening: apply the Microsoft fix for CVE-2020-1030, restrict Point and Print and printer-driver installation rights where feasible, disable the Print Spooler service on hosts that do not need it, retain registry, file, and library telemetry for spooler abuse, and document confirmed printer-object and DLL patterns 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/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel]
+- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events]
+
 
 ==== Rule query
 
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-seincreasebasepriorityprivilege-use.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-seincreasebasepriorityprivilege-use.asciidoc
index d9bee4fa3d..e9e8429775 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-seincreasebasepriorityprivilege-use.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-seincreasebasepriorityprivilege-use.asciidoc
@@ -36,7 +36,7 @@ Identifies attempts to use the SeIncreaseBasePriorityPrivilege privilege by an u
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -56,30 +56,62 @@ Identifies attempts to use the SeIncreaseBasePriorityPrivilege privilege by an u
 *Investigating Suspicious SeIncreaseBasePriorityPrivilege Use*
 
 
-SeIncreaseBasePriorityPrivilege allows to increase the priority of processes running on the system so that the CPU scheduler allows them to pre-empt other lower priority processes when the higher priority process has something to do.
-
 
 *Possible investigation steps*
 
 
-- Review the process.executable reputation and it's execution chain.
-- Investiguate if the SubjectUserName is expected to perform this action.
-- Correlate the event with other security alerts or logs to identify any patterns or additional suspicious activities that might suggest a broader attack campaign.
-- Check the agent health status and verify if there is any tampering with endpoint security processes.
+- What priority-change path did 4674 preserve?
+  - Why: this privilege manipulates process or thread priority; the target object matters as much as the requester.
+  - Focus: Security 4674 on `host.id`: `winlog.event_data.PrivilegeList`, `winlog.event_data.AccessMask`, `winlog.event_data.ProcessName`, `winlog.event_data.ObjectType`, and `winlog.event_data.ObjectName`.
+  - Hint: sparse or numeric-only `winlog.event_data.ObjectName` is the main visibility gap; keep the target unresolved and use same-session Security records, not assumed self-tuning.
+  - Implication: escalate when the object is a "Process" or "Thread" tied to security tooling, LSASS, or another user's workload; lower suspicion only when requester, object, and `host.name` fit bounded tuning or testing.
+
+- Is the requesting image path expected for priority control on this host?
+  - Focus: `winlog.event_data.ProcessName`, `winlog.event_data.ProcessId`, `winlog.event_data.SubjectUserSid`, `host.name`, and `@timestamp`.
+  - Hint: `winlog.event_data.ProcessId` is hexadecimal; use it only inside a tight host/time window; PID reuse can mislead.
+  - Implication: escalate when the path is user-writable, temporary, renamed, or unrelated to local tuning; treat a recurring full path and SID as identity support, not closure, until object and session evidence align.
+
+- Which subject and local session requested this privilege use?
+  - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, and `winlog.event_data.SubjectLogonId`.
+  - Implication: escalate when a normal user, rare admin, machine account, or service account lacks a clear scheduling-priority role; matching SID, domain, and session support benignity only with matching requester and object evidence.
+
+- Does the 4624 session origin fit a priority-tuning operator?
+  - Focus: on the same `host.id`, match alert `winlog.event_data.SubjectLogonId` to 4624 `winlog.event_data.TargetLogonId`, then read `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`.
+  - Hint: query `event.code` 4624 with alert `host.id` and `winlog.event_data.TargetLogonId`; search backward from `@timestamp` because the session can predate 4674. !{investigate{"description":"","label":"Linked logon for the priority-change session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} Missing 4624 or empty `source.ip` is unresolved, not benign.
+  - Implication: escalate when source, logon type, or authentication method is rare for `host.name` or subject SID; matching origin supports authorized tuning only after requester path and target object fit.
+
+- Do surrounding Security records show repeated or multi-target priority use by the same requester?
+  - Focus: Security events around `@timestamp` on the same `host.id`, grouped by `winlog.event_data.SubjectLogonId`, `winlog.event_data.ProcessId`, `winlog.event_data.ProcessName`, and `winlog.event_data.ObjectName`.
+  - Hint: start in the alert window with `event.code` 4674 and alert `winlog.event_data.SubjectLogonId`; expand only if the same session continues around `@timestamp`. Add `event.outcome` to separate failed attempts from successful use. !{investigate{"description":"","label":"4674 priority-use events from this requester session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4674","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ProcessId","queryType":"phrase","value":"{{winlog.event_data.ProcessId}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4674","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ProcessName","queryType":"phrase","value":"{{winlog.event_data.ProcessName}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when one session or requester touches multiple process/thread objects, repeats against security targets, or continues after failures; a single 4674 keeps scope local but still requires requester, object, and session answers for closure.
+
+- If local evidence is suspicious or unresolved, do related alerts expand scope or urgency?
+  - Focus: related alerts for the same `host.id`, prioritizing privilege abuse, defense evasion, security-tool interference, service-control, or authentication findings. !{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"}}
+  - Hint: if the subject remains suspicious, use the subject pivot; use the `user.id` provider only after confirming it maps to `winlog.event_data.SubjectUserSid`. !{investigate{"description":"","label":"Alerts associated with the subject","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}],[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the host or user also shows privilege escalation, defense evasion, or unusual authentication; keep scope local when related alerts are absent and 4674/session evidence supports bounded work.
+
+- Escalate for unauthorized process/thread priority manipulation or security-tool interference; close only when object, requester, subject, session, and related alerts bind to one authorized tuning or troubleshooting workflow; preserve 4674 and recovered 4624 evidence and escalate when sparse object or session evidence leaves suspicious findings unresolved.
 
 
 *False positive analysis*
 
 
-- Administrative tasks involving legitimate CPU scheduling priority changes.
+- Performance engineering, benchmark, QA, vendor, or internal support work can trigger when an administrator adjusts scheduling priority or CPU assignment for a test or latency-sensitive workload. Confirm only when `winlog.event_data.ProcessName`, `winlog.event_data.ObjectType`, `winlog.event_data.ObjectName`, `winlog.event_data.SubjectUserSid`, recovered `source.ip`, and `winlog.logon.type` align with the same recognized host, accounts, and workload. If records are unavailable, require telemetry-only recurrence of the same full requester path, SID, object family, and host class before treating as benign.
+- If the target object is sparse or numeric-only, do not close solely on tool name or user claim.
+- Before creating an exception, validate that `winlog.event_data.ProcessName`, `winlog.event_data.ObjectType`, `winlog.event_data.ObjectName`, `winlog.event_data.SubjectUserSid`, `host.id`, and recovered `source.ip` or `winlog.logon.type` stay stable across known-benign occurrences. Build the exception from that minimum confirmed pattern; avoid exceptions on `winlog.event_data.PrivilegeList` or `user.name` alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected machine from the network to prevent further unauthorized access or lateral movement within the domain.
-- Terminate the processes involved in the execution chain.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken.
+- If confirmed benign, reverse temporary containment and document the validated `winlog.event_data.ProcessName`, `winlog.event_data.ObjectType`, `winlog.event_data.ObjectName`, `winlog.event_data.SubjectUserSid`, recovered `source.ip`, `winlog.logon.type`, and `host.id` values proving the tuning or troubleshooting workflow. Create an exception only after the same pattern repeats benignly.
+- If suspicious but unconfirmed, preserve a case export of triggering 4674, recovered 4624 session record, surrounding same-session Security records, and related-alert links before containment. Record requester path and PID, subject SID, target object, session origin, and event time as case anchors.
+- If suspicious but unconfirmed, apply reversible containment first, such as restricting the subject's remote access, pausing the support workflow, or raising monitoring on `host.id`. Escalate to host isolation or account disablement only if the target maps to a security-critical process, related alerts show additional privilege abuse or defense evasion, or the recovered session suggests credential misuse.
+- If confirmed malicious, isolate the host when the object, requester, session, or related-alert evidence shows unauthorized priority manipulation of a security-critical process or another user's workload. Record the requester path and PID, subject SID, target object, recovered session origin, and event time before stopping processes or deleting tooling.
+- Reset or suspend the implicated account only when the recovered session and related alerts show likely credential misuse, and review other hosts for the same `winlog.event_data.ProcessName`, `winlog.event_data.ObjectName`, or `winlog.event_data.SubjectUserSid` before eradicating artifacts so scoping finishes before evidence is destroyed.
+- Eradicate only the unauthorized tuning or interference tooling and any persistence or launcher artifacts identified during the investigation, then restore affected security or service configurations to a known-good state.
+- Hardening: restrict assignment of "SeIncreaseBasePriorityPrivilege" to the smallest admin cohort, retain Security 4674 and 4624 visibility, and record visibility gaps that limited the case decision.
+
 
 ==== Setup
 
@@ -88,19 +120,8 @@ SeIncreaseBasePriorityPrivilege allows to increase the priority of processes run
 *Setup*
 
 
-Ensure advanced audit policies for Windows are enabled, specifically:
-Audit Sensitive Privilege Use https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4674[Event ID 4674] (An operation was attempted on a privileged object.)
-
-```
-Computer Configuration >
-Policies >
-Windows Settings >
-Security Settings >
-Advanced Audit Policies Configuration >
-Audit Policies >
-Privilege Use >
-Audit Sensitive Privilege Use (Success)
-```
+Audit Sensitive Privilege Use must be enabled to generate the events used by this rule.
+Setup instructions: https://ela.st/audit-sensitive-privilege-use
 
 
 ==== Rule query
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc
index f291c1c279..8d6a5c2004 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc
@@ -1,7 +1,7 @@
 [[suspicious-solarwinds-web-help-desk-java-module-load-or-child-process]]
 === Suspicious SolarWinds Web Help Desk Java Module Load or Child Process
 
-Identifies the SolarWinds Web Help Desk Java process loading an untrusted or remote native module (DLL). This behavior is uncommon for the Web Help Desk server and may indicate successful exploitation of deserialization vulnerabilities (CVE-2025-40536, CVE-2025-40551), which allow attackers to load malicious SQLite extensions and achieve remote code execution.
+Identifies the SolarWinds Web Help Desk Java process loading an untrusted or remote native module (DLL) or spawning a suspicious child process such as cmd, PowerShell, or rundll32. This behavior is uncommon for the Web Help Desk server and may indicate successful exploitation of deserialization vulnerabilities (CVE-2025-40536, CVE-2025-40551), which allow attackers to load malicious SQLite extensions and achieve remote code execution.
 
 *Rule type*: eql
 
@@ -35,7 +35,7 @@ Identifies the SolarWinds Web Help Desk Java process loading an untrusted or rem
 * Data Source: Elastic Defend
 * Resources: Investigation Guide
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -51,53 +51,73 @@ Identifies the SolarWinds Web Help Desk Java process loading an untrusted or rem
 *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, validate the guidance and adapt it to your environment and operational requirements.
 
+*Investigating Suspicious SolarWinds Web Help Desk Java Module Load or Child Process*
 
-*Investigating Suspicious SolarWinds Web Help Desk Java Module Load or Child Process"*
 
 
-SolarWinds Web Help Desk is a Java-based, internet-facing application commonly deployed on Windows servers.
-Recent vulnerabilities (CVE-2025-40536, CVE-2025-40551) allow unauthenticated attackers to exploit unsafe
-deserialization and abuse SQLite extension loading to execute arbitrary native code within the Java process.
+*Possible investigation steps*
 
-This rule detects suspicious native module (DLL) loads by the Web Help Desk Java process, as well as
-post-exploitation child process execution, both of which are strong indicators of successful exploitation.
 
+- Which path fired, and what alert-local evidence defines it?
+  - Why: The single-event branch decides whether DLL fields or child-process fields carry the decisive evidence.
+  - Focus: `event.category`, Java path in `process.executable` or `process.parent.executable`, `dll.path`, and child `process.command_line`.
+  - Hint: record `process.entity_id` for library alerts and `process.parent.entity_id` for child-process alerts before later pivots.
+  - Implication: Escalate quickly for Web Help Desk Java loading remote or untrusted native code, or spawning "cmd.exe", "powershell.exe", or "rundll32.exe" with payload behavior. Lower concern only when the exact branch maps to a recognized local extension, authorized validation, or vendor support action and process or DLL evidence stays consistent.
 
-*Possible investigation steps*
+- Does the Java-side identity match the expected Web Help Desk service instance?
+  - Focus: Java path from step 1 and Java command line: `process.command_line` for library alerts or `process.parent.command_line` for child-process alerts.
+  - Implication: Escalate when the Java path falls outside the WebHelpDesk install tree or the service command line is abnormal for the deployed server. Identity lowers suspicion only when exact Java path and service context match the installed server; it does not clear a remote DLL load or shell child.
+
+- For the DLL-load path, does the module look like a remote SQLite-extension payload or unsupported native component?
+  - Why: Malicious SQLite-extension style native loading makes DLL path and trust state the strongest branch evidence.
+  - Focus: `dll.path`, `dll.hash.sha256`, `dll.code_signature.exists`, `dll.code_signature.trusted`, and `dll.code_signature.subject_name`.
+  - Implication: Escalate when `dll.path` shows "\Device\Mup\", a UNC-style share, temp or unrelated writable path, unsigned or untrusted module, or signer unrelated to Web Help Desk or its controlled extension set. Lower concern only when the module is local to the Web Help Desk or JDBC layout and has a recognized hash or signer.
+
+- For the child-process path, does the Java-spawned child show post-exploitation intent?
+  - Focus: `process.name`, `process.command_line`, and `process.parent.command_line`.
+  - Implication: Escalate when the command line decodes or stages payloads, loads DLLs, launches scripts, performs discovery, or changes persistence. Lower concern only for exact recognized validation or vendor-support command on this server with no contradictory DLL evidence.
 
+- Did the same Web Help Desk Java instance produce more DLL loads or suspicious children around the alert?
+  - Focus: process and library events scoped by `host.id` plus Java-side `process.entity_id` or `process.parent.entity_id`; review `process.command_line`, `dll.path`, and `dll.hash.sha256`. !{investigate{"description":"","label":"Process and DLL activity tied to the Web Help Desk Java instance","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":"library","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: Escalate when the same Java instance loads multiple remote or untrusted DLLs, starts multiple shell or loader children, or shows child execution after a suspicious DLL load. No surrounding process or library events narrows scope, but does not clear the original alert.
 
-- Review the **process executable path** to confirm the activity originated from the Web Help Desk Java runtime (e.g., `WebHelpDesk\jre\bin\java.exe`).
-- Examine the **loaded DLL path**:
-  - Pay special attention to DLLs loaded from UNC paths (e.g., `\<IP>\share\*.dll`) or temporary directories.
-  - Validate whether the DLL is unsigned or has an untrusted code signature.
-- Review **network telemetry** around the time of the alert for outbound SMB connections (TCP 445) originating from the Java process.
-- If a child process was spawned (e.g., `cmd.exe`, `powershell.exe`, `rundll32.exe`):
-  - Inspect command-line arguments for evidence of payload execution, staging, or persistence.
-- Check system logs for additional indicators of compromise, including scheduled task creation, service installation, or persistence mechanisms.
-- Determine the Web Help Desk version in use and confirm whether security patches addressing the relevant CVEs have been applied.
+- If local evidence remains suspicious or unresolved, are there related exploit or post-exploitation alerts on this server?
+  - Focus: related alerts on `host.id`, especially Web Help Desk exploitation, suspicious Java children, DLL loads, persistence, or credential access. !{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 related alerts align with the same Java process, DLL hash, or child command pattern. Keep the case local when related-alert review is clean, but do not use alert isolation alone to close.
+
+- Escalate on remote or untrusted DLL loading, malicious child execution, or same-Java corroboration; close only when branch evidence tightly matches a recognized local extension, authorized validation, or vendor support action on this host with no contradictory process or DLL evidence; if visibility or authorization is incomplete, preserve evidence and escalate.
 
 
 *False positive analysis*
 
 
-- Legitimate Web Help Desk installations typically do not load arbitrary native extensions at runtime. False positives are expected to be rare.
-- Custom integrations or troubleshooting activities that involve native JDBC extensions could trigger this rule. Validate whether such behavior is expected in your environment.
-- Security software or backup agents interacting with Java processes may occasionally load signed native libraries; verify the DLL origin and signature before dismissing the alert.
+- Local native extension, JDBC, or vendor-support testing can explain the DLL path only when the module stays local to the Web Help Desk or controlled plugin layout; `dll.hash.sha256`, `dll.code_signature.subject_name`, and `dll.code_signature.trusted` match the expected component; Java identity matches the installed server; and no Java-spawned shell or loader appears. Without support or change records, require telemetry-only alignment across `host.id`, Java `process.executable` or `process.parent.executable`, `dll.path`, and `dll.hash.sha256`; otherwise treat as unresolved.
+- Java-spawned "cmd.exe", "powershell.exe", or "rundll32.exe" is a Web Help Desk operational anti-pattern. Close only for authorized validation or vendor support where `process.name`, `process.command_line`, `process.parent.executable`, and `host.id` match that exact activity and no remote or untrusted DLL evidence appears. Without exact support or validation context, treat the branch as suspicious.
+- Before creating an exception, validate stable benign behavior for the exact workflow and host. For DLL loads, anchor on Java identity, `dll.path`, `dll.hash.sha256`, `dll.code_signature.subject_name`, and `host.id`; for child processes, anchor on Java parent identity, exact `process.command_line`, and `host.id`. Avoid exceptions on "java.exe", the WebHelpDesk path prefix, a DLL directory prefix, or the server alone.
 
 
 *Response and remediation*
 
 
-- Treat this alert as a **high-confidence compromise indicator** if the DLL is untrusted or loaded from a remote path.
-- Isolate the affected host to prevent further lateral movement or payload staging.
-- Terminate suspicious child processes and capture memory artifacts if possible for forensic analysis.
-- Remove any malicious files identified on disk and review persistence mechanisms.
-- Apply the latest SolarWinds Web Help Desk security updates addressing CVE-2025-40536 and CVE-2025-40551.
-- Conduct a broader environment sweep to identify other potentially vulnerable or compromised Web Help Desk instances.
-- Escalate the incident to the security operations or incident response team for full containment and remediation.
+- If confirmed benign, reverse temporary containment and document the Java identity, DLL hash/path or child command line, `host.id`, and support, validation, or extension evidence that proved the workflow. Create an exception only from the narrow branch-specific anchors that proved that workflow.
+- If suspicious but unconfirmed, preserve the alert export, process tree, Java and child command lines, loaded DLL file, DLL hash/signature, and any "\Device\Mup\" share path before containment. Apply reversible containment first, such as restricting Web Help Desk exposure or blocking the observed remote share path, and escalate to endpoint isolation only when DLL or child-process evidence suggests active payload execution.
+- If confirmed malicious, preserve process, DLL, and case artifacts before destructive action. Isolate the endpoint when the Java process is executing payloads or reaching remote native-code staging, block the malicious share path or DLL hash, collect the loaded DLL and relevant process evidence before termination, then remove only the payloads, persistence items, and service changes identified during the investigation.
+- Remediate the entry vector by upgrading or patching Web Help Desk to the vendor-fixed release, confirming the exposed service is no longer vulnerable, and reviewing whether public access, outbound SMB from the server, or native-extension/plugin controls need tighter restrictions.
+- Post-incident hardening: retain the process and library telemetry that proved the case, document remote SQLite-extension loading or Java-spawned shell activity for future triage, and record any authorized validation or support exception with its exact branch-specific anchors.
+
+
+==== 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
 
@@ -107,7 +127,7 @@ post-exploitation child process execution, both of which are strong indicators o
 any where host.os.type == "windows" and
 (
  (event.category == "library" and
-  process.executable : ("C:\\Program Files\\WebHelpDesk\\*\\java.exe", "C:\\Program Files (x86)\\WebHelpDesk\\*\\java.exe") and
+  process.executable : ("C:\\Program Files\\WebHelpDesk\\*\\java*.exe", "C:\\Program Files (x86)\\WebHelpDesk\\*\\java*.exe") and
   (dll.path : "\\Device\\Mup\\*" or dll.code_signature.trusted == false or ?dll.code_signature.exists == false)) or
 
  (event.category == "process" and process.name : ("cmd.exe", "powershell.exe", "rundll32.exe") and
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-startup-shell-folder-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-startup-shell-folder-modification.asciidoc
index 151f204ca5..0e0bb0b934 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-startup-shell-folder-modification.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-startup-shell-folder-modification.asciidoc
@@ -36,7 +36,6 @@ Identifies suspicious startup shell folder modifications to change the default S
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Persistence
-* Tactic: Defense Evasion
 * Resources: Investigation Guide
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
@@ -45,7 +44,7 @@ Identifies suspicious startup shell folder modifications to change the default S
 * Data Source: SentinelOne
 * Data Source: Crowdstrike
 
-*Version*: 319
+*Version*: 320
 
 *Rule authors*: 
 
@@ -65,61 +64,78 @@ Identifies suspicious startup shell folder modifications to change the default S
 *Investigating Suspicious Startup Shell Folder Modification*
 
 
-Techniques used within malware and by adversaries often leverage the Windows registry to store malicious programs for persistence. Startup shell folders are often targeted as they are not as prevalent as normal Startup folder paths so this behavior may evade existing AV/EDR solutions. These programs may also run with higher privileges which can be ideal for an attacker.
 
-> **Note**:
-> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
+*Possible investigation steps*
 
 
-*Possible investigation steps*
+- What shell-folder scope changed, and which local path now receives Startup items?
+  - Why: `registry.value` separates per-user "Startup" from all-users "Common Startup"; all-users scope broadens persistence beyond one profile.
+  - Focus: `registry.path`, `registry.value`, `registry.hive`, `registry.data.type`, `registry.data.strings`.
+  - Implication: escalate when `registry.data.strings` points to a user-writable, hidden, deceptive, or all-users local path; lower concern here only for a recognized managed redirection target, then continue through process and user/host checks.
+
+- Which process and lineage changed the shell-folder value?
+  - Focus: `process.executable`, `process.command_line`, `process.parent.executable`, `process.parent.command_line`, `process.code_signature.subject_name`.
+  - Implication: escalate when the writer is a COM broker such as dllhost.exe, script host, LOLBin, renamed binary, user-writable executable, or unrelated parent chain; lower concern for management or packaging tooling only when command line and lineage explain this exact shell-folder write. Signed identity never clears the behavior by itself.
+
+- Was a startup artifact staged or executed from the redirected path?
+  - Why: the registry change can be setup only; persistence is proven by startup content in the redirected directory, and delayed staging or value reversion can hide the chain.
+  - Focus: same-process activity, redirected-directory file events, and command lines referencing `registry.data.strings`.
+    - !{investigate{"description":"","label":"Activity from this process instance 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"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"File events in the redirected Startup path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.directory","queryType":"phrase","value":"{{registry.data.strings}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Process command lines referencing the redirected path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.command_line","queryType":"phrase","value":"{{registry.data.strings}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+  - Hint: if file telemetry is available, check file-event writes to that directory; missing file-event visibility is unresolved, not benign.
+  - Implication: escalate when the modifier or later process writes, launches, or reverts around shortcuts, scripts, or binaries in the redirected directory.
 
+- Does the creating identity and host context fit one recognized redirection workflow?
+  - Focus: `user.id`, `user.name`, `user.domain`, `host.id`, `host.name`.
+  - Implication: escalate when an interactive or ad hoc identity changes Startup resolution on a host that does not normally customize shell folders; lower concern only when identity, host cohort, path, and lineage converge on one recognized management or packaging workflow.
 
-- 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.
-- Review the source process and related file tied to the Windows Registry entry.
-- Validate if the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.
-- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
-- Examine the host for derived artifacts that indicate suspicious activities:
-  - Analyze the file using a private sandboxed analysis system.
-  - Observe and collect information about the following activities in both the sandbox and the alert subject host:
-    - Attempts to contact external domains and addresses.
-      - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.
-      - Examine the DNS cache for suspicious or anomalous entries.
-        - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}}
-    - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
-    - Examine the host services for suspicious or anomalous entries.
-      - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}}
-      - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}}
-      - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}}
-  - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
-- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.
+- If local evidence is suspicious or unresolved, does same-host activity change scope?
+  - Why: sibling autostart `registry.path` changes can preserve persistence if the redirected Startup folder is noticed, restored, or cleaned.
+  - Focus: use !{investigate{"description":"","label":"Recent activity on this host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} for the same `host.id`, then filter for the exact `registry.data.strings` path, sibling autostart `registry.path` changes, and process starts referencing the redirected path.
+  - Implication: broaden response when the host shows additional shell-folder or Run-key changes, execution from the redirected path, or repeated attempts to use it; keep scope local only when the pivot finds no matching autostart or execution evidence.
+
+- Do the path, process, payload-use, and context findings support startup-folder evasion?
+  - Implication: escalate for an unexpected process or actor, suspicious local path, shortcut/script/binary content, redirected-path execution, or same-host persistence/evasion; close only when telemetry narrows the case to one exact recognized workflow and outside confirmation verifies legitimacy where telemetry alone cannot; preserve and escalate when file visibility, process context, or workflow evidence is incomplete.
 
 
 *False positive analysis*
 
 
-- There is a high possibility of benign legitimate programs being added to shell folders. This activity could be based on new software installations, patches, or other network administrator activity. Before undertaking further investigation, it should be verified that this activity is not benign.
+- Managed shell-folder redirection or application packaging can repoint "Startup" or "Common Startup" to a nondefault local path, but this is operationally sensitive. Treat these explanations as benign only when alert-window telemetry proves the exact redirected folder, process lineage, expected startup content, and managed host cohort all match one management or packaging job. Use deployment records, management configuration, packaging job logs, or owner confirmation when telemetry alone cannot prove legitimacy; do not close on a management label without this evidence.
+- Before exceptioning, validate recurrence of the same `registry.value`, `registry.data.strings`, `process.executable`, `process.command_line`, `process.parent.executable`, `user.id`, and `host.id` pattern after confirming the benign workflow. Build the exception from that minimum workflow, and avoid exceptions on all Startup shell-folder modifications, the whole Explorer shell-folder key family, or the rule name alone.
+
 
+*Response and remediation*
 
-*Related rules*
 
+- If confirmed benign, record the exact registry path/value/data, process lineage, `user.id`, and `host.id` pattern that proved the recognized workflow, then reverse temporary containment. Keep any exception narrow and require recurrence of that same workflow.
+- If suspicious but unconfirmed, preserve the alert, Timeline or case exports, the current shell-folder value, process tree, command line, and redirected-directory contents or metadata when available before changing state. Apply reversible containment first, such as blocking execution from the redirected directory or increasing monitoring on the host. Restore the legitimate Startup path only after evidence capture, dependency review, and validation of the correct per-user or Common Startup path. Isolate the host only when payload execution or related alerts show active compromise.
+- If confirmed malicious, collect staged shortcuts, scripts, binaries, hashes, and registry evidence before eradication. Contain the endpoint when its role allows, contain the creating account when the evidence shows account misuse, validate the correct per-user or Common Startup value, restore that value, and remove only the artifacts identified in the investigation. If direct response is unavailable, escalate with the preserved evidence to the team that can act on the host.
+- Before cleanup, review other user profiles and the all-users Startup scope for the same redirected path, then verify no process execution still points to that directory. After recovery, restrict shell-folder redirection to controlled management tooling, retain registry/process and available file telemetry needed to connect redirection to later payload staging, and document delayed-staging or value-reversion blind spots for future cases.
 
-- Startup or Run Key Registry Modification - 97fc44d3-8dae-4019-ae83-298c3015600f
-- Persistent Scripts in the Startup Directory - f7c4dc5a-a58d-491d-9f14-9b66507121c0
 
+==== 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*
 
-*Response and remediation*
 
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
 
-- Initiate the incident response process based on the outcome of the triage.
-- Isolate the involved host to prevent further post-compromise behavior.
-- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
-- If the malicious file was delivered via phishing:
-  - Block the email sender from sending future emails.
-  - Block the malicious web pages.
-  - Remove emails from the sender from mailboxes.
-  - Consider improvements to the security awareness program.
-- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
-- 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).
+- 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-reg-setup[Sysmon Registry Events]
 
 
 ==== Rule query
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-suid-binary-execution-auditd-sequence.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-suid-binary-execution-auditd-sequence.asciidoc
new file mode 100644
index 0000000000..a02febdedc
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-suid-binary-execution-auditd-sequence.asciidoc
@@ -0,0 +1,129 @@
+[[suspicious-suid-binary-execution-auditd-sequence]]
+=== Suspicious SUID Binary Execution (Auditd Sequence)
+
+Detects suspicious sequences where a non-root user launches a high-risk parent process (interpreter, shell one-liner, or execution from user-writable paths) and then quickly executes a common privilege elevation helper (su, sudo, pkexec, passwd, chsh, newgrp) that gains an effective UID of 0 while the real UID remains non-root. This can indicate misuse of SUID/SGID helpers, polkit/sudo abuse, or interactive privilege escalation attempts captured via Auditd Manager telemetry.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* 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 <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1548/
+* https://docs.elastic.co/integrations/auditd_manager
+
+*Tags*: 
+
+* Data Source: Auditd Manager
+* Domain: Endpoint
+* OS: Linux
+* 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 Suspicious SUID Binary Execution (Auditd Sequence)*
+
+
+Confirm whether the non-root real user should be invoking su, sudo, pkexec, or account utilities as root. Review the
+parent process chain and whether the parent executable location or shell invocation suggests a one-liner or staging
+from user-writable paths.
+
+
+*Possible investigation steps*
+
+
+- Review process details for script paths, temp directory execution, or suspicious interpreters.
+- Check sudoers / polkit policy changes and recent authentication events for the user.
+- Pivot for follow-on persistence (cron, systemd units) or credential access from the same session.
+
+
+*Response and remediation*
+
+
+- If unauthorized, contain the session, revoke elevated access, and review sudoers and polkit configuration for tampering.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by host.id with maxspan=30s
+  [process where host.os.type == "linux" and event.type == "start" and
+   event.action == "executed" and
+   user.id != "0" and user.effective.id != "0" and
+   (
+     process.name like ("python*", "perl*", "ruby*", "php*", "lua*", ".*") or
+     process.name in ("node", "bun", "java") or
+     process.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/user/*", "/var/run/user/*", "/home/*/*") or
+     (
+       process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh") and
+       process.args in ("-c", "--command", "-ic", "-ci", "-cl", "-lc")
+     )
+   )
+  ] by process.pid
+
+  [process where host.os.type == "linux" and event.type == "start" and
+   event.action == "executed" and
+   user.effective.id == "0" and user.id != "0" and
+   (
+     (process.name in ("sudo", "pkexec") and
+      not process.args like "-*" and
+      not process.args : ("/usr/*", "/bin/*", "/sbin/*", "/opt/*")) or
+     (process.name == "su" and
+      not process.args in ("--command", "-c", "--shell", "-s")) or
+     (process.name in ("passwd", "chsh", "newgrp") and
+      not process.args in ("--shell", "-s", "--help"))
+   )
+  ] by process.parent.pid
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Abuse Elevation Control Mechanism
+** ID: T1548
+** Reference URL: https://attack.mitre.org/techniques/T1548/
+* Sub-technique:
+** Name: Setuid and Setgid
+** ID: T1548.001
+** Reference URL: https://attack.mitre.org/techniques/T1548/001/
+* Sub-technique:
+** Name: Sudo and Sudo Caching
+** ID: T1548.003
+** Reference URL: https://attack.mitre.org/techniques/T1548/003/
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-suid-binary-execution.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-suid-binary-execution.asciidoc
index 5c9ea54f89..e0a7ad7228 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-suid-binary-execution.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-suid-binary-execution.asciidoc
@@ -1,9 +1,9 @@
 [[suspicious-suid-binary-execution]]
 === Suspicious SUID Binary Execution
 
-Detects execution of common privilege elevation helpers (su, sudo, pkexec, passwd, chsh, newgrp) under the root effective user when the real user and parent user are not root, combined with minimal argument counts and suspicious parent context (interpreters, short shell -c invocations, or parents running from user-writable paths).
+Detects execution of SUID binaries that may be used for privilege escalation under the root effective user when the real user and parent user are not root, combined with minimal argument counts and suspicious parent context (interpreters, short shell -c invocations, or parents running from user-writable paths) to indicate potential misuse of SUID binaries for privilege escalation.
 
-*Rule type*: query
+*Rule type*: eql
 
 *Rule indices*: 
 
@@ -32,7 +32,7 @@ Detects execution of common privilege elevation helpers (su, sudo, pkexec, passw
 * Tactic: Privilege Escalation
 * Resources: Investigation Guide
 
-*Version*: 1
+*Version*: 2
 
 *Rule authors*: 
 
@@ -52,8 +52,7 @@ Detects execution of common privilege elevation helpers (su, sudo, pkexec, passw
 *Investigating Suspicious SUID Binary Execution*
 
 
-Confirm whether the non-root real user should be invoking su, sudo, pkexec, or account utilities as root. Review the
-parent process tree, script path, and any preceding download or decode activity.
+Confirm whether the non-root real user should be invoking SUID binaries as root. Review the parent process tree, script path, and any preceding download or decode activity.
 
 
 *Possible investigation steps*
@@ -75,20 +74,30 @@ parent process tree, script path, and any preceding download or decode activity.
 
 [source, js]
 ----------------------------------
-host.os.type:linux and event.category:process and event.action:"exec" and
-process.name:("su" or "sudo" or "pkexec" or "passwd" or "chsh" or "newgrp") and
-process.user.id:"0" and not process.real_user.id:"0" and
-not process.parent.user.id:"0" and
+process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
+  (process.user.id == "0" and process.real_user.id != "0" and process.parent.user.id != "0") or
+  (process.group.id == "0" and process.real_group.id != "0" and process.parent.group.id != "0")
+) and
 (
-  (process.name:("sudo" or "pkexec") and process.args_count:1) or
-  (process.name:("su" or "passwd" or "chsh" or "newgrp") and process.args_count <= 2)
+  (process.name in ("su", "passwd", "unix_chkpwd") and process.args_count <= 2) or
+  (
+    process.name in ("sudo", "pkexec", "fusermount", "fusermount3", "mount", "umount", "newgrp", "chsh") and
+    process.args_count == 1
+  ) or
+  process.name in (
+    "sudoedit", "gpasswd", "chfn", "polkit-agent-helper-1", "dbus-daemon-launch-helper", "ssh-keysign",
+    "pam_extrausers_chkpwd", "expiry", "chage", "crontab", "wall", "bsd-write", "ssh-agent", "ping",
+    "ping6", "traceroute", "mtr", "ntfs-3g", "Xorg.wrap", "chrome-sandbox", "bwrap"
+  )
 ) and
 (
-  process.parent.name:(python* or perl* or ruby* or node or bun or java or php* or lua* or .*) or
-  process.parent.executable:(/tmp/* or /var/tmp/* or /dev/shm/* or /home/* or /run/user/*) or
-  (process.parent.name:(bash or sh or zsh or dash or fish or ksh) and 
-   (process.parent.command_line: (-bash or -sh or -zsh or -dash or -fish or -ksh) or 
-   (process.parent.args:("-c" or "--command" or "-ic" or "-ci") and process.parent.args_count <= 4)))
+  process.parent.name like (".*", "python*", "perl*", "ruby*", "lua*", "php*", "node", "deno", "bun", "java") or
+  process.parent.executable like ("./*", "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/user/*", "/var/run/user/*", "/home/*/*") or
+  (
+    process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh") and
+    process.parent.args in ("-c", "-cl", "-lc", "--command", "-ic", "-ci", "-bash", "-sh", "-zsh", "-dash", "-fish", "-ksh", "-mksh") and
+    process.parent.args_count <= 4
+  )
 )
 
 ----------------------------------
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-windows-command-shell-arguments.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-windows-command-shell-arguments.asciidoc
index 16057c6843..fd6f29edb1 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-windows-command-shell-arguments.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-windows-command-shell-arguments.asciidoc
@@ -42,7 +42,7 @@ Identifies the execution of the Windows Command Shell process (cmd.exe) with sus
 * Data Source: Elastic Endgame
 * Data Source: Crowdstrike
 
-*Version*: 208
+*Version*: 209
 
 *Rule authors*: 
 
@@ -58,47 +58,79 @@ Identifies the execution of the Windows Command Shell process (cmd.exe) with sus
 *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 Command Shell Arguments*
 
 
-The Windows Command Shell (cmd.exe) is a critical component for executing commands and scripts. Adversaries exploit it to execute malicious scripts, download payloads, or manipulate system settings. The detection rule identifies unusual command-line arguments and patterns indicative of such abuse, filtering out known benign processes to minimize false positives. This helps in early detection of potential threats by monitoring for suspicious command executions.
-
 
 *Possible investigation steps*
 
 
-- Review the command line arguments associated with the cmd.exe process to identify any suspicious patterns or keywords such as "curl", "regsvr32", "wscript", or "Invoke-WebRequest" that may indicate malicious activity.
-- Check the parent process of the cmd.exe execution to determine if it is a known benign process or if it is associated with potentially malicious activity, especially if the parent process is explorer.exe or other unusual executables.
-- Investigate the user account associated with the cmd.exe process to determine if the activity aligns with the user's typical behavior or if it appears anomalous.
-- Examine the network activity of the host to identify any unusual outbound connections or data transfers that may correlate with the suspicious command execution.
-- Cross-reference the alert with other security logs or alerts from tools like Sysmon, SentinelOne, or Microsoft Defender XDR to gather additional context and corroborate findings.
-- Assess the risk score and severity of the alert to prioritize the investigation and determine if immediate response actions are necessary.
+- What abuse path and launch context does the alerting "cmd.exe" show?
+  - Focus: `process.command_line`, `process.args`, `process.executable`, `process.parent.executable`, and `process.parent.command_line`; classify reconstruction, remote retrieval, WebDAV or UNC execution, obfuscated environment setup, or handoff to "regsvr32.exe", "wscript.exe", "mshta.exe", PowerShell, or AutoIt.
+  - Implication: escalate when the command reconstructs scripts, pulls remote content, starts from a remote share, chains to proxy execution, runs from a non-native path, or has a parent conflicting with command purpose; lower suspicion only when parent-command, user-host, child, artifact, and destination evidence form one consistent current activity. Identity or recurrence alone does not clear suspicious arguments.
+
+- Did the same "cmd.exe" instance launch a second stage?
+  - Focus: child starts where `host.id` and `process.parent.entity_id` map to `process.entity_id`; review child `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child process starts from the same cmd.exe instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `process.entity_id` is absent, use `host.id` plus `process.pid` in a tight alert-time window.
+  - Implication: escalate when the shell launches PowerShell, "regsvr32.exe", "wscript.exe", "mshta.exe", archive tools, script files, or newly staged payloads; lower suspicion when no child follows or stays inside the parent directory or command-named output path.
+
+- If endpoint file telemetry is available, did the shell reconstruct or stage executable content?
+  - Focus: file activity tied to `process.entity_id` or, if needed, `host.id` plus `process.pid`, checking `file.path`, `file.Ext.original.path`, `file.Ext.header_bytes`, and `file.Ext.windows.zone_identifier`. !{investigate{"description":"","label":"File activity for the alerting cmd.exe instance","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.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the shell writes scriptable files, rebuilds archive or PE content, renames staged payloads, or leaves internet-marked content in temp, public, or user-writable paths; lower suspicion when paths stay under the parent directory or command-named output path and no written content later executes. Missing file telemetry is unresolved, not benign.
+
+- If endpoint network telemetry is available, did the shell retrieve content or execute from WebDAV or UNC infrastructure?
+  - Focus: process-scoped DNS and connections for `host.id` and `process.entity_id`; compare DNS `dns.question.name` or `dns.resolved_ip` and connection `destination.ip` or `destination.port` with UNC, "DavWWWRoot", or URL fragments in `process.command_line`. !{investigate{"description":"","label":"Network activity for the alerting cmd.exe instance","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.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `dns.resolved_ip` is present, correlate it to `destination.ip` on the same host and process before judging the destination.
+  - Implication: escalate when the shell reaches rare public hosts, unexpected WebDAV endpoints, or shares unrelated to the parent; lower suspicion when DNS and connections match the share, URL, or host pattern visible in the command and parent. Missing network telemetry is unresolved, not benign.
+
+- If local findings remain suspicious or unresolved, does the pattern recur on the same host or user?
+  - Focus: recent alerts for the same `host.id`, emphasizing execution, delivery, persistence, or proxy-execution detections that reuse the same command-shell pattern. !{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"}}
+  - Hint: if the host is shared or quiet, compare recent alerts for the same `user.id` to test whether the user carries the pattern to other systems. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same host or user also shows delivery, shell, or persistence alerts; keep local when related alerts are clean and telemetry binds one parent-command, child, artifact, destination, and user-host tuple.
+
+- What disposition does the parent-command, child, artifact, destination, and user-host tuple support?
+  - Escalate for staged execution, remote retrieval, script reconstruction, proxy execution, or broader compromise; close only when alert-local command, parent, child, artifact, destination, user-host, and related-alert evidence bind one exact benign tuple with no contradictions. Preserve evidence and escalate on conflicts or incomplete visibility.
 
 
 *False positive analysis*
 
 
-- Processes related to Spiceworks and wmiprvse.exe can trigger false positives. Exclude these by adding exceptions for process arguments containing "%TEMP%\\Spiceworks\\*" when the parent process is wmiprvse.exe.
-- Development tools like Perl, Node.js, and NetBeans may cause false alerts. Exclude these by specifying their executable paths in the exception list.
-- Citrix Secure Access Client initiated by userinit.exe can be a false positive. Exclude this by adding an exception for process arguments containing "?:\\Program Files\\Citrix\\Secure Access Client\\nsauto.exe" with the parent process name as userinit.exe.
-- Scheduled tasks or services like PCPitstopScheduleService.exe may trigger alerts. Exclude these by adding their paths to the exception list.
-- Command-line operations involving npm or Maven commands can be benign. Exclude these by specifying command-line patterns like "\"cmd\" /c %NETBEANS_MAVEN_COMMAND_LINE%" in the exception list.
+- Packaging, build, installer, or developer activity can use "cmd.exe" to reconstruct files, call package managers, or hand off to helper utilities. Confirm `process.parent.executable`, `process.parent.command_line`, `process.command_line`, `user.id`, and `host.id` align with the same current parent path, helper command, package cache, build output, or database-export output, and that recovered child, file, or destination evidence does not conflict. Build records or change tickets are corroboration only.
+- Remote-support or software-distribution activity can reference UNC paths or "DavWWWRoot". When network or file telemetry exists, confirm `process.command_line`, `process.parent.executable`, `host.id`, and any recovered `dns.question.name`, `destination.ip`, or `file.path` stay inside one current distribution share, vendor endpoint, support-client cache, or deployment path and no unexpected child appears. Missing file or network telemetry is unresolved, not benign. Support records or inventories are corroboration only.
+- Before creating an exception, validate that the same `process.parent.executable`, `process.command_line`, `user.id`, `host.id`, and recovered artifact or destination anchors recur across prior alerts from this rule. Avoid exceptions on "cmd.exe" alone, one argument token, one destination, or parent name.
 
 
 *Response and remediation*
 
 
-- Isolate the affected system from the network to prevent further spread of potential malware or unauthorized access.
-- Terminate any suspicious cmd.exe processes identified by the detection rule to halt malicious activity.
-- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or scripts.
-- Review and restore any altered system settings or configurations to their original state to ensure system integrity.
-- Analyze the command-line arguments and parent processes involved in the alert to understand the scope and origin of the threat, and identify any additional compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment measures are necessary.
-- Implement additional monitoring and detection rules to identify similar suspicious command-line activities in the future, enhancing the organization's ability to detect and respond to such threats promptly.
+- If confirmed benign, reverse temporary containment and document the parent command, alerting command, user-host scope, and recovered artifact or destination evidence. Create an exception only after the same tuple is stable across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve the alert, Timeline records, full command lines, process tree, recovered child details, staged files, and DNS or connection evidence before destructive action. Apply reversible containment first, such as temporary destination restrictions or heightened monitoring on `host.id` and `user.id`; isolate only when follow-on execution, staged payloads, or remote retrieval justifies disruption.
+- If confirmed malicious, isolate the host when identity, lineage, artifact, or destination evidence establishes unauthorized execution, then block confirmed malicious domains, destinations, or hashes. Record malicious shell and child identifiers before termination, scope related hosts and users before artifact removal, then remove only the scripts, archives, rebuilt payloads, persistence artifacts, or launcher components identified during the investigation.
+- Post-incident hardening: retain process, file, and network telemetry. If browser, explorer, script-host, or AutoIt launch paths were involved, review controls for user-driven shell launches; if WebDAV, UNC, or URL retrieval was involved, review remote-share and WebDAV execution controls. Note adjacent "mshta.exe", "wscript.exe", "regsvr32.exe", PowerShell, AutoIt, and explorer-driven clickfix-style variants for future triage.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires telemetry from one of the configured source integrations to be enabled and ingested.
+
+
+*Supported data sources*
+
+
+This rule can use the following 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
 
diff --git a/docs/detections/prebuilt-rules/rule-details/system-public-ip-discovery-via-dns-query.asciidoc b/docs/detections/prebuilt-rules/rule-details/system-public-ip-discovery-via-dns-query.asciidoc
index 50465e2502..b5c14a5014 100644
--- a/docs/detections/prebuilt-rules/rule-details/system-public-ip-discovery-via-dns-query.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/system-public-ip-discovery-via-dns-query.asciidoc
@@ -1,7 +1,7 @@
 [[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. Malwares tend to perform this action to assess potential targets.
+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
 
@@ -43,7 +43,7 @@ Identifies DNS queries to known public IP address lookup web services. Malwares
 * Data Source: Crowdstrike
 * Data Source: Sysmon
 
-*Version*: 3
+*Version*: 4
 
 *Rule authors*: 
 
@@ -67,32 +67,75 @@ Identifies DNS queries to known public IP address lookup web services. Malwares
 *Possible investigation steps*
 
 
-- Investigate the process execution chain (parent process tree) for unknown processes or malicious scripts.
-- Verify if the executed process is persistent on the host like common mechanisms Startup folder, task or Run key.
-- Review any unusual network, files or registry events by the same process.
-- Investigate other alerts associated with the user/host during the past 48 hours.
-- Extract this communication's indicators of compromise (IoCs) and use traffic logs to search for other potentially compromised hosts.
+- 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*
 
 
-- Trusted domain from an expected process running in the environment.
+- 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*
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Isolate the involved host to prevent further post-compromise behavior.
-- Immediately block the identified indicators of compromise (IoCs).
-- Implement any temporary network rules, procedures, and segmentation required to contain the attack.
-- 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.
-- Update firewall rules to be more restrictive.
-- Reimage the host operating system or restore the compromised files to clean versions.
-- 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).
+- 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
@@ -104,13 +147,16 @@ network where host.os.type == "windows" and dns.question.name != null and proces
 (
   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") or
+  "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\\*.exe", "?:\\ProgramData\\*.exe")
+  ?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 :
          (
@@ -140,7 +186,6 @@ network where host.os.type == "windows" and dns.question.name != null and proces
           "iplogger.*",
           "freegeoip.net",
           "freegeoip.app",
-          "ipinfo.io",
           "geoplugin.net",
           "myip.dnsomatic.com",
           "www.geoplugin.net",
@@ -148,12 +193,17 @@ network where host.os.type == "windows" and dns.question.name != null and proces
           "ip4.seeip.org",
           "*.geojs.io",
           "*portmap.io",
-          "api.2ip.ua",
           "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 == "S-1-5-18"
+)
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-via-windows-directory-masquerading.asciidoc b/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-via-windows-directory-masquerading.asciidoc
index dc9bc19d77..ac053e9d5c 100644
--- a/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-via-windows-directory-masquerading.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-via-windows-directory-masquerading.asciidoc
@@ -37,7 +37,6 @@ Identifies an attempt to bypass User Account Control (UAC) by masquerading as a
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Privilege Escalation
-* Tactic: Defense Evasion
 * Resources: Investigation Guide
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
@@ -47,7 +46,7 @@ Identifies an attempt to bypass User Account Control (UAC) by masquerading as a
 * Data Source: SentinelOne
 * Data Source: Crowdstrike
 
-*Version*: 322
+*Version*: 323
 
 *Rule authors*: 
 
@@ -67,60 +66,86 @@ Identifies an attempt to bypass User Account Control (UAC) by masquerading as a
 *Investigating UAC Bypass Attempt via Windows Directory Masquerading*
 
 
-Windows User Account Control (UAC) allows a program to elevate its privileges (tracked as low to high integrity levels) to perform a task under administrator-level permissions, possibly by prompting the user for confirmation. UAC can deny an operation under high-integrity enforcement, or allow the user to perform the action if they are in the local administrators group and enter an administrator password when prompted.
 
-For more information about the UAC and how it works, check the https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works[official Microsoft docs page].
+*Possible investigation steps*
 
-This rule identifies an attempt to bypass User Account Control (UAC) by masquerading as a Microsoft trusted Windows directory. Attackers may bypass UAC to stealthily execute code with elevated permissions.
 
-> **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.
+- Does the alert-local path prove execution from a mock trusted Windows directory?
+  - Why: This technique abuses a trailing-space "C:\Windows " tree that AppInfo checks can normalize while the fake path still executes.
+  - Focus: `process.executable` and `process.command_line`, especially "C:\Windows \System32\" or "C:\Windows \SysWOW64\" instead of the canonical Windows path.
+  - Implication: escalate when executable or argument paths contain the trailing-space trusted-directory clone; lower suspicion only when `process.executable` and `process.command_line` resolve to the canonical Windows path and later evidence does not contradict that.
 
+- Is the binary a copied auto-elevating Windows executable?
+  - Focus: `process.name`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.hash.sha256`.
+  - Implication: escalate when a signed Microsoft auto-elevating binary runs from the fake tree, name or PE metadata imitates one, or the hash is unfamiliar; if not auto-elevating, keep suspicious as path masquerading or staging until lineage and artifacts explain it.
 
-*Possible investigation steps*
+- Do the parent, user, and token context fit a UAC-bypass transition?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, `process.Ext.token.integrity_level_name`, and `process.Ext.token.elevation_level`.
+  - Implication: escalate when a browser, document process, script host, installer, or remote-admin parent launches the copied binary with high or full integrity; lower suspicion when parent, user, token state, and host cohort align with confirmed compatibility or security testing.
+
+- Did file events show the fake tree being staged before or by the alerting process?
+  - Focus: same-`host.id` file events where `file.path` is under "C:\Windows \", plus alert-process file events scoped by `process.entity_id` when present. !{investigate{"description":"","label":"File events for the suspicious process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: File telemetry is conditional; missing file events leave staging unresolved, not benign. Use `file.Ext.original.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier` only when the fake-tree writer is unclear.
+  - Implication: escalate when any process creates "C:\Windows \", copies the auto-elevating executable, or drops a same-directory DLL; lower suspicion only when fake-tree artifacts are bounded to controlled lab testing with no contradictory DLL or child-process evidence.
+
+- Did the copied binary load a sidecar DLL from the fake tree?
+  - Focus: library events scoped by `host.id` plus `process.entity_id` when present; review `dll.path`, `dll.hash.sha256`, and `dll.code_signature.subject_name`. !{investigate{"description":"","label":"Library events for the suspicious process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: Library telemetry is conditional; missing library events leave DLL payload execution unresolved, not benign.
+  - Implication: escalate when the copied binary loads a same-directory DLL from the fake tree, especially unsigned, unfamiliar, or mismatched; if no DLL evidence appears, continue to child-process review before treating execution as unresolved.
 
+- Did the copied binary spawn elevated follow-on code?
+  - Focus: same-`host.id` child processes where `process.parent.entity_id` matches `process.entity_id`; review child `process.command_line` and `process.Ext.token.integrity_level_name`. !{investigate{"description":"","label":"Child processes launched by the copied binary","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the copied binary spawns high-integrity shells, scripts, payloads, or unexpected admin tools; if no child appears, treat execution as unresolved unless path, binary, parent, file, and DLL evidence all support controlled lab testing.
 
-- 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.
-- Inspect the host for suspicious or abnormal behavior in the alert timeframe.
-- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes.
-- Examine the host for derived artifacts that indicate suspicious activities:
-  - Analyze any suspicious spawned processes using a private sandboxed analysis system.
-  - Observe and collect information about the following activities in both the sandbox and the alert subject host:
-    - Attempts to contact external domains and addresses.
-      - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.
-      - Examine the DNS cache for suspicious or anomalous entries.
-        - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}}
-    - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
-    - Examine the host services for suspicious or anomalous entries.
-      - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}}
-      - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}}
-      - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}}
-  - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
-- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.
+- If local evidence is suspicious or incomplete, is the same fake path or host showing related activity?
+  - Focus: related alerts for the same `process.executable` fake path, especially UAC-bypass, masquerading, or payload-staging detections; check same-host alert history for privilege-escalation, defense-evasion, or suspicious file-staging context.
+    - !{investigate{"description":"","label":"Alerts associated with the same fake executable path","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+    - !{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: escalate scope when the same fake path appears across hosts or the same host has surrounding staging, privilege-escalation, or defense-evasion alerts; keep scope local only when local evidence also supports controlled lab testing.
+
+- What disposition do the fake path, binary identity, lineage, artifacts, execution, and scope support?
+  - Escalate when path, binary identity, lineage, artifacts, execution, or scope show fake-tree UAC bypass; close only when all categories align with controlled lab testing and no contradictions remain; preserve artifacts and escalate when mixed or incomplete.
 
 
 *False positive analysis*
 
 
-- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+- This behavior is an operational anti-pattern outside explicit testing. Authorized compatibility or security research can trigger it only when a team deliberately constructs a trailing-space Windows tree in a controlled lab. Confirm exact `process.executable`, stable `process.hash.sha256`, Microsoft signer and original file name, `process.parent.executable`, `user.id`, `host.id`, and sidecar-DLL behavior against the same test. If test plans exist, require alignment; otherwise rely on prior alerts for the same path, hash, parent workflow, and lab cohort without unexpected elevated children.
+- Do not treat a signed Microsoft binary or lab host as sufficient. Same-directory DLL load, elevated shell, suspicious parent, internet-provenance file event, or recurrence outside the expected cohort keeps the alert suspicious until the exact test scope explains it.
+- Before an exception, validate recurrence of the minimum workflow pattern: exact `process.executable`, stable `process.hash.sha256`, `process.parent.executable`, expected sidecar-DLL behavior, and bounded `host.id` or `user.id` cohort. Avoid exceptions on "C:\Windows " alone, binary name alone, or `host.id` alone.
 
 
 *Response and remediation*
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Isolate the involved host to prevent further post-compromise behavior.
-- If the triage identified malware, search the environment for additional compromised hosts.
-  - Implement temporary network rules, procedures, and segmentation to contain the malware.
-  - Stop suspicious processes.
-  - Immediately block the identified indicators of compromise (IoCs).
-  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
-- Remove and block malicious artifacts identified during triage.
-- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
-- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
-- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+- If confirmed benign, reverse temporary containment and record the exact fake-tree path, copied binary hash, parent workflow, user/host cohort, and sidecar-DLL behavior that proved the recognized workflow. Create an exception only after that same pattern recurs consistently for this rule.
+- If suspicious but unconfirmed, preserve a case export for the alert process, parent chain, token context, fake-tree directory, copied binary, sidecar DLLs and hashes, and any elevated child details before containment. Apply reversible containment next, such as restricting execution from the fake tree or isolating the affected host if sidecar loading, elevated children, or broader post-exploitation evidence is active.
+- If confirmed malicious, collect the copied auto-elevating binary and sidecar DLLs, preserve process, file, and library telemetry, then isolate the host after weighing business criticality. Scope other hosts for the same fake path, copied binary hash, and DLL pattern before killing processes, deleting the fake "system32" tree, and remediating the launcher or access path that staged it.
+- Post-incident hardening: remove the fake trailing-space directory tree, restrict creation or execution of copied Windows binaries from user-writable or fake trusted paths, retain file/library/process telemetry for same-directory DLL hijacking, and record the recovered auto-elevating-binary and DLL pair 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/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
@@ -159,3 +184,11 @@ process where host.os.type == "windows" and event.type == "start" and
 ** Name: Match Legitimate Resource Name or Location
 ** ID: T1036.005
 ** Reference URL: https://attack.mitre.org/techniques/T1036/005/
+* Technique:
+** Name: Abuse Elevation Control Mechanism
+** ID: T1548
+** Reference URL: https://attack.mitre.org/techniques/T1548/
+* Sub-technique:
+** Name: Bypass User Account Control
+** ID: T1548.002
+** Reference URL: https://attack.mitre.org/techniques/T1548/002/
diff --git a/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc b/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc
index e04ab034ef..f44a5e20c2 100644
--- a/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc
@@ -34,8 +34,6 @@ Identifies attempts to bypass User Account Control (UAC) by abusing an elevated
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Privilege Escalation
-* Tactic: Defense Evasion
-* Tactic: Execution
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
 * Data Source: Sysmon
@@ -43,7 +41,7 @@ Identifies attempts to bypass User Account Control (UAC) by abusing an elevated
 * Data Source: SentinelOne
 * Resources: Investigation Guide
 
-*Version*: 313
+*Version*: 314
 
 *Rule authors*: 
 
@@ -59,47 +57,83 @@ Identifies attempts to bypass User Account Control (UAC) by abusing an elevated
 *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 UAC Bypass Attempt with IEditionUpgradeManager Elevated COM Interface*
 
 
-User Account Control (UAC) is a security feature in Windows designed to prevent unauthorized changes by prompting for elevated permissions. The IEditionUpgradeManager COM interface can be exploited by attackers to bypass UAC, allowing them to execute code with elevated privileges without user consent. This detection rule identifies such attempts by monitoring for the execution of the ClipUp program from non-standard paths, initiated by a specific COM interface, indicating potential misuse for privilege escalation.
-
 
 *Possible investigation steps*
 
 
-- Review the process execution details to confirm the presence of ClipUp.exe running from a non-standard path, as indicated by the process.executable field not matching "C:\Windows\System32\ClipUp.exe".
-- Investigate the parent process, dllhost.exe, to determine if it was legitimately initiated or if it shows signs of compromise, focusing on the process.parent.args field to verify the use of the specific COM interface CLSID: /Processid:{BD54C901-076B-434E-B6C7-17C531F4AB41}.
-- Check the user account context under which ClipUp.exe was executed to assess if it aligns with expected user behavior or if it suggests unauthorized access.
-- Correlate this event with other security logs and alerts from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender XDR, or SentinelOne to identify any related suspicious activities or patterns.
-- Examine recent changes or anomalies in system configurations or installed software that might indicate preparation for or execution of a UAC bypass attempt.
-- If available, review network activity logs for any unusual outbound connections or data exfiltration attempts following the execution of ClipUp.exe.
+- Does the alert show the IEditionUpgradeManager ClipUp bypass path?
+  - Focus: `process.name`, `process.executable`, `process.parent.name`, `process.parent.args`, and `process.Ext.token.elevation_level`.
+  - Hint: absent token metadata does not lower suspicion; the path and COM parent args still define the bypass path.
+  - Implication: a "dllhost.exe" broker, IEditionUpgradeManager CLSID, "ClipUp.exe" name, and non-System32 path warrant UAC bypass investigation; high or full elevation raises priority. Concern drops only when later identity and child checks bind to exact servicing or authorized testing.
+
+- Is the non-system ClipUp image a genuine Microsoft servicing component or an attacker-defined payload?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Hint: absent hash, signature, or PE metadata does not lower suspicion; fall back to path, COM args, command line, and child behavior.
+  - Implication: treat the image as attacker-controlled when unsigned, not Microsoft-signed, mismatched to "ClipUp.exe", or in a user-writable root. A Microsoft signer, matching original name, and stable hash reduce suspicion only when the same path ties to the servicing package under review.
+
+- Does the path or runtime metadata fit system-directory spoofing or lookalike staging?
+  - Why: the alert already proves ClipUp ran outside genuine System32; a writable root ending in "\system32\clipup.exe" is the staging clue.
+  - Focus: `process.executable`, `process.Ext.relative_file_creation_time`, `process.Ext.relative_file_name_modify_time`, and `process.command_line`.
+  - Hint: absent relative timing fields leave the issue unresolved; use path root, command line, signer/hash, and local process history.
+  - Implication: temp, profile, writable-share, or other non-Windows roots ending in "\system32\clipup.exe" indicate system-directory spoofing, especially with recent create or rename timing. Stable path age and servicing arguments reduce concern only after image identity also fits.
+
+- Did the elevated ClipUp instance start follow-on tooling?
+  - Focus: child process starts where `process.parent.entity_id` matches `process.entity_id`, reviewing `process.name`, `process.executable`, `process.command_line`, and `process.Ext.token.integrity_level_name`. !{investigate{"description":"","label":"Child processes launched by the rogue ClipUp instance","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"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if `process.entity_id` is absent, recover children with `host.id` + `process.pid` in a tight alert-time window; an empty child search is unresolved, not benign.
+  - Implication: shells, script hosts, LOLBins, installers, or security-control tooling turn the alert into post-elevation execution. No visible child keeps the case scoped to the bypass launch, not closed.
+
+- Where else did this exact ClipUp pattern run?
+  - Focus: matching process starts by `process.hash.sha256`, `process.executable`, `process.parent.args`, and `process.Ext.token.elevation_level`, scoped by `host.id` and `user.id`.
+  - Hint: if the hash or elevation field is absent, pivot on the exact `process.executable` + `process.parent.args` pair and keep the time window tight. !{investigate{"description":"","label":"Process events for the same ClipUp path and COM interface","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"},{"excluded":false,"field":"process.parent.args","queryType":"phrase","value":"{{process.parent.args}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: after local evidence remains suspicious or unresolved, use matching path, hash, COM args, and elevation state to scope hosts or users; recurrence is supporting context, not a reason to close over contradictory local evidence.
+
+- Escalate when the COM-brokered non-system ClipUp launch pairs with attacker-defined identity, system-directory spoofing clues, unexpected elevation, or suspicious children. Close only when alert-local process evidence and supported child/history recovery bind to one confirmed servicing package or authorized OS-image test; require external confirmation when telemetry cannot prove that exact activity. Preserve evidence and escalate when answers remain mixed or incomplete.
 
 
 *False positive analysis*
 
 
-- Legitimate software updates or installations may trigger the rule if they temporarily use non-standard paths for ClipUp.exe. Verify the source and purpose of the process to determine if it is part of a legitimate update or installation.
-- Custom scripts or administrative tools that utilize ClipUp.exe from non-standard paths for legitimate purposes can cause false positives. Review the script or tool usage and consider excluding these specific paths if they are verified as safe.
-- Software testing environments where ClipUp.exe is executed from non-standard paths for testing purposes may trigger the rule. Implement exclusions for known testing environments to prevent unnecessary alerts.
-- Automated deployment tools that use ClipUp.exe from non-standard paths as part of their deployment process can be mistaken for malicious activity. Confirm the deployment tool's behavior and add exceptions for its known operations.
-- In environments where multiple users have administrative privileges, legitimate administrative actions might inadvertently match the rule's criteria. Regularly audit administrative actions and consider excluding known benign activities.
+- Windows edition upgrade, activation, or repair servicing can explain ClipUp activity only when evidence converges on one workflow: Microsoft-signed `process.hash.sha256`, expected `process.executable`, IEditionUpgradeManager `process.parent.args`, compatible `process.Ext.token.integrity_level_name` when present, and no suspicious children. If change records are unavailable, require telemetry confirmation from the same signed hash, path, parent args, `host.id`, and `user.id` pattern on the same host.
+- Treat non-System32 ClipUp as an operational anti-pattern outside servicing. The only other benign path is an authorized OS-image or lab test where `process.executable`, `process.hash.sha256`, `process.command_line`, `process.parent.executable`, `process.parent.args`, and `user.id` all match the exact test case. Any unsigned image, writable-profile path, or elevated child tooling contradicts this explanation.
+- Before creating an exception, require a stable benign pattern for `process.executable`, `process.hash.sha256`, `process.parent.args`, `process.Ext.token.integrity_level_name`, and relevant `host.id` or `user.id`. Avoid exceptions on `process.name`, `process.parent.name`, or the COM CLSID alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Terminate the ClipUp.exe process if it is running from a non-standard path to stop any ongoing malicious activity.
-- Conduct a thorough review of the system's recent activity logs to identify any additional unauthorized changes or suspicious behavior.
-- Restore any altered system files or configurations to their original state using known good backups or system restore points.
-- Update and patch the operating system and all installed software to the latest versions to mitigate known vulnerabilities.
-- Implement application whitelisting to prevent unauthorized programs from executing, focusing on blocking non-standard paths for critical system executables.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.
+- If confirmed benign, reverse temporary containment and record the image identity, broker context, token state, `host.id`, and `user.id` that proved the servicing or deployment workflow. Create an exception only after the same full pattern repeats benignly.
+- If suspicious but unconfirmed, preserve the alert, endpoint timeline export, process tree, non-system ClipUp path and hash, IEditionUpgradeManager parent context, token details, and recovered child-process evidence before containment.
+- If suspicious but unconfirmed, apply reversible containment tied to the findings: block the non-system ClipUp path or hash, end the associated user session when needed, or raise monitoring on the affected `host.id`. Isolate the host only if elevated children, control tampering, or broader suspicious process history raises impact.
+- If confirmed malicious, isolate the host, terminate the rogue ClipUp instance and elevated children after recording their process identifiers, and block the confirmed path or hash. Review the same hash, path, COM parent args, and user across other hosts before deleting artifacts.
+- Eradicate only the staged ClipUp copy, launched payloads, persistence, or launcher artifacts identified during the investigation, then restore affected controls and validate that the Windows servicing path uses the genuine System32 binary.
+- Post-incident hardening: restrict system-binary lookalikes from user-writable paths with WDAC or AppLocker, retain process lineage and token telemetry for elevated COM abuse, and document any missing telemetry or uncovered variant with the preserved evidence set.
+
+
+==== 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
 
diff --git a/docs/detections/prebuilt-rules/rule-details/uac-bypass-via-icmluautil-elevated-com-interface.asciidoc b/docs/detections/prebuilt-rules/rule-details/uac-bypass-via-icmluautil-elevated-com-interface.asciidoc
index 78270dc0ce..09631a5a9b 100644
--- a/docs/detections/prebuilt-rules/rule-details/uac-bypass-via-icmluautil-elevated-com-interface.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/uac-bypass-via-icmluautil-elevated-com-interface.asciidoc
@@ -23,7 +23,9 @@ Identifies User Account Control (UAC) bypass attempts via the ICMLuaUtil Elevate
 
 *Maximum alerts per execution*: 100
 
-*References*: None
+*References*: 
+
+* https://github.com/hfiref0x/UACME
 
 *Tags*: 
 
@@ -31,15 +33,13 @@ Identifies User Account Control (UAC) bypass attempts via the ICMLuaUtil Elevate
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Privilege Escalation
-* Tactic: Defense Evasion
-* Tactic: Execution
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
 * Data Source: Sysmon
 * Data Source: Microsoft Defender XDR
 * Resources: Investigation Guide
 
-*Version*: 214
+*Version*: 215
 
 *Rule authors*: 
 
@@ -55,47 +55,86 @@ Identifies User Account Control (UAC) bypass attempts via the ICMLuaUtil Elevate
 *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 UAC Bypass via ICMLuaUtil Elevated COM Interface*
 
 
-The ICMLuaUtil Elevated COM Interface is a Windows component that facilitates User Account Control (UAC) operations, allowing certain processes to execute with elevated privileges. Adversaries exploit this by invoking the interface to bypass UAC, executing malicious code stealthily. The detection rule identifies such attempts by monitoring processes initiated by `dllhost.exe` with specific arguments, excluding legitimate processes like `WerFault.exe`, thus flagging potential privilege escalation activities.
-
 
 *Possible investigation steps*
 
 
-- Review the process tree to identify the parent and child processes of the flagged `dllhost.exe` instance to understand the context of its execution.
-- Examine the command-line arguments of the `dllhost.exe` process to confirm the presence of the suspicious `/Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}` or `/Processid:{D2E7041B-2927-42FB-8E9F-7CE93B6DC937}` arguments.
-- Check for any recent changes or installations on the system that might have introduced the suspicious behavior, focusing on software that might interact with UAC settings.
-- Investigate the user account under which the `dllhost.exe` process was executed to determine if it has been compromised or if it has elevated privileges.
-- Correlate the event with other security logs or alerts from data sources like Sysmon or Microsoft Defender XDR to identify any related suspicious activities or patterns.
-- Assess the network activity of the affected system around the time of the alert to detect any potential data exfiltration or communication with known malicious IP addresses.
+- What did the auto-elevated COM broker launch?
+  - Focus: `process.name`, `process.executable`, `process.command_line`, `process.pe.original_file_name`, and `process.parent.args`.
+  - Implication: escalate when the CLSID-specific broker launched a shell, script host, LOLBin, installer, user-writable binary, or relaunched payload; lower suspicion when the child is a signed Windows or endpoint-management helper whose protected path and arguments fit one recognized servicing or support workflow.
+
+- Does the elevated child look like a stable trusted binary or a staged payload?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.Ext.relative_file_creation_time`.
+  - Implication: escalate when the child is unsigned, new, user-writable, renamed, hash-new, or PE-mismatched; lower suspicion only when identity, signer, age, and path fit a stable installed component.
+
+- Did the child receive an elevation state that changes risk for this user session?
+  - Focus: `process.Ext.token.integrity_level_name`, `process.Ext.token.elevation_level`, `process.Ext.authentication_id`, and `user.id`.
+  - Implication: escalate when a limited or interactive user context produced a high-integrity or full-elevation child without a matching maintenance task; lower suspicion when token and session align with a recognized elevated admin utility for the same user.
+
+- Which process initiated the brokered elevation behind `dllhost.exe`?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.effective_parent.executable`, and `process.Ext.effective_parent.name`.
+  - Hint: if effective-parent fields are absent or repeat `dllhost.exe`, recover broader lineage and keep origin attribution unresolved rather than treating the COM broker as the real launcher.
+  - Implication: escalate when the logical initiator is a script host, archive/temp path, renamed binary, remote-access tool, or unexplained user process; lower suspicion when it resolves to the same signed Windows or endpoint-management workflow as the child.
+
+- Did the elevated child spawn payloads, shells, or other post-elevation tools?
+  - Focus: child process events from `process.entity_id`, checking `process.name`, `process.executable`, `process.command_line`, and `process.parent.executable`. !{investigate{"description":"","label":"Child processes launched by the elevated child 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"}}
+  - Hint: if `process.entity_id` is absent, recover children with `host.id` plus `process.pid` in a tight alert-time window and treat PID reuse as ambiguous.
+  - Implication: escalate when the elevated child starts shells, script hosts, LOLBins, security-tool tampering, or payloads outside the recognized workflow; if no child process appears, scope the case to the broker launch rather than assuming the bypass failed.
+
+- If local evidence is suspicious or incomplete, does surrounding alert context expand scope?
+  - Focus: related alerts for `host.id`, especially privilege-escalation, defense-evasion, masquerading, suspicious child-process, or tampering findings tied to `process.parent.args` or `process.executable`. !{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"}}
+  - Hint: compare `user.id` alerts only to decide whether elevation is host-local or follows the user. !{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: pivot on same executable and COM parent arguments. !{investigate{"description":"","label":"Process events for the same child and COM interface","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"},{"excluded":false,"field":"process.parent.args","queryType":"phrase","value":"{{process.parent.args}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden response scope when the same host or user also shows UAC-bypass, masquerading, or post-elevation execution; keep scope local when surrounding alerts are clean and broker, child, token, and follow-on evidence are coherent.
+
+- What disposition do the broker, child identity, launcher, token, follow-on activity, and scope support?
+  - Escalate on unauthorized brokered CLSID launch, child identity, launcher, token, child-process, or alert-scope evidence; close only when alert-local and recovered process evidence bind one exact recognized workflow with no contradictory follow-on activity; preserve and escalate on mixed or incomplete evidence.
 
 
 *False positive analysis*
 
 
-- Legitimate software updates or installations may trigger the rule if they use the ICMLuaUtil Elevated COM Interface for necessary elevation. Users can monitor the specific software involved and create exceptions for trusted applications.
-- System maintenance tasks initiated by IT administrators might use similar processes for legitimate purposes. Identifying these tasks and excluding them from the rule can reduce false positives.
-- Certain enterprise applications may require elevated privileges and use the same COM interface. Regularly review and whitelist these applications to prevent unnecessary alerts.
-- Automated scripts or tools used for system management that invoke the interface should be evaluated. If deemed safe, they can be added to an exclusion list to avoid repeated false positives.
-- Regularly update the list of excluded processes to reflect changes in the organization's software environment, ensuring that only non-threatening behaviors are excluded.
+- Legitimate closure is narrow: signed Windows or enterprise endpoint-management helpers may use the elevated COM broker during servicing or support. Align identity (`process.executable`, signer, hash, and PE original name), broker context (`process.parent.args` and effective parent), token state, and absence of contradictory child-process or alert-scope evidence. Recently staged helpers also need `process.Ext.relative_file_creation_time`, hash or signer, parent context, and command line to fit the same update workflow; require outside confirmation when telemetry cannot explain the elevation.
+- If workflow context is unavailable, recurrence for the same `host.id` or `user.id` can support the conclusion but cannot override contradictory local evidence.
+- Before creating an exception, validate that child identity, signer or hash, `process.parent.args`, token state, and host or user scope stay stable across benign occurrences. Build the exception from that minimum confirmed pattern, and avoid exceptions on `process.parent.name`, `dllhost.exe`, or CLSID values alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Terminate any suspicious processes initiated by `dllhost.exe` with the specified arguments to stop the execution of potentially malicious code.
-- Conduct a thorough review of the affected system to identify any unauthorized changes or additional malicious files, and remove them.
-- Restore the system from a known good backup if any critical system files or configurations have been altered.
-- Update and patch the operating system and all installed software to mitigate any known vulnerabilities that could be exploited for UAC bypass.
-- Implement application whitelisting to prevent unauthorized applications from executing, focusing on blocking the execution of `dllhost.exe` with suspicious arguments.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network.
+- First, export the alert details, process tree, command line, hash/signature identity, token state, effective-parent evidence, and recovered child-process or related-alert records.
+- If confirmed benign after preservation, reverse temporary containment and document the validated child identity, broker CLSID, effective parent, token state, `host.id`, and `user.id` values that proved the workflow. Create an exception only after the same complete pattern repeats benignly.
+- If suspicious but unconfirmed, apply reversible containment tied to the finding: block the suspicious `process.executable`, end the associated user session, or raise monitoring on the same `host.id`. Use host isolation only when the elevated child spawned payloads or coincided with tampering or lateral-movement evidence.
+- If confirmed malicious, isolate the host when needed to prevent lateral movement, then terminate the elevated child and payloads using the preserved `process.entity_id`, `process.hash.sha256`, command line, broker CLSID, token state, and `@timestamp`. If direct response is unavailable, hand off the preserved process, child-process, and scope evidence to the response team.
+- Review other hosts and users for the same `process.parent.args`, `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, or `user.id` before removing artifacts so scoping completes before evidence is destroyed.
+- Eradicate only the staged helper binary, launched payloads, persistence changes, and launcher artifacts identified during the investigation, then restore affected controls and service configuration to a known-good state.
+- Post-incident hardening: reduce local administrator membership where possible, set UAC to the highest practical enforcement level, restrict system lookalike or helper binaries from user-writable paths, prefer WDAC or AppLocker coverage for admin helpers, and retain process telemetry around elevated COM abuse.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
+
+Setup instructions: https://ela.st/install-elastic-defend
+
+
+*Additional data sources*
+
+
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
+
+- https://ela.st/m365-defender[Microsoft Defender XDR]
+- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation]
+
 
 ==== Rule query
 
@@ -105,7 +144,8 @@ The ICMLuaUtil Elevated COM Interface is a Windows component that facilitates Us
 process where host.os.type == "windows" and event.type == "start" and
  process.parent.name == "dllhost.exe" and
  process.parent.args in ("/Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}", "/Processid:{D2E7041B-2927-42FB-8E9F-7CE93B6DC937}") and
- process.pe.original_file_name != "WerFault.exe"
+ process.pe.original_file_name != "WerFault.exe" and
+ not (process.executable : "?:\\Program Files\\WireGuard\\wireguard.exe" and process.args : "/installmanagerservice")
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/untrusted-driver-loaded.asciidoc b/docs/detections/prebuilt-rules/rule-details/untrusted-driver-loaded.asciidoc
index 177d9bca02..f160ddc4e9 100644
--- a/docs/detections/prebuilt-rules/rule-details/untrusted-driver-loaded.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/untrusted-driver-loaded.asciidoc
@@ -1,7 +1,7 @@
 [[untrusted-driver-loaded]]
 === Untrusted Driver Loaded
 
-Identifies attempt to load an untrusted driver. Adversaries may modify code signing policies to enable execution of unsigned or self-signed code.
+Identifies an untrusted driver loaded by the Windows kernel. Adversaries may modify code signing policies to enable execution of unsigned or self-signed kernel code.
 
 *Rule type*: eql
 
@@ -33,7 +33,7 @@ Identifies attempt to load an untrusted driver. Adversaries may modify code sign
 * Resources: Investigation Guide
 * Data Source: Elastic Defend
 
-*Version*: 13
+*Version*: 14
 
 *Rule authors*: 
 
@@ -53,68 +53,79 @@ Identifies attempt to load an untrusted driver. Adversaries may modify code sign
 *Investigating Untrusted Driver Loaded*
 
 
-Microsoft created the Windows Driver Signature Enforcement (DSE) security feature to prevent drivers with invalid signatures from loading and executing into the kernel (ring 0). DSE aims to protect systems by blocking attackers from loading malicious drivers on targets. 
 
-This protection is essential for maintaining system security. However, attackers or administrators can disable DSE and load untrusted drivers, which can put the system at risk. Therefore, it's important to keep this feature enabled and only load drivers from trusted sources to ensure system integrity and security.
+*Possible investigation steps*
 
-This rule identifies an attempt to load an untrusted driver, which effectively means that DSE was disabled or bypassed. This can indicate that the system was compromised.
 
-> **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.
+- What exact kernel driver loaded, and what trust failure made it alert?
+  - Focus: `process.pid`, `dll.path`, `dll.code_signature.exists`, `dll.code_signature.trusted`, and `dll.code_signature.status`.
+  - Implication: escalate when System loaded an unsigned or untrusted driver from a non-vendor, user-writable, temp, or renamed path; lower concern only when the trust failure fits a controlled driver-development or hardware-validation host class.
 
+- Does the driver identity map to a known vulnerable driver, BYOVD chain, or offensive loader?
+  - Why: TDL-style and BYOVD activity may be easier to recognize by stable hash, original PE name, or signer than current file name.
+  - Focus: `dll.hash.sha256`, `dll.pe.original_file_name`, `dll.code_signature.subject_name`, and `dll.code_signature.thumbprint_sha256`.
+  - Implication: escalate when hash, original name, or signer maps to a vulnerable-driver blocklist, signature-bypass loader, or malicious kernel tooling; lower concern only when the same artifact is tied to a controlled lab or validation cohort.
 
-*Possible investigation steps*
+- Does recency or rename timing show the driver was staged for this load?
+  - Focus: `dll.Ext.relative_file_creation_time`, `dll.Ext.relative_file_name_modify_time`, and `dll.path`; if file-event telemetry is available, use the same `host.id` and path to identify who wrote or renamed it. !{investigate{"description":"","label":"File events for the loaded driver path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{dll.path}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the driver appeared just before load, was recently renamed, or was written by an unrelated staging process. Missing file-event telemetry leaves provenance unresolved, not benign.
+
+- What resident service or device identity is tied to the loaded image?
+  - Focus: compare `dll.path`, `dll.hash.sha256`, and `dll.code_signature.subject_name` with current Osquery driver inventory and service output.
+  - Hint: For non-Microsoft drivers by `image`, `service`, `signed`, `subject_name`, and `VtLink`; use it as current-state context, and keep the alert as the historical load record if no matching image exists.
+    - !{osquery{"label":"Osquery - Retrieve All Non-Microsoft Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE NOT (provider == \"Microsoft\" AND signed == \"1\")\n"}}
+  - Hint: For unsigned current drivers when the alert shows missing or untrusted signature metadata; current signed or service values do not prove what existed at `@timestamp`.
+    - !{osquery{"label":"Osquery - Retrieve All Unsigned Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE signed == \"0\"\n"}}
+  - Implication: escalate when current inventory lacks a coherent image or service entry, the service is unexpected for the host, or other unsigned drivers do not fit the host role. Treat osquery as corroboration; do not delay escalation when alert-local identity, trust, or recency evidence is decisive.
 
+- Did signing or code-integrity control activity make this load possible?
+  - Why: 64-bit Windows normally enforces kernel-mode driver signing, while test-signing, DSE tampering, or vulnerable-driver loaders can open a path for untrusted kernel code.
+  - Focus: same-host process events around the load using `host.id`, `process.name`, `process.executable`, and `process.command_line` for bcdedit test-signing/nointegritychecks changes or known vulnerable-driver loader activity. !{investigate{"description":"","label":"Process events on the driver host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when surrounding process evidence shows test-signing changes, code-integrity bypass tooling, or vulnerable-driver loader execution; absent process evidence weakens this corroborator but does not clear an unexplained untrusted driver load.
 
-- Examine the driver loaded to identify potentially suspicious characteristics. The following actions can help you gain context:
-  - Identify the path that the driver was loaded from. If you're using Elastic Defend, path information can be found in the `dll.path` field.
-  - Examine the file creation and modification timestamps:
-    - On Elastic Defend, those can be found in the `dll.Ext.relative_file_creation_time` and `dll.Ext.relative_file_name_modify_time` fields. The values are in seconds.
-    - Search for file creation events sharing the same file name as the `dll.name` field and identify the process responsible for the operation.
-      - Investigate any other abnormal behavior by the subject process, such as network connections, registry or file modifications, and any spawned child processes.
-  - Use the driver SHA-256 (`dll.hash.sha256` field) hash value to search for the existence and reputation in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
-- 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.
-- Use Osquery to investigate the drivers loaded into the system.
-  - !{osquery{"label":"Osquery - Retrieve All Non-Microsoft Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE NOT (provider == \"Microsoft\" AND signed == \"1\")\n"}}
-  - !{osquery{"label":"Osquery - Retrieve All Unsigned Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE signed == \"0\"\n"}}
-- Identify the driver's `Device Name` and `Service Name`.
-- Check for alerts from the rules specified in the `Related Rules` section.
+- Does the host cohort and prevalence fit a controlled driver workflow?
+  - Focus: `host.id`, `host.name`, and the smallest stable indicator, usually `dll.hash.sha256`, `dll.path`, or `dll.code_signature.subject_name`.
+  - Hint: broaden only when identity, recency, inventory, or tampering evidence remains suspicious or unresolved. !{investigate{"description":"","label":"Alerts associated with the driver identity","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"dll.hash.sha256","queryType":"phrase","value":"{{dll.hash.sha256}}","valueType":"string"}],[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"dll.path","queryType":"phrase","value":"{{dll.path}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: escalate when the driver appears on production systems, user-writable paths, unrelated hosts, or outside the expected lab cohort; lower concern only when artifact, path pattern, signer, and host cohort consistently match a controlled validation workflow.
+
+- Using identity, trust failure, staging/provenance, osquery inventory, signing-control evidence, and host-cohort spread: escalate unauthorized kernel code, BYOVD, or signature-bypass evidence; close only when telemetry binds the load to one controlled driver workflow; preserve artifacts and escalate mixed or incomplete cases.
 
 
 *False positive analysis*
 
 
-- This activity should not happen legitimately. The security team should address any potential benign true positive (B-TP), as this configuration can put the user and the domain at risk.
+- Controlled driver-development, OEM hardware validation, and authorized security or EDR compatibility testing can load test-signed or unsigned drivers on isolated lab hosts. Confirm first with telemetry: `dll.hash.sha256`, `dll.path`, `dll.code_signature.status` or `dll.code_signature.subject_name`, current osquery image and service output, and `host.id` cohort must align with one workflow. Use build, test, or change records only after telemetry binds the exact artifact and cohort; if unavailable, require prior alerts for the same driver artifact and host cohort before exceptioning. If any evidence dimension contradicts the workflow, do not close as benign.
+- Build exceptions only from the minimum confirmed pattern, such as `dll.hash.sha256` plus `dll.path` plus bounded `host.id` cohort or service identity. Avoid exceptions on `dll.name`, signer, or generic unsigned-driver conditions alone.
+
 
+*Response and remediation*
 
-*Related Rules*
 
+- If confirmed benign:
+  - Reverse temporary containment and document the driver artifact, host cohort, current osquery image and service values, and any corroborating external record. Keep exceptions narrow to the confirmed hash, path, host cohort, or service identity.
+- If suspicious but unconfirmed:
+  - Preserve the driver file if accessible, the alert event export, osquery driver inventory results, surrounding signing-control process events, and the case timeline before containment or cleanup.
+  - Apply reversible containment first, such as temporary network restriction or heightened monitoring, while scoping the same `dll.hash.sha256` or `dll.path` across other hosts.
+  - Escalate to host isolation before reboot, uninstall, or cleanup only if evidence shows code-integrity tampering, vulnerable-driver loader activity, post-load abuse, or spread outside the expected lab cohort.
+- If confirmed malicious:
+  - Isolate the host after preserving the driver artifact, service or boot-start context, signing-control evidence, and affected `host.id` or `host.name`. If endpoint response is unavailable, hand off that evidence set to the team that can contain the system.
+  - Scope other hosts for the same `dll.hash.sha256`, `dll.path`, or `dll.code_signature.subject_name` before uninstalling the driver, deleting the file, removing the backing service, or rebooting.
+  - Remove the malicious driver, related service or boot-start entry, and code-signing or DSE changes identified during investigation, then remediate the loader or vulnerable-driver path that introduced it.
+- Post-incident hardening:
+  - Re-enable or enforce driver-signing and code-integrity controls on the affected host class, block confirmed malicious or vulnerable `dll.hash.sha256` values and `dll.path` locations, and restrict test-signing to isolated lab systems.
+  - Document any BYOVD family, loader service name, or host-cohort pattern uncovered during triage for future response cases.
 
-- First Time Seen Driver Loaded - df0fd41e-5590-4965-ad5e-cd079ec22fa9
-- Code Signing Policy Modification Through Registry - da7733b1-fe08-487e-b536-0a04c6d8b0cd
-- Code Signing Policy Modification Through Built-in tools - b43570de-a908-4f7f-8bdb-b2df6ffd8c80
 
+==== Setup
+
+
+
+*Setup*
 
-*Response and remediation*
 
+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.
 
-- Initiate the incident response process based on the outcome of the triage.
-- Isolate the involved host to prevent further post-compromise behavior.
-- Disable and uninstall all suspicious drivers found in the system. This can be done via Device Manager. (Note that this step may require you to boot the system into Safe Mode.)
-- Remove the related services and registry keys found in the system. Note that the service will probably not stop if the driver is still installed.
-  - This can be done via PowerShell `Remove-Service` cmdlet.
-- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
-- 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.
-- Ensure that the Driver Signature Enforcement is enabled on the system.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
-- 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 instructions: https://ela.st/install-elastic-defend
 
 
 ==== Rule query
@@ -124,7 +135,16 @@ This rule identifies an attempt to load an untrusted driver, which effectively m
 ----------------------------------
 driver where host.os.type == "windows" and process.pid == 4 and
   (dll.code_signature.trusted == false or dll.code_signature.exists == false) and
-  not dll.code_signature.status : ("errorExpired", "errorRevoked", "errorCode_endpoint:*")
+  /* errorExpired and errorRevoked are handled by d12bac54-ab2a-4159-933f-d7bcefa7b61d */
+  not dll.code_signature.status : ("errorExpired", "errorRevoked", "errorCode_endpoint:*") and
+  
+  /* HP DOT4 printer driver family FPs (Dot4.sys, Dot4Prt.sys, Dot4usb.sys, Dot4Scan.sys) */
+  not dll.hash.sha256 : (
+        "f21c1d478180bc5e932bb2c2e4618e3ed463ca87acedeb139682d218435f82f1",
+        "7e2f2a139e897eae56038b920bda9381094bc0ae9e626f6634e6b444b8b0c91f",
+        "12ffdf5f48a79b1b4adbb88ba2cb6c59dd6719554e8ea6beefe99b3e3c66f1ac",
+        "dbc6afaf80141e2480e19878f581edfe9c2b018da2ec527c4025ff04d5587afd"
+  )
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-child-process-of-dns-exe.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-child-process-of-dns-exe.asciidoc
index d8a64ffaae..e95d1911b2 100644
--- a/docs/detections/prebuilt-rules/rule-details/unusual-child-process-of-dns-exe.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/unusual-child-process-of-dns-exe.asciidoc
@@ -50,7 +50,7 @@ Identifies an unexpected process spawning from dns.exe, the process responsible
 * Data Source: SentinelOne
 * Data Source: Crowdstrike
 
-*Version*: 319
+*Version*: 320
 
 *Rule authors*: 
 
@@ -70,43 +70,79 @@ Identifies an unexpected process spawning from dns.exe, the process responsible
 *Investigating Unusual Child Process of dns.exe*
 
 
-SIGRed (CVE-2020-1350) is a wormable, critical vulnerability in the Windows DNS server that affects Windows Server versions 2003 to 2019 and can be triggered by a malicious DNS response. Because the service is running in elevated privileges (SYSTEM), an attacker that successfully exploits it is granted Domain Administrator rights. This can effectively compromise the entire corporate infrastructure.
-
-This rule looks for unusual children of the `dns.exe` process, which can indicate the exploitation of the SIGRed or a similar remote code execution vulnerability in the DNS server.
-
-
 *Possible investigation steps*
 
 
-- Investigate the process execution chain (parent process tree) for unknown processes.
-  - Any suspicious or abnormal child process spawned from dns.exe should be carefully reviewed and investigated. It's impossible to predict what an adversary may deploy as the follow-on process after the exploit, but built-in discovery/enumeration utilities should be top of mind (`whoami.exe`, `netstat.exe`, `systeminfo.exe`, `tasklist.exe`).
-  - Built-in Windows programs that contain capabilities used to download and execute additional payloads should also be considered. This is not an exhaustive list, but ideal candidates to start out would be: `mshta.exe`, `powershell.exe`, `regsvr32.exe`, `rundll32.exe`, `wscript.exe`, `wmic.exe`.
-  - If a denial-of-service (DoS) exploit is successful and DNS Server service crashes, be mindful of potential child processes related to `werfault.exe` occurring.
-- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes.
-- Investigate other alerts associated with the host during the past 48 hours.
-- Check whether the server is vulnerable to CVE-2020-1350.
-- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
+- What did "dns.exe" launch, and does that define a crash path or live execution path?
+  - Focus: `process.name`, `process.executable`, `process.command_line`, and `process.parent.executable`.
+  - Implication: escalate quickly for shells, script hosts, downloaders, service tools, or non-Windows paths spawned by "dns.exe"; a bounded "WerFault.exe" crash-reporting child points toward DNS service fault or SIGRed DoS, but still needs follow-on checks.
+- Is the child binary a recognized system or DNS-support component, or a disguised payload?
+  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the child is unsigned, renamed, user-writable, newly seen, or PE-mismatched; a recognized Microsoft or vendor identity lowers only identity concern and does not clear unexpected execution from "dns.exe".
+- What intent does the child command line express?
+  - Focus: `process.command_line`, `process.name`, and `process.Ext.token.integrity_level_name`.
+  - Implication: escalate for discovery, script interpretation, download, service change, credential, or persistence behavior under the DNS service token; crash-reporting or bounded diagnostic arguments support fault handling.
+- Do lineage and session context fit the Windows DNS service?
+  - Focus: `process.parent.command_line`, `process.parent.entity_id`, `process.Ext.session_info.logon_type`, and `user.id`.
+  - Implication: escalate when parent, service, or user context does not fit a stable Windows DNS service launch; expected service lineage supports but does not prove a benign child.
+- Did the child produce follow-on execution or artifacts after the spawn?
+  - Focus: recovered file, registry, network, DNS, and descendant process events for `host.id` + child `process.entity_id`, or `host.id` + `process.pid` in a tight alert window.
+    - !{investigate{"description":"","label":"File and registry events for the same child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Network events for the same child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Child process events from the dns.exe child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: prioritize descendant `process.command_line`, `file.path`, `registry.path`, and `destination.ip`. Missing network telemetry is unresolved, not benign.
+  - Implication: escalate when recovered events show descendants, payload staging, persistence changes, or outbound activity; no follow-on activity supports a crash-only hypothesis but cannot clear the alert alone.
+- If local evidence remains suspicious or unresolved, do same-host alerts show the same DNS-service execution pattern?
+  - Focus: same-parent process starts and related alerts on `host.id`, prioritizing `process.parent.name` of "dns.exe", the same child `process.executable`, or the same `process.hash.sha256`.
+    - !{investigate{"description":"","label":"Process events from the same dns.exe parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","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"}}
+  - Hint: broaden scope only after child identity, command intent, lineage, or follow-on recovery remains suspicious or incomplete.
+  - Implication: escalate scope when related alerts repeat the "dns.exe" child pattern or child binary identity; unrelated or nonmatching alerts keep the case narrower.
+- Escalate for live execution intent, suspicious identity or lineage, or recovered post-exploitation artifacts; close only when evidence tightly binds one crash-handling or recognized DNS-support workflow on this host; preserve artifacts and escalate when evidence is mixed or incomplete.
 
 
 *False positive analysis*
 
 
-- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+- Crash handling can legitimately produce "WerFault.exe" after a DNS service fault or SIGRed DoS attempt. Confirm that child identity, `process.command_line`, signer, and `host.id` form a crash-reporting pattern and recovered follow-on endpoint activity does not contradict it. Use incident records only as corroboration; telemetry-only closure requires a crash-reporter-only pattern on the same `host.id` without payload descendants or artifact creation.
+- Named DNS/security tooling, such as ReasonLabs DNS components in the rule exclusions, explains the alert only when exact `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `process.parent.executable`, and `host.id` match that product workflow. Treat generic vendor claims, partial matches, or a trusted signer without matching behavior as unresolved.
+- Before creating an exception, anchor it on exact child path, signer or certificate thumbprint when available, command line, parent DNS service path, and affected `host.id`. Avoid exceptions on `process.parent.name` of "dns.exe", `process.name` alone, or the entire host.
 
 
 *Response and remediation*
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Isolate the involved hosts to prevent further post-compromise behavior.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
-- Reimage the host operating system or restore the compromised server to a clean state.
-- Install the latest patches on systems that run Microsoft DNS Server.
-- Consider the implementation of a patch management system, such as the Windows Server Update Services (WSUS).
-- 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.
-- Review the privileges assigned to the user to ensure that the least privilege principle is being followed.
-- 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).
+- If suspicious but unconfirmed, preserve the child `process.entity_id`, `process.executable`, `process.hash.sha256`, signer details, `process.command_line`, `process.parent.command_line`, crash dumps, recovered endpoint events, and any collected payload artifacts before containment.
+- Apply reversible containment before destructive action: remove the server from DNS rotation, restrict external resolver exposure, or heighten monitoring on the affected `host.id`. Move to host isolation only when follow-on execution or broader compromise evidence shows the server cannot serve safely.
+- If confirmed benign, reverse temporary containment and record the exact child path, signer, command line, parent DNS service path, and `host.id` that proved the crash-handling or DNS-support workflow. Create an exception only after the same pattern is stable across prior alerts.
+- If confirmed malicious, weigh DNS/domain-controller criticality, then isolate the server when feasible, terminate the suspicious child and descendants after evidence capture, and block confirmed malicious domains, IPs, hashes, or payload paths identified during triage.
+- Scope other DNS servers and domain controllers for the same child path, hash, command line, signer, or "dns.exe" child-process pattern before deleting artifacts or rebuilding systems.
+- Eradicate only payloads, persistence changes, or malicious child processes identified during the investigation, restore DNS service configuration from known-good state, and reset credentials only if evidence shows credential exposure or lateral movement from the server.
+- Post-incident hardening: apply the Microsoft DNS security update for CVE-2020-1350, remove temporary SIGRed workarounds only after patching is verified, and retain process plus file, registry, and network telemetry for DNS servers where gaps limited 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/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
@@ -118,9 +154,11 @@ process where host.os.type == "windows" and event.type == "start" and
   process.parent.name : "dns.exe" and
   not process.executable : (
     "?:\\Windows\\System32\\conhost.exe",
+    "?:\\Windows\\System32\\dns.exe",
 
     /* Crowdstrike specific exclusion as it uses NT Object paths */
     "\\Device\\HarddiskVolume*\\Windows\\System32\\conhost.exe",
+    "\\Device\\HarddiskVolume*\\Windows\\System32\\dns.exe",
     "\\Device\\HarddiskVolume*\\Program Files\\ReasonLabs\\*"
   ) and
   not ?process.parent.executable : "?:\\Program Files\\ReasonLabs\\DNS\\ui\\DNS.exe"
diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-execution-via-microsoft-common-console-file.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-execution-via-microsoft-common-console-file.asciidoc
index 500a7c02cd..8991503033 100644
--- a/docs/detections/prebuilt-rules/rule-details/unusual-execution-via-microsoft-common-console-file.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/unusual-execution-via-microsoft-common-console-file.asciidoc
@@ -42,7 +42,7 @@ Identifies the execution of a child process from a Microsoft Common Console file
 * Data Source: Microsoft Defender XDR
 * Data Source: SentinelOne
 
-*Version*: 207
+*Version*: 208
 
 *Rule authors*: 
 
@@ -62,27 +62,75 @@ Identifies the execution of a child process from a Microsoft Common Console file
 *Investigating Unusual Execution via Microsoft Common Console File*
 
 
-- Investigate the source of the MSC file.
-- Investigate the process execution chain (all spawned child processes and their descendants).
-- Investigate the process and it's descendants network and file events.
-- 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.
+
+*Possible investigation steps*
+
+
+- What ".msc" path and immediate child process triggered the alert?
+  - Focus: `process.parent.executable`, `process.parent.args`, `process.parent.command_line`, `process.executable`, and `process.command_line`.
+  - Implication: escalate when "mmc.exe" opens a user-writable, download, cloud-sync, archive-extraction, or document-like ".msc" and the child is a shell, script host, "mshta.exe", "schtasks.exe", or another LOLBin; lower suspicion only when the exact ".msc" path and child command fit a recognized administrative console workflow on this host.
+
+- Does the child command line expose second-stage or persistence intent?
+  - Focus: `process.command_line`, checking for "WScript.Shell", "schtasks /create", "OneDriveUpdate", "wscript.exe /b", "start /min", "mshta", ".hta", remote URLs, or script/batch names.
+  - Hint: review same-child file and network events for staged scripts, task artifacts, or remote retrieval. Missing network telemetry is unresolved, not benign. !{investigate{"description":"","label":"File and network events for the MMC-launched child","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.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the command creates tasks, hides/minimizes execution, starts script hosts, or embeds remote retrieval; lower suspicion only when the arguments perform a narrow helper action expected from the same console.
+
+- Does the child identity and session context fit expected administration?
+  - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.Ext.relative_file_creation_time`, and the `user.id` + `host.id` pair.
+  - Implication: escalate when the child runs from a user-writable or recently created path, has a signer mismatch, or appears under an unexpected administrative user/session; identity confirmation alone never clears an unsafe command line.
+
+- Do descendants continue the MSC-launched chain into scripting, tasks, or delayed execution?
+  - Why: MSC lures can store task commands that create a scheduled task, run VBS, then launch HTA through "mshta.exe"; the first child may be only the handoff.
+  - Focus: descendant starts on the same `host.id`, linked by `process.parent.entity_id` or `process.Ext.ancestry`, checking `process.name` and `process.command_line`. !{investigate{"description":"","label":"Descendant processes from the MMC-launched child","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"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: if entity linkage is absent, match `process.parent.pid` to the alerting `process.pid` within a tight alert-time window and treat matches as weaker.
+  - Hint: after a suspicious descendant, expand that descendant's file and network events from Timeline.
+  - Implication: escalate when descendants show "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe", "powershell.exe", "pwsh.exe", "schtasks.exe", repeated shells, Microsoft-themed task names, or command-line URLs; lower suspicion when the tree ends at one expected helper with no delayed script or task process.
+
+- If local evidence remains suspicious or unresolved, what related alerts change scope or containment?
+  - Focus: related alerts for the same `user.id`, especially document delivery, script execution, task creation, or outbound 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: review same-`host.id` alerts to separate one-host lure execution from repeated activity across assets. !{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 containment when the same user or host also shows initial-access, script-host, scheduled-task, or outbound-staging alerts; keep response local when those alerts are absent, but leave benign closure to the process-chain synthesis.
+
+- Escalate for lure-driven ".msc" execution, script staging, scheduled-task creation, remote retrieval, or suspicious descendants; close only when alert-local evidence and process recovery bind one exact recognized console workflow with no contradictory descendants; preserve artifacts and escalate when evidence is mixed or visibility incomplete.
+
+
+*False positive analysis*
+
+
+- Custom administrative consoles, vendor MMC snap-ins, or IT troubleshooting bundles stored outside default Windows console paths can launch helpers, browsers, viewers, or support utilities. Confirm that `process.parent.args`, `process.parent.command_line`, `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `user.id`, and `host.id` all align with one exact console package or affected cohort. If inventory, ticketing, or owner confirmation is unavailable, close only when process and descendant telemetry still prove that helper workflow with no unresolved script, task, hidden execution, or remote-retrieval behavior.
+- Before creating an exception, validate prior alerts from this rule for the same ".msc" path in `process.parent.args`, child `process.executable`, signer in `process.code_signature.subject_name`, stable `process.command_line`, and bounded `user.id` and `host.id` scope. Build the exception from that full workflow pattern; avoid exceptions on `process.parent.name` value "mmc.exe" or the child `process.executable` alone.
 
 
 *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).
+
+- If confirmed benign, reverse any temporary containment and document the exact ".msc" path, child command pattern, signer, `user.id`, and `host.id`. Create an exception only after the same workflow pattern recurs consistently across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve a case export for the alerting process instance (`host.id` plus `process.entity_id` or `process.pid` and alert time), the parent MSC path, child and descendant command lines, executable hash/signer, task names, script names, and URLs visible in command lines before making destructive changes. Apply reversible containment first, such as temporary URL/domain blocking, disabling a newly created scheduled task after preserving its command, or heightened monitoring on the affected `host.id` and `user.id`.
+- If confirmed malicious, isolate the host or contain the affected account only after preserving the process chain, scheduled-task names, script names, hashes, and command-line indicators. Terminate malicious child or descendant processes after preservation, block confirmed command-line URLs or domains, and hand off the preserved artifact set if endpoint response is unavailable.
+- Eradicate only the malicious ".msc", scripts, scheduled tasks, and staged payloads identified during the investigation, then remediate the delivery path that let the lure execute. Review related hosts and users for the same `process.parent.args` path or descendant `process.command_line` pattern before broad cleanup.
+- Post-incident hardening: restrict or warn on ".msc" launches from user-writable, download, archive-extraction, or cloud-sync paths, and retain process lineage and command-line telemetry needed to distinguish future admin consoles from MSC lures.
+
+
+==== 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
diff --git a/docs/detections/prebuilt-rules/rule-details/user-added-to-the-admin-group.asciidoc b/docs/detections/prebuilt-rules/rule-details/user-added-to-the-admin-group.asciidoc
index 215372033b..67785c8965 100644
--- a/docs/detections/prebuilt-rules/rule-details/user-added-to-the-admin-group.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/user-added-to-the-admin-group.asciidoc
@@ -33,7 +33,7 @@ Identifies users being added to the admin group. This could be an indication of
 * Data Source: Jamf Protect
 * Resources: Investigation Guide
 
-*Version*: 5
+*Version*: 6
 
 *Rule authors*: 
 
@@ -51,17 +51,13 @@ Identifies users being added to the admin group. This could be an indication of
 
 To thoroughly investigate the actions that occurred **after a user was elevated to administrator**, it's essential to conduct a search on the Timeline. This allows you to review and understand the sequence of events that followed the elevation, helping to identify any potentially malicious or unauthorized activities that might have taken place. **Analyzing these actions is crucial for maintaining security and ensuring that the elevation was not exploited for harmful purposes.**
 
-> **Note**:
-> 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.
-
 **Consider reviewing these actions:**
 
 - Have persistency items been added?
 - Is any software installed after elevation?
 - Were any additional users created after elevation?
 
-!{investigate{"label":"Show events after Privilege Escalation","providers":[[{"excluded":false,"field":"host.hostname","queryType":"phrase","value":"{{host.hostname}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now+30m"}}
-!{investigate{"label":"Show events having the same reponsible process","providers":[[{"excluded":false,"field":"host.hostname","queryType":"phrase","value":"{{host.hostname}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.group_leader.entity_id}}","valueType":"string"}]]}}
+!{investigate{"label":"Show events having the same responsible process","providers":[[{"excluded":false,"field":"host.hostname","queryType":"phrase","value":"{{host.hostname}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.group_leader.entity_id}}","valueType":"string"}]]}}
 !{investigate{"label":"Show events having the same parent process","providers":[[{"excluded":false,"field":"host.hostname","queryType":"phrase","value":"{{host.hostname}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]]}}
 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc b/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc
index aa2b5d669d..d3b44fab96 100644
--- a/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc
@@ -44,7 +44,7 @@ Identifies use of vssadmin.exe for shadow copy deletion or resizing on endpoints
 * Data Source: SentinelOne
 * Data Source: Crowdstrike
 
-*Version*: 317
+*Version*: 318
 
 *Rule authors*: 
 
@@ -64,66 +64,79 @@ Identifies use of vssadmin.exe for shadow copy deletion or resizing on endpoints
 *Investigating Volume Shadow Copy Deleted or Resized via VssAdmin*
 
 
-The Volume Shadow Copy Service (VSS) is a Windows feature that enables system administrators to take snapshots of volumes that can later be restored or mounted to recover specific files or folders.
 
-A typical step in the playbook of an attacker attempting to deploy ransomware is to delete Volume Shadow Copies to ensure that victims have no alternative to paying the ransom, making any action that deletes shadow copies worth monitoring.
+*Possible investigation steps*
 
-This rule monitors the execution of Vssadmin.exe to either delete or resize shadow copies.
 
+- What recovery-inhibition path does the alert-local command express?
+  - Focus: `process.command_line` and `process.args`; separate "delete shadows" with "/all", "/quiet", "/for=", "/oldest", or "/shadow=" from "resize shadowstorage" with "/for=", "/on=", and "/maxsize=".
+  - Implication: escalate faster when the command deletes all shadows, suppresses prompts, targets broad restore scope, or forces a tiny maximum; lower suspicion when it targets one volume, one shadow ID, or capacity-aligned resize inside a recognized retention, storage, or reset workflow.
 
-*Possible investigation steps*
+- Is the VssAdmin binary identity consistent with the tool being invoked?
+  - Focus: `process.executable`, `process.pe.original_file_name`, and, when available, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when path, PE metadata, hash, signer, or trust does not fit Microsoft VssAdmin; lower suspicion when identity matches the expected Microsoft tool, but identity never clears broad deletion or forced shrinkage.
+
+- Does the launcher and account explain why VssAdmin changed shadow-copy state?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, `user.name`, and `user.domain`.
+  - Implication: escalate when Office, a browser, script host, remote-access tool, or unusual account launches the command; lower suspicion when the parent and account match the same backup agent, deployment runner, storage-management console, image-prep script, or lab-reset workflow.
+
+- Are surrounding process events part of the same recovery-inhibition or impact chain?
+  - Why: destructive operators often pair VssAdmin with recovery tampering ("wmic shadowcopy delete", "diskshadow", "wbadmin delete catalog", "bcdedit recoveryenabled no", "reagentc /disable"), service stops, or encryption launchers.
+  - Focus: same-parent starts by `host.id` plus `process.parent.entity_id`; compare `process.name`, `process.command_line`, parent context, and timing. !{investigate{"description":"","label":"Process events from the same parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Range: start with the alert window through the next 15 minutes; expand only if the same lineage shows recovery tampering or encryption prep.
+  - Implication: escalate when the same lineage or short window shows backup deletion, recovery disablement, service stops, security-tool interference, or encryption tooling; lower suspicion when activity stays within one coherent maintenance or reset sequence.
 
+- If endpoint file telemetry is available, is destructive file impact already visible from this process or host?
+  - Focus: file events by `host.id` plus `process.entity_id`; fallback to `host.id`, `process.pid`, and a tight alert window, checking `file.path`, `file.extension`, and `file.Ext.original.extension`. !{investigate{"description":"","label":"File events from VssAdmin","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when file activity shows mass renames, unfamiliar extensions, ransom-note drops, or destructive cleanup after VssAdmin starts; absence of file telemetry is unresolved, not benign.
 
-- 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.
-- In the case of a resize operation, check if the resize value is equal to suspicious values, like 401MB.
-- Investigate other alerts associated with the user/host during the past 48 hours.
-- If unsigned files are found on the process tree, retrieve them and determine if they are malicious:
-  - Use a private sandboxed malware analysis system to perform analysis.
-    - Observe and collect information about the following activities:
-      - Attempts to contact external domains and addresses.
-      - 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.
-- Use process name, command line, and file hash to search for occurrences in other hosts.
-- Check if any files on the host machine have been encrypted.
+- Do same-user or same-host alerts show spread beyond this VssAdmin event?
+  - Focus: same-`user.id` related alerts, especially impact, backup tampering, execution, credential, or lateral-movement activity. !{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 local scope, lineage, process activity, or file impact remains suspicious or unresolved, review the same `host.id` for other shadow-copy, backup-catalog, service-stop, encryption, or ransom-note alerts. !{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 containment when same-user or same-host alerts show additional recovery inhibition, encryption, credential access, or lateral movement; keep scope local when both pivots match the same exact retention, storage-maintenance, image-prep, or lab-reset pattern.
 
+- Escalate when command intent plus launch context or surrounding process/file evidence supports unauthorized recovery inhibition; close only when command scope, identity, lineage, account, host, and follow-on telemetry bind to one exact recognized workflow, with outside confirmation if telemetry cannot prove legitimacy. Preserve evidence and escalate on conflict or incomplete visibility.
 
 
 *False positive analysis*
 
 
-- This rule may produce benign true positives (B-TPs). If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of user and command line conditions.
+- Backup retention, storage maintenance, disaster-recovery testing, image preparation, and lab resets can delete one shadow copy or resize shadow storage. Confirm command scope (`process.command_line`), lineage (`process.parent.executable` and `process.parent.command_line`), actor/asset (`user.id`, `host.id`, `host.name`), and follow-on evidence with no same-window recovery tampering, encryption, ransom-note, or destructive cleanup outside that workflow. External records can corroborate after telemetry matches; otherwise require recurring command scope, parent, account, and host pattern across prior alerts without contradictory process or file evidence.
+- Before creating an exception, validate recurring `process.executable`, `process.pe.original_file_name`, `process.parent.executable`, stable `process.command_line` scope, `user.id` or `user.name`, and `host.id` for the confirmed workflow. Keep it constrained to that workflow and avoid exceptions on `process.name`, "vssadmin.exe", "resize", "delete", or "shadows" alone.
 
 
-*Related rules*
+*Response and remediation*
 
 
-- Volume Shadow Copy Deleted or Resized via VssAdmin - b5ea4bfe-a1b2-421f-9d47-22a75a6f2921
-- Volume Shadow Copy Deletion via PowerShell - d99a037b-c8e2-47a5-97b9-170d076827c4
+- If confirmed benign, reverse temporary controls and record the command scope, parent lineage, account, host, and external evidence that tied the event to recognized maintenance or reset activity. Create an exception only if the same command scope, lineage, account, and host recur consistently across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve the alert document, raw process event, parent tree, full command line, account and host identifiers, same-window process activity, and any file-impact artifacts before containment. Apply reversible containment first: isolate the host if destructive activity appears and host criticality allows it; otherwise restrict the implicated admin channel or account while scope is confirmed. Broaden containment only if same-user or same-host pivots show spread.
+- If confirmed malicious, keep the preserved evidence and isolate the endpoint to stop further impact while retaining telemetry. Suspend related accounts or admin channels when session, lineage, or related-alert evidence shows misuse. Record `process.entity_id` and `process.command_line` before termination. Remove only malicious scripts, payloads, scheduled tasks, services, ransom notes, and backup-tampering changes identified during the investigation.
+- Restore affected VSS, backup, and recovery settings, validate that snapshots or backup jobs work again, and recover impacted data from trusted backups after containment and eradication are complete.
+- Post-incident hardening: restrict VSS-management workflows on sensitive hosts, limit backup-administration rights, protect offline or out-of-band backups from the same accounts, and validate controls for adjacent recovery-inhibition variants such as "wmic shadowcopy delete", "diskshadow", "wbadmin delete catalog", "bcdedit", and "reagentc".
 
 
-*Response and remediation*
+==== 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:
 
-- Initiate the incident response process based on the outcome of the triage.
-- Consider isolating the involved host to prevent destructive behavior, which is commonly associated with this activity.
-- Priority should be given due to the advanced stage of this activity on the attack.
-- 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.
-- If data was encrypted, deleted, or modified, activate your data recovery plan.
-- 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.
-- Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.).
-- 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).
+- 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
diff --git a/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deletion-via-powershell.asciidoc b/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deletion-via-powershell.asciidoc
index b077feae8e..8b73a696ba 100644
--- a/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deletion-via-powershell.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deletion-via-powershell.asciidoc
@@ -39,7 +39,6 @@ Identifies the use of the Win32_ShadowCopy class and related cmdlets to achieve
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Impact
-* Tactic: Execution
 * Resources: Investigation Guide
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
@@ -49,7 +48,7 @@ Identifies the use of the Win32_ShadowCopy class and related cmdlets to achieve
 * Data Source: SentinelOne
 * Data Source: Crowdstrike
 
-*Version*: 318
+*Version*: 319
 
 *Rule authors*: 
 
@@ -70,65 +69,80 @@ Identifies the use of the Win32_ShadowCopy class and related cmdlets to achieve
 *Investigating Volume Shadow Copy Deletion via PowerShell*
 
 
-The Volume Shadow Copy Service (VSS) is a Windows feature that enables system administrators to take snapshots of volumes that can later be restored or mounted to recover specific files or folders.
 
-A typical step in the playbook of an attacker attempting to deploy ransomware is to delete Volume Shadow Copies to ensure that victims have no alternative to paying the ransom, making any action that deletes shadow copies worth monitoring.
+*Possible investigation steps*
 
-This rule monitors the execution of PowerShell cmdlets to interact with the Win32_ShadowCopy WMI class, retrieve shadow copy objects, and delete them.
 
+- Does the alert-local PowerShell command show broad shadow-copy deletion, remote targeting, or obscured execution?
+  - Focus: `process.command_line`, checking whether "Win32_ShadowCopy" is paired with WMI or CIM enumeration and deletion.
+  - Hint: treat `Get-WmiObject`, `gwmi`, `Get-CimInstance`, `gcim`, `Remove-WmiObject`, `rwmi`, `Remove-CimInstance`, `rcim`, "$_.Delete()", `-ComputerName`, and `-CimSession` as high-signal command cues. This rule requires plaintext cmdlet tokens in `process.args`; fully encoded commands or script-file invocations that hide the deletion logic will not fire this rule.
+  - Implication: escalate when the command deletes all returned shadow-copy instances, targets remote systems, or hides WMI or CIM deletion behind aliases; lower suspicion only when narrowly scoped to one recognized backup-retention, image-reset, or lab-test workflow on the expected host.
 
-*Possible investigation steps*
+- Is the PowerShell host binary expected rather than renamed or tampered?
+  - Focus: `process.executable`, `process.name`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when path, signer, trust state, or original file name does not match the expected PowerShell host; lower suspicion when identity matches a trusted system PowerShell installation, but continue because legitimate PowerShell can still delete recovery points.
+
+- Does the parent process and user context explain why this host removed shadow copies?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, `user.name`, and `user.domain`.
+  - Implication: escalate when Office, a browser, a script host, an unexpected remote-management chain, or a standard user launches deletion; lower suspicion when parent, account, and host match a recognized backup, imaging, disaster-recovery, or lab-reset workflow.
+
+- Do surrounding process events show recovery inhibition or ransomware preparation from the same host or lineage?
+  - Why: ransomware commonly pairs shadow-copy deletion with other recovery removal or encryption preparation before impact.
+  - Focus: process starts on `host.id` and, when present, the same `process.entity_id` or lineage, using `process.name`, `process.command_line`, and `process.parent.executable`. !{investigate{"description":"","label":"Process starts on the same host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Range: start with the alert window and following 15 minutes; expand only when the same lineage shows recovery tampering or encryption behavior.
+  - Implication: escalate when the same window shows `vssadmin`, `wmic`, `diskshadow`, `wbadmin`, backup service stops, recovery-setting changes, or likely encryptor launchers; lower suspicion when activity stays bounded to the same parent-launched cleanup or reset sequence and no other recovery-inhibition utilities appear.
 
+- If command or lineage remains suspicious and endpoint file telemetry is available, does file activity show encryption or destructive cleanup?
+  - Focus: recover file events with `host.id` + `process.entity_id`; if absent, use `host.id` + `process.pid` plus a tight alert window as a weaker fallback, then review `file.path`, `file.extension`, and `file.Ext.original.extension`. !{investigate{"description":"","label":"File events from the PowerShell process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when recovered file events show mass renames, unfamiliar extensions, replaced user files, or ransom-note paths after deletion; lower suspicion only when changes stay inside the recovered backup or reset target. Missing endpoint file telemetry leaves file impact unanswered; do not treat absence of file evidence as benign.
 
-- Investigate the program execution chain (parent process tree).
-- Check whether the account is authorized to perform this operation.
-- 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.
-- If unsigned files are found on the process tree, retrieve them and determine if they are malicious:
-  - Use a private sandboxed malware analysis system to perform analysis.
-    - Observe and collect information about the following activities:
-      - Attempts to contact external domains and addresses.
-      - 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.
-- Use process name, command line, and file hash to search for occurrences in other hosts.
-- Check if any files on the host machine have been encrypted.
+- If local evidence remains suspicious or unresolved, does related alerting show the same VSS deletion or backup-tampering pattern?
+  - Focus: related impact or execution alerts for the same `user.id` involving VSS deletion, backup tampering, credential access, or the same parent tool. !{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: check the same `host.id` for shadow-copy deletion by other binaries, encryption, ransom-note creation, backup tampering, or service tampering. !{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 same user touches multiple hosts or the same host shows a broader ransomware chain; keep the case local only when related alerts are absent and local telemetry already fits one recognized workflow.
 
+- Escalate broad or remote shadow-copy deletion that lacks a recognized workflow, has suspicious lineage, destructive process or file evidence, or related spread; close only when narrow command scope, identity, lineage, and supported surrounding telemetry fit one workflow; preserve and escalate mixed or visibility-limited evidence.
 
 
 *False positive analysis*
 
 
-- This rule has chances of producing benign true positives (B-TPs). If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of user and command line conditions.
+- PowerShell WMI or CIM shadow-copy deletion is suspicious by default outside controlled backup-retention cleanup, disaster-recovery testing, gold-image preparation, lab reset, or ransomware simulation. Close as benign only when `process.command_line` is narrowly scoped, `process.parent.executable` matches the backup, orchestration, reset, or test tool, `user.id` or `user.name` matches the expected admin or service account, `host.id` plus `host.name` fit the target, and surrounding telemetry shows no destructive process or file impact. Use change records or lab schedules only as corroboration; generic storage maintenance is not enough.
+- Before creating an exception, validate historical stability for the same `process.executable`, `process.parent.executable`, stable `process.command_line` scope, `user.id` or `user.name`, and `host.id`. Build the exception from that minimum confirmed workflow pattern. Avoid exceptions on "powershell.exe", `process.name`, or "Win32_ShadowCopy" alone.
 
 
-*Related rules*
+*Response and remediation*
 
 
-- Volume Shadow Copy Deleted or Resized via VssAdmin - b5ea4bfe-a1b2-421f-9d47-22a75a6f2921
-- Volume Shadow Copy Deletion via PowerShell - d99a037b-c8e2-47a5-97b9-170d076827c4
+- If confirmed benign, reverse any temporary containment and record the `process.command_line`, `process.parent.executable`, `user.id` or `user.name`, `host.id`, and maintenance evidence that proved the workflow. Create an exception only if the same command scope, lineage, account, and host recur consistently across prior alerts from this rule.
+- If suspicious but unconfirmed, preserve the alert, `process.entity_id`, full `process.command_line`, `process.args`, parent chain, `user.id`, `user.name`, `host.id`, surrounding process commands, and any recovered file-impact examples before containment. Apply reversible containment first: isolate the host only when destructive process or file evidence suggests ongoing impact and the host can tolerate isolation; otherwise restrict the implicated admin channel or account while scope is confirmed. Expand containment to related hosts or accounts only if the same-user or same-host pivots show spread.
+- If confirmed malicious, preserve the same process, command, lineage, and recovered file-impact artifacts before destructive action. Prefer endpoint isolation to stop further impact while keeping telemetry available; if direct response is unavailable, escalate with the preserved `host.id`, `user.id`, `user.name`, `process.entity_id`, `process.command_line`, and suspected ransom-note or renamed-extension indicators to the team that can isolate the host and suspend related accounts or services. If the malicious process chain is still active, record `process.entity_id` and `process.command_line` before suspending or terminating it.
+- After scope review, remove only the malicious scripts, scheduled tasks, services, payloads, or dropped notes identified during the investigation, then restore affected backup or recovery settings and validate that snapshots or backup jobs are functioning before closure.
+- Post-incident hardening: restrict VSS-management workflows and remote CIM deletion patterns to controlled administrative channels, retain the process and file telemetry that proved the case, and review whether adjacent VSS methods such as "vssadmin", "wmic", `diskshadow`, `wbadmin`, COM-based deletion, or diff-area resizing need the same controls.
 
 
-*Response and remediation*
+==== 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:
 
-- Initiate the incident response process based on the outcome of the triage.
-- Consider isolating the involved host to prevent destructive behavior, which is commonly associated with this activity.
-- Priority should be given due to the advanced stage of this activity on the attack.
-- 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.
-- If data was encrypted, deleted, or modified, activate your data recovery plan.
-- 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.
-- Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.).
-- 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).
+- 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
diff --git a/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deletion-via-wmic.asciidoc b/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deletion-via-wmic.asciidoc
index bdb89c1d94..5cd731dc3c 100644
--- a/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deletion-via-wmic.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deletion-via-wmic.asciidoc
@@ -35,7 +35,6 @@ Identifies use of wmic.exe for shadow copy deletion on endpoints. This commonly
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Impact
-* Tactic: Execution
 * Resources: Investigation Guide
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
@@ -45,7 +44,7 @@ Identifies use of wmic.exe for shadow copy deletion on endpoints. This commonly
 * Data Source: SentinelOne
 * Data Source: Crowdstrike
 
-*Version*: 317
+*Version*: 318
 
 *Rule authors*: 
 
@@ -65,66 +64,76 @@ Identifies use of wmic.exe for shadow copy deletion on endpoints. This commonly
 *Investigating Volume Shadow Copy Deletion via WMIC*
 
 
-The Volume Shadow Copy Service (VSS) is a Windows feature that enables system administrators to take snapshots of volumes that can later be restored or mounted to recover specific files or folders.
 
-A typical step in the playbook of an attacker attempting to deploy ransomware is to delete Volume Shadow Copies to ensure that victims have no alternative to paying the ransom, making any action that deletes shadow copies worth monitoring.
+*Possible investigation steps*
 
-This rule monitors the execution of `wmic.exe` to interact with VSS via the `shadowcopy` alias and delete parameter.
 
+- What recovery data did WMIC try to delete?
+  - Focus: `process.command_line` scope: "shadowcopy delete", "ID=", "VolumeName=", "where", "/node:", or broad no-filter deletion.
+  - Implication: escalate when the command removes all shadows, targets a remote node, or lacks a narrow snapshot or volume filter; lower suspicion only when it targets one expected snapshot or volume and parent, account, host, and later process evidence fit that task.
 
-*Possible investigation steps*
+- Is this the expected Microsoft WMIC binary for the host?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when WMIC is renamed, runs outside a Windows system path, has a non-Microsoft or untrusted signature, or mismatches its original file name; Microsoft-signed system-path WMIC lowers identity risk but does not clear shadow-copy deletion.
 
+- Which launcher and account initiated the deletion?
+  - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, `user.name`, and `user.domain`.
+  - Implication: escalate when a document, browser, archive tool, script host, interactive user, or unexplained remote-management parent launches WMIC; lower suspicion only when parent command, account, and host identify the exact recovery, imaging, lab-reset, or authorized test runner.
 
-- Investigate the program execution chain (parent process tree).
-- Check whether the account is authorized to perform this operation.
-- Contact the account owner and confirm whether they are aware of this activity.
-- In the case of a resize operation, check if the resize value is equal to suspicious values, like 401MB.
-- Investigate other alerts associated with the user/host during the past 48 hours.
-- If unsigned files are found on the process tree, retrieve them and determine if they are malicious:
-  - Use a private sandboxed malware analysis system to perform analysis.
-    - Observe and collect information about the following activities:
-      - Attempts to contact external domains and addresses.
-      - 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.
-- Use process name, command line, and file hash to search for occurrences in other hosts.
-- Check if any files on the host machine have been encrypted.
+- Did the same host or lineage run other recovery-inhibition or encryption-prep commands?
+  - Why: ransomware often mixes WMIC with "vssadmin.exe", "wbadmin.exe", "bcdedit.exe", "REAgentC.exe", "diskshadow.exe", service-stop commands, or encryption tooling.
+  - Focus: same-`host.id` process starts, scoped to `process.parent.entity_id` when present, for recovery-inhibition utilities, service stops, backup-agent tampering, or encryption tools. !{investigate{"description":"","label":"Process events from the same parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: without `process.entity_id`, pivot by `host.id` + `process.pid` near the alert and treat lineage as weaker.
+  - Implication: escalate when WMIC is adjacent to additional recovery inhibition, backup tampering, service stops, or encryption preparation; keep scope narrower when process activity stays limited to one coherent maintenance or test sequence.
 
+- If local evidence is suspicious or unresolved, is the activity broader than one host workflow?
+  - Focus: same-`user.id` alerts for impact, execution, credential, or recovery-inhibition activity. !{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: review same-`host.id` alerts for alternate shadow-copy deletion utilities, backup tampering, or repeated destructive command lines. !{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: escalate scope when the user or host shows related impact or execution alerts beyond this command; keep host-local only when both pivots stay confined to the same narrow command sequence.
+
+- Escalate for unauthorized shadow-copy deletion, remote targeting, destructive preparation, or broader spread; close only when command scope, binary identity, parent/account context, same-host corroboration, and related alerts bind to one recognized workflow; preserve evidence and escalate when mixed or incomplete.
 
 
 *False positive analysis*
 
 
-- This rule has chances of producing benign true positives (B-TPs). If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of user and command line conditions.
+- Treat WMIC shadow-copy deletion as a recovery-inhibition anti-pattern. Benign closure is narrow: telemetry must show one expected snapshot or volume, a parent command for that exact task, the expected account and host, and no contradictory same-host recovery-inhibition or encryption-prep activity. Use change records or test plans only as corroboration.
+- Do not close as benign when the command removes all shadows, uses "/node:" remote targeting, has unexplained lineage, or appears with service-stop, backup-tampering, or encryption-prep activity. Recurrence, WMIC identity, or a stated maintenance window is not enough when process evidence remains broad or contradictory.
+- Before creating an exception, require a confirmed benign case with the exact `process.command_line` scope, `process.parent.executable`, `process.parent.command_line`, `user.id`, and `host.id`. Build the exception from that minimum pattern, never on "wmic.exe", `process.name`, or "shadowcopy" alone.
 
 
-*Related rules*
+*Response and remediation*
 
 
-- Volume Shadow Copy Deleted or Resized via VssAdmin - b5ea4bfe-a1b2-421f-9d47-22a75a6f2921
-- Volume Shadow Copy Deletion via PowerShell - d99a037b-c8e2-47a5-97b9-170d076827c4
+- If confirmed benign, reverse temporary containment and document the command scope, parent workflow, account, host, and corroborating maintenance or test evidence. Create an exception only when the same workflow recurs consistently for the same account and host scope.
+- If suspicious but unconfirmed, export the alert, process tree, full command line, parent command line, account, host identifiers, and related-alert results before containment. Apply reversible containment first, such as heightened monitoring or temporary administrative-access restrictions for the affected host or account; isolate the endpoint only if process evidence suggests active encryption, backup tampering, or broader destructive activity.
+- If confirmed malicious, preserve the process tree and command evidence before stopping processes or deleting artifacts. Isolate the endpoint to prevent further impact, suspend or reset involved accounts when the same `user.id` shows unauthorized activity, and remove only the scripts, scheduled tasks, services, or tools identified through the process investigation.
+- Restore recovery capability after containment: re-enable or repair affected VSS, backup, and recovery settings, validate that snapshots or backup jobs are functioning, and confirm no related recovery-inhibition commands remain active on the same host or scoped host set.
+- Post-incident hardening: restrict WMIC and VSS-management access on sensitive hosts, use application control where WMIC is not required, retain the process evidence that proved the case, and record any observed variants such as "vssadmin.exe", PowerShell Win32_ShadowCopy deletion, "wbadmin.exe", "bcdedit.exe", or "diskshadow.exe" in the case notes.
 
 
-*Response and remediation*
+==== 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:
 
-- Initiate the incident response process based on the outcome of the triage.
-- Priority should be given due to the advanced stage of this activity on the attack.
-- Consider isolating the involved host to prevent destructive behavior, which is commonly associated with this activity.
-- 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.
-- If data was encrypted, deleted, or modified, activate your data recovery plan.
-- 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.
-- Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.).
-- 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).
+- 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
diff --git a/docs/detections/prebuilt-rules/rule-details/web-shell-detection-script-process-child-of-common-web-processes.asciidoc b/docs/detections/prebuilt-rules/rule-details/web-shell-detection-script-process-child-of-common-web-processes.asciidoc
index db1045afb7..0d241ed319 100644
--- a/docs/detections/prebuilt-rules/rule-details/web-shell-detection-script-process-child-of-common-web-processes.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/web-shell-detection-script-process-child-of-common-web-processes.asciidoc
@@ -38,8 +38,6 @@ Identifies suspicious commands executed via a web server, which may suggest a vu
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Persistence
-* Tactic: Initial Access
-* Tactic: Execution
 * Resources: Investigation Guide
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
@@ -49,7 +47,7 @@ Identifies suspicious commands executed via a web server, which may suggest a vu
 * Data Source: Sysmon
 * Data Source: Crowdstrike
 
-*Version*: 423
+*Version*: 424
 
 *Rule authors*: 
 
@@ -66,53 +64,84 @@ Identifies suspicious commands executed via a web server, which may suggest a vu
 
 
 
-*Investigating Web Shell Detection: Script Process Child of Common Web Processes*
+*Possible investigation steps*
 
 
-Adversaries may backdoor web servers with web shells to establish persistent access to systems. A web shell is a web script that is placed on an openly accessible web server to allow an adversary to use the web server as a gateway into a network. A web shell may provide a set of functions to execute or a command-line interface on the system that hosts the web server.
+- What execution path did the alert capture?
+  - Focus: child `process.executable` / `process.command_line`; web-parent `process.parent.name`, `process.parent.executable`, and `process.parent.command_line` for IIS/Apache/nginx/PHP CGI/Tomcat/ArcGIS.
+  - Implication: escalate when a web-facing parent launches a shell, script host, downloader, archive tool, or admin utility outside bounded tasks; lower only when parent context, child path, and command match one exact deployment, health-check, log rotation, or support task.
+- Is the child command administration or post-exploitation?
+  - Focus: `process.command_line`: WMIC, download cradles, archive creation, account/system discovery, service control, credential access, script-host flags, or web-root/temp/backup/app-content paths.
+  - Hint: for PowerShell, reconstruct script blocks by `host.id` and `process.pid` via `powershell.file.script_block_text`, `powershell.sequence`, and `powershell.total`; missing PowerShell telemetry is unresolved, not benign.
+  - Implication: escalate when the command stages payloads, runs discovery, creates accounts, changes services, or writes to web-accessible or temp paths; lower suspicion when bounded to one recognized deployment, health-check, log rotation, or support task.
+- Is user context human admin or service identity?
+  - Why: web-process children often inherit app-pool or service identity; `user.id`, `user.name`, and `user.domain` do not prove human initiation.
+  - Focus: `@timestamp`, `user.id`, `user.name`, `process.Ext.session_info.logon_type`, and `process.parent.command_line`.
+  - Implication: escalate when service or network logon context launches interactive troubleshooting, remote administration, or off-hours shell activity without a matching window; lower suspicion when identity, logon type, parent pool/service, and command scope fit one exact workflow.
+- Does child binary identity fit its command?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the child is renamed, unsigned/untrusted, user-writable, or mismatched to original file name; lower suspicion when identity and path match stable tooling, but continue because trusted binaries can carry web-shell commands.
+- Did file telemetry show web-shell placement, staging, or config changes?
+  - Focus: if file telemetry exists, review `host.id` file events for child `process.entity_id` or `process.pid`, checking `file.path`, `file.Ext.original.path`, and `file.Ext.windows.zone_identifier`. !{investigate{"description":"","label":"File events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: web-root script writes without later child starts are adjacent-variant evidence; if the child writes a script or executable, query starts where `process.executable` equals that path on same `host.id`.
+  - Implication: escalate when the child writes ASPX, ASP, PHP, JSP, JS, BAT, PS1, EXE, DLL, JAR, WAR, or archives to web-accessible/temp/user-writable paths, or a written artifact later executes; missing file telemetry is unresolved, not benign, and absence does not close.
+- Did the child launch second-stage processes?
+  - Focus: child starts on `host.id` where `process.parent.entity_id` equals child `process.entity_id`, checking `process.executable`, `process.command_line`, and `process.hash.sha256`. !{investigate{"description":"","label":"Child process events from the suspicious child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when descendants include shells, script hosts, downloaders, archive tools, credential utilities, service control, or persistence tooling; absence only narrows impact when command, file, network, and related alerts also fit a benign workflow.
+- Did DNS/network telemetry show retrieval or control?
+  - Focus: if DNS/network telemetry exists, review child `process.entity_id` events on `host.id`, separating `dns.question.name` / `dns.resolved_ip` from `destination.ip` / `destination.port`; compare role with command intent. !{investigate{"description":"","label":"Network events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: map DNS results to later connection IPs before linking query and connection; if a third-party alert lacks `process.entity_id`, recover the child by `host.id`, `process.pid`, and `@timestamp`. Missing network/DNS telemetry is unresolved, not benign.
+  - Implication: escalate when the child retrieves tools from public infrastructure, reaches rare/misaligned destinations, or connects outside web-server administration; decide from alert-local process evidence and corroboration when DNS/network telemetry is unavailable.
+- Do related alerts show broader compromise?
+  - Focus: same-web-parent starts and 48h `host.id` alerts for web-shell, credential-access, discovery, archive, lateral-movement, persistence, or anti-forensics.
+    - !{investigate{"description":"","label":"Process events from the same web parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","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: escalate scope when alerts cluster around the same server role, child command family, or staged artifacts; absence only narrows response scope when local parent-child, command, identity, file, and network evidence are explained.
+- What disposition fits?
+  - Implication: escalate on unexplained server-side execution, exploit-like command intent, suspicious child identity, payload staging, rare destinations, or broader compromise; do not wait for optional pivots when alert-local process evidence is unsafe. Close only when same-host alert-window telemetry proves one exact benign web-server workflow; use outside confirmation for legitimacy gaps. If evidence is mixed or visibility incomplete, preserve artifacts and escalate.
 
-This rule detects a web server process spawning script and command-line interface programs, potentially indicating attackers executing commands using the web shell.
 
+*False positive analysis*
 
-*Possible investigation steps*
 
+- Web deployment, post-install validation, health checks, vendor extension install, ArcGIS publishing, or maintenance can spawn "cmd.exe", PowerShell, or "wscript.exe" from web components. Confirm only when parent, child, command, service identity, and artifact/destination evidence describe the same alert-window workflow with no unexpected web-content writes, rare callbacks, or contradictions.
+- If telemetry proves shape but not legitimacy, require matching change, deployment, runbook, vendor, or owner confirmation; use prior occurrences post-closure to test exception stability.
+- Build exceptions from minimum confirmed pattern: web parent command, child executable/hash/signature, command line, `user.id`, `host.id`, and bounded content path or destination when decisive. Avoid parent name, `process.name`, or `host.id` alone.
 
-- Investigate abnormal behaviors observed by the subject process such as network connections, registry or file modifications, and any other spawned child processes.
-- Examine the command line to determine which commands or scripts were executed.
-- Investigate other alerts associated with the user/host during the past 48 hours.
-- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
-- If scripts or executables were dropped, retrieve the files and determine if they are malicious:
-  - Use a private sandboxed malware analysis system to perform analysis.
-    - Observe and collect information about the following activities:
-      - Attempts to contact external domains and addresses.
-      - 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.
 
+*Response and remediation*
 
-*False positive analysis*
 
+- If confirmed benign, reverse temporary containment, document exact parent, child, command, service identity, artifact/destination evidence, and confirmation, and create exceptions only from that pattern.
+- If suspicious but unconfirmed, preserve the alert/export, process tree, child/parent entity IDs, command lines, hash, staged-file copies, destinations, related alerts, and web/app logs around `@timestamp` before containment or cleanup.
+- Apply reversible containment tied to evidence: block confirmed malicious destinations, restrict affected site/app access, disable exposed extension or virtual directory, or increase `host.id` monitoring. Isolate only when evidence and server criticality permit.
+- If confirmed malicious, contain the host or terminate the child only after preservation; if direct response is unavailable, escalate with process/artifact/destination/server-log evidence to the team that can contain the server, disable the exposed path, or stop the service.
+- Before deletion/restoration, hunt for the same hash, child command, staged path, domain, IP, and port across hosts/accounts. Then remove web shells, scripts, archives, scheduled tasks, dropped utilities, and persistence; restore known-good content/config; rotate exposed service, app, or admin credentials if secrets may be exposed.
+- After containment, patch the implicated app, extension, framework, or server component; review the internet-exposed site/service that launched the child; retain endpoint, network, and web logs; document script-only variants or logging gaps.
 
-- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team.
 
+==== 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*
 
-*Response and remediation*
 
+This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
 
-- 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).
+- 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
diff --git a/docs/detections/prebuilt-rules/rule-details/windows-server-update-service-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/rule-details/windows-server-update-service-spawning-suspicious-processes.asciidoc
index bbbd7e3cc2..858666bdb4 100644
--- a/docs/detections/prebuilt-rules/rule-details/windows-server-update-service-spawning-suspicious-processes.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/windows-server-update-service-spawning-suspicious-processes.asciidoc
@@ -35,7 +35,6 @@ Identifies suspicious processes being spawned by the Windows Server Update Servi
 * OS: Windows
 * Use Case: Threat Detection
 * Tactic: Initial Access
-* Tactic: Execution
 * Data Source: Elastic Endgame
 * Data Source: Elastic Defend
 * Data Source: Sysmon
@@ -43,7 +42,7 @@ Identifies suspicious processes being spawned by the Windows Server Update Servi
 * Data Source: SentinelOne
 * Resources: Investigation Guide
 
-*Version*: 3
+*Version*: 4
 
 *Rule authors*: 
 
@@ -59,9 +58,6 @@ Identifies suspicious processes being spawned by the Windows Server Update Servi
 *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 Windows Server Update Service Spawning Suspicious Processes*
 
@@ -70,30 +66,65 @@ Identifies suspicious processes being spawned by the Windows Server Update Servi
 *Possible investigation steps*
 
 
-- Examine the child process details, focusing on the process names and original file names such as cmd.exe, powershell.exe, pwsh.exe, and powershell_ise.exe, to identify any unauthorized or unexpected command-line activity.
-- Investigate the timeline of events leading up to the alert, including any preceding or subsequent processes, to understand the context and potential impact of the suspicious activity.
-- Check for any associated network activity or connections initiated by the suspicious processes to identify potential data exfiltration or communication with external command and control servers.
-- Review recent changes or access logs on the affected  server to identify any unauthorized access attempts or modifications that could indicate exploitation or the presence of a web shell.
-- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender XDR, or SentinelOne to gather additional context and corroborate findings.
-- Assess the risk and impact of the detected activity, considering the severity and risk score, and determine appropriate response actions, such as isolating the affected system or conducting a deeper forensic analysis.
+- What does the alert-local WSUS parent-child path show?
+  - Focus: child `process.executable` and `process.command_line`, plus `process.parent.name`, `process.parent.executable`, and `process.parent.args`, especially "w3wp.exe" with "WsusPool" or "WsusService.exe".
+  - Implication: escalate when a WSUS web or service component launches a shell, PowerShell, "rundll32.exe", or "curl.exe" for interpreter, download, or proxy-execution behavior; lower suspicion only when the parent-child pair and arguments match a narrow recognized WSUS setup, cleanup, or repair pattern.
+- Does the child command and binary identity fit bounded WSUS maintenance?
+  - Why: WSUS children can inherit service context; visible user fields may not prove human initiation.
+  - Focus: `process.command_line`, `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`/`trusted`, and child processes. !{investigate{"description":"","label":"Child processes of the suspicious WSUS child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: for PowerShell with script-block telemetry, anchor on `host.id` + `process.entity_id` or `host.id` + `process.pid` in a tight alert window. Reconstruct `powershell.file.script_block_id`, `powershell.total`, `powershell.sequence`, and `powershell.file.script_block_text`; missing script-block telemetry is unresolved, not benign.
+  - Implication: escalate on encoded script content, external retrieval, discovery, archive, remote-admin, temp-path DLL activity, or a renamed/unsigned/mismatched child; lower suspicion only when command scope, path, PE identity, and signer all match the same narrow WSUS task. Identity alone does not clear the launch chain.
+- Did the child stage payloads or WSUS-content artifacts?
+  - Focus: process-scoped file `file.path`, `file.Ext.original.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier`; missing file telemetry is unresolved, not benign. !{investigate{"description":"","label":"File events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: scope by `host.id` + `process.entity_id`, or `host.id` + `process.pid` if absent; check later starts where `process.executable` equals the written path.
+  - Implication: escalate when the child writes scripts, DLLs, EXEs, archives, or renamed content under WSUS, IIS, temp, or user-writable paths, especially if later executed; lower suspicion only when writes stay inside the same narrow WSUS maintenance path.
+- Did the child retrieve tooling, call back, or reach destinations outside the WSUS role?
+  - Focus: process-scoped DNS `event.action`, `dns.question.name`, `dns.resolved_ip`, and connection `destination.ip`/`destination.port`; missing network telemetry is unresolved, not benign. !{investigate{"description":"","label":"Network events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Hint: scope by `host.id` + `process.entity_id`, or `host.id` + `process.pid` if absent. Compare DNS "lookup_result" `dns.resolved_ip` with later `destination.ip` from the same process.
+  - Implication: escalate when the child retrieves tools from public infrastructure, connects to rare or unrelated systems, or uses destinations inconsistent with WSUS update distribution; lower suspicion when the same process reaches only recognized internal mirrors, proxies, or vendor services that fit command and parent context.
+- If local findings are suspicious or unresolved, does same-host scope show broader WSUS compromise?
+  - Focus: related alerts on the same `host.id`, especially repeated WSUS-spawned tools and complementary webshell, credential-access, discovery, archive, or lateral-movement activity. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Range: start with the alert window; expand to 48 hours only if parent-child, command, artifact, or destination evidence remains suspicious or incomplete.
+  - Implication: broaden containment when related alerts corroborate WSUS compromise or post-exploitation; keep scope local when surrounding activity is limited to one fully explained maintenance action.
+- Escalate for unexplained service-side execution, payload staging, suspicious destinations, or broader WSUS compromise; close only when parent-child path, command intent, service context, binary identity, artifacts, destinations, and same-host scope prove one exact recognized WSUS maintenance or validation workflow; preserve artifacts and escalate when evidence is mixed or optional telemetry is missing.
 
 
 *False positive analysis*
 
 
-- This behavior is rare and should be treated with high suspicion.
+- WSUS installation, post-install repair, cleanup, health-check, migration, or authorized CVE validation can launch bounded shell or PowerShell children from "WsusPool" or "WsusService.exe". Close only when parent `process.parent.name`/`process.parent.args`, child command, path, hash or signer, `user.id`, and `host.id` prove the same narrow task; artifact and destination telemetry should corroborate when available, and missing recovery that leaves staging or callback unresolved requires confirmation or escalation.
+- Before creating an exception, validate stability across prior alerts for the same WSUS server: parent context, child path/hash/signer, exact `process.command_line`, `user.id`, `host.id`, and any bounded artifact or destination pattern. Avoid exceptions on "WsusService.exe", "w3wp.exe", `process.name`, or `host.id` alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected Server from the network to prevent further unauthorized access or lateral movement.
-- Terminate any suspicious processes identified as being spawned by w3wp.exe, such as cmd.exe or powershell.exe, to halt any ongoing malicious activity.
-- Conduct a thorough review of the server's application pools and web directories to identify and remove any unauthorized web shells or scripts.
-- Restore the server from a known good backup taken before the suspicious activity was detected to ensure system integrity.
-- Apply the latest security patches and updates to the Server to mitigate known vulnerabilities and prevent exploitation.
-- Monitor network traffic and server logs for any signs of continued or attempted exploitation, focusing on unusual outbound connections or repeated access attempts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised.
+- If confirmed benign, reverse temporary containment and document the parent context, child `process.executable`, `process.command_line`, signer or hash, `user.id`, `host.id`, and bounded artifact or destination evidence that proved the WSUS workflow. Create an exception only from that full stable pattern.
+- If suspicious but unconfirmed, preserve the case export, process tree, child `process.entity_id`, `process.pid`, `process.command_line`, parent context, `user.id`, `host.id`, recovered staged paths, recovered DNS or destination indicators, and related-alert identifiers before containment. Apply reversible containment first: block confirmed malicious destinations, restrict inbound WSUS exposure on ports 8530/8531, limit external access to the affected service, or increase monitoring. Isolate the host only when artifact, destination, or related-alert evidence shows active compromise and the server role can tolerate disruption.
+- If confirmed malicious, isolate the WSUS host or terminate the malicious child only after preserving process identifiers, command lines, parent context, hashes, staged paths, destination indicators, and related-alert evidence. Then disable the exposed WSUS service path or block inbound 8530/8531 until patched, scope other servers and accounts for confirmed indicators, remove only artifacts identified during triage, restore WSUS/IIS content, rotate exposed credentials if configuration material was accessed, apply the relevant Microsoft WSUS update, and retain case logs.
+
+
+==== 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
 
diff --git a/docs/detections/prebuilt-rules/rule-details/windows-service-installed-via-an-unusual-client.asciidoc b/docs/detections/prebuilt-rules/rule-details/windows-service-installed-via-an-unusual-client.asciidoc
index b1bea2c1e7..8da3218a8a 100644
--- a/docs/detections/prebuilt-rules/rule-details/windows-service-installed-via-an-unusual-client.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/windows-service-installed-via-an-unusual-client.asciidoc
@@ -24,7 +24,7 @@ Identifies the creation of a Windows service by an unusual client process. Servi
 *References*: 
 
 * https://www.x86matthew.com/view_post?id=create_svc_rpc
-* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4697
+* https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4697
 * https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0100_windows_audit_security_system_extension.md
 * https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry
 
@@ -37,7 +37,7 @@ Identifies the creation of a Windows service by an unusual client process. Servi
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 217
+*Version*: 218
 
 *Rule authors*: 
 
@@ -53,47 +53,69 @@ Identifies the creation of a Windows service by an unusual client process. Servi
 *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 Windows Service Installed via an Unusual Client*
 
 
-Windows services are crucial for running background processes with elevated privileges. Adversaries exploit this by creating services to escalate privileges from administrator to SYSTEM. The detection rule identifies anomalies by flagging service installations initiated by atypical processes, excluding known legitimate services. This helps in spotting potential privilege escalation attempts by monitoring unusual client activity.
+*Possible investigation steps*
+
 
+- Which unusual service-control path did the alert preserve?
+  - Why: Custom Service Control Manager RPC clients can create services without normal attribution; PID 0 is the path this alert needs interpreted.
+  - Focus: `winlog.event_data.ClientProcessId`, `winlog.event_data.ParentProcessId`, `user.domain`, `winlog.computer_name`, and `winlog.event_data.ServiceAccount`.
+  - Implication: escalate when PID 0 attribution combines with a local-account domain and LocalSystem; lower suspicion only when exact host, account, service, and time match a recognized deployment or test explaining zeroed attribution.
 
-*Possible investigation steps*
+- What would the new service execute and how privileged is it?
+  - Why: Event 4697 captures the create-time image path only; later service changes can contradict a clean create-time string.
+  - Focus: `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceType`, `winlog.event_data.ServiceStartType`, and `winlog.event_data.ServiceAccount`.
+  - Implication: escalate when the image path is user-writable, temporary, ProgramData, or system-masqueraded; type is driver; start type is boot, system, or disabled; or LocalSystem lacks a matching product. Lower suspicion when all service fields align with one recognized installer, endpoint agent, backup, or deployment tool.
 
+- Which account and logon session requested the service creation?
+  - Focus: service-install `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, and `winlog.event_data.SubjectLogonId`; 4624 `source.ip` and `winlog.logon.type`; 4648 explicit-credential context.
+  - Implication: escalate when the subject is an unexpected local admin or machine account, origin is remote or rare for the host, explicit credentials appear, or source is absent where remote administration is expected; lower suspicion when subject, logon type, source, and service target fit one recognized management session. Missing 4624/4648 or source fields leaves origin unresolved, not benign.
+  - Hint: on `host.id`, search 4624 where `winlog.event_data.TargetLogonId` equals service-install `winlog.event_data.SubjectLogonId`; search 4648 where `winlog.event_data.SubjectLogonId` matches.
+    - !{investigate{"description":"","label":"Linked logon for the service-install session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
+    - !{investigate{"description":"","label":"Explicit-credential events for the service-install session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
 
-- Review the event logs to identify the specific client process that initiated the service installation by examining the winlog.event_data.ClientProcessId and winlog.event_data.ParentProcessId fields.
-- Investigate the parent process associated with the unusual client process to determine if it is a known legitimate application or potentially malicious.
-- Check the winlog.event_data.ServiceFileName to verify the path and name of the service file, ensuring it is not a known legitimate service excluded in the query.
-- Analyze the timeline of events around the service installation to identify any preceding suspicious activities or related alerts that might indicate a broader attack.
-- Conduct a reputation check on the client process and service file using threat intelligence sources to assess if they are associated with known malicious activities.
-- Examine the system for any additional indicators of compromise, such as unexpected network connections or changes to critical system files, that may suggest privilege escalation or lateral movement attempts.
+- Do surrounding Windows Security records show a contained install or follow-on control activity?
+  - Focus: same-host `event.code`, `winlog.record_id`, `winlog.event_data.ServiceName`, and `winlog.event_data.SubjectLogonId` around `@timestamp`.
+  - Implication: escalate when the same logon session creates multiple services, pairs install with explicit credentials, or shows account changes or failures around service creation; lower suspicion when records stay limited to one expected installer session for the same service. Missing Security telemetry is unresolved, not benign.
+  - Hint: inspect same-session 4697 records for clustered service creation. !{investigate{"description":"","label":"Same-session service-install events","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":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+
+- Is the same service-install pattern recurring in a bounded cohort or spreading?
+  - Focus: historical Event ID 4697 records by `winlog.event_data.SubjectUserSid`, `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceAccount`, and `winlog.computer_name`.
+  - Implication: escalate when the same subject creates PID 0 LocalSystem services across unrelated hosts, or service names or paths rotate; lower suspicion when exact service fields recur in the same managed host cohort with a stable subject and no contradictory service metadata.
+  - Hint: query 4697 for the same subject or service fields, group by `winlog.computer_name`, `winlog.event_data.ServiceName`, and `winlog.event_data.ServiceFileName`, then compare PID 0 recurrence. !{investigate{"description":"","label":"Historical 4697 service-install recurrence","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","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":"4697","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ServiceFileName","queryType":"phrase","value":"{{winlog.event_data.ServiceFileName}}","valueType":"string"}]],"relativeFrom":"now-7d/d","relativeTo":"now"}}
+
+- Based on the Windows Security evidence, what disposition is supported?
+  - Implication: escalate when PID 0, LocalSystem image, actor/session evidence, or 4697 recurrence does not bind to one recognized workflow; close only when the same fields prove one exact service deployment or test on this host and no contradictory Security evidence remains; if mixed, preserve service-install and logon records, then escalate.
 
 
 *False positive analysis*
 
 
-- Legitimate software installations or updates may trigger the rule if they create services using unusual client processes. To manage this, identify and whitelist these processes in the detection rule to prevent unnecessary alerts.
-- System management tools like Veeam and PDQ Inventory are already excluded, but other similar tools might not be. Regularly review and update the exclusion list to include any additional legitimate tools used in your environment.
-- Custom scripts or administrative tools that create services for maintenance or monitoring purposes can also cause false positives. Document these scripts and consider adding them to the exclusion list if they are verified as safe.
-- Temporary or one-time service installations for troubleshooting or testing can be mistaken for threats. Ensure that such activities are logged and communicated to the security team to avoid confusion and unnecessary alerts.
-- Changes in system configurations or updates to existing software might alter the behavior of legitimate processes, causing them to be flagged. Regularly review and adjust the detection rule to accommodate these changes while maintaining security integrity.
+- Software deployment, endpoint agent, backup, configuration tools, or authorized service-control/RPC testing can trigger when Service Control Manager behavior leaves PID 0 attribution. Examples include Veeam, PDQ, CrowdStrike installer, SCCM/SMS, nsnetpush, or pbpsdeploy-style patterns. Confirm service name, file, account, subject SID, host cohort, logon session, and test timing align with one product or test workflow, with no contradictory Security records.
+- Before creating an exception, require stable recurrence for the same `winlog.event_data.SubjectUserSid`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceName`, `winlog.event_data.ServiceAccount`, and host cohort. Avoid broad exceptions on `user.name`, `host.name`, or service name alone.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
-- Terminate the suspicious service and any associated processes identified by the alert to stop potential privilege escalation or malicious activity.
-- Conduct a thorough review of the service's configuration and associated files to identify any unauthorized changes or malicious code.
-- Restore any altered or compromised system files from a known good backup to ensure system integrity.
-- Change all administrator and SYSTEM account passwords on the affected system and any connected systems to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
-- Implement additional monitoring and logging on the affected system and similar environments to detect any recurrence of the threat or related suspicious activities.
+- If confirmed benign:
+  - Reverse any temporary containment and record the exact evidence that confirmed the workflow: service fields, subject and logon IDs, affected host, and recurrence or change context.
+  - Build any exception only from the stable workflow anchors validated above, not from a broad user, host, or service-name match.
+- If suspicious but unconfirmed:
+  - Preserve the alert, original Event ID 4697 record, related 4624/4648 records, `winlog.record_id` values, service configuration, and the service binary named by `winlog.event_data.ServiceFileName` before containment.
+  - Apply reversible containment tied to the findings, such as isolating the host if lateral movement risk is present, restricting the subject account, or disabling the new service after preserving its configuration. Avoid deleting the service or binary until maliciousness and scope are clear.
+- If confirmed malicious:
+  - Preserve the original Event ID 4697 record, related 4624/4648 records, service configuration, service binary, and recurrence evidence before containment or eradication.
+  - Contain the host and affected account based on the service definition, actor/session evidence, and recurrence pattern; weigh host criticality before isolation.
+  - Disable or stop the malicious service after preserving configuration and binary evidence, then remove the service and service binary only after scope is established.
+  - Reset or rotate credentials for the subject account when logon evidence shows misuse, and review other hosts where the same subject or service pattern created LocalSystem services.
+- Post-incident hardening:
+  - Restrict service creation to controlled deployment accounts and administrative hosts.
+  - Retain Audit Security System Extension success logging and enough Windows Security history to correlate 4624, 4648, and 4697 records.
+  - Record the confirmed benign workflow or malicious service pattern so future alerts can compare exact service, subject, and host evidence.
 
 ==== Setup
 
@@ -102,19 +124,8 @@ Windows services are crucial for running background processes with elevated priv
 *Setup*
 
 
-The 'Audit Security System Extension' logging policy must be configured for (Success)
-Steps to implement the logging policy with Advanced Audit Configuration:
-
-```
-Computer Configuration >
-Policies >
-Windows Settings >
-Security Settings >
-Advanced Audit Policies Configuration >
-Audit Policies >
-System >
-Audit Security System Extension (Success)
-```
+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
@@ -127,7 +138,7 @@ configuration where host.os.type == "windows" and
   (winlog.event_data.ClientProcessId == "0" or winlog.event_data.ParentProcessId == "0") and
   startswith~(user.domain, winlog.computer_name) and winlog.event_data.ServiceAccount == "LocalSystem" and 
   not winlog.event_data.ServiceFileName : (
-    "?:\\Windows\\VeeamVssSupport\\VeeamGuestHelper.exe",
+    "?:\\Windows\\VeeamVssSupport\\VeeamGuestHelper.exe*",
     "?:\\Windows\\VeeamLogShipper\\VeeamLogShipper.exe",
     "%SystemRoot%\\system32\\Drivers\\Crowdstrike\\*-CsInstallerService.exe",
     "\"%windir%\\AdminArsenal\\PDQInventory-Scanner\\service-1\\PDQInventory-Scanner-1.exe\" ",
diff --git a/docs/detections/prebuilt-rules/rule-details/wps-office-exploitation-via-dll-hijack.asciidoc b/docs/detections/prebuilt-rules/rule-details/wps-office-exploitation-via-dll-hijack.asciidoc
index 7c5e60ee64..96334c1c8d 100644
--- a/docs/detections/prebuilt-rules/rule-details/wps-office-exploitation-via-dll-hijack.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/wps-office-exploitation-via-dll-hijack.asciidoc
@@ -36,7 +36,7 @@ Identifies the load of a remote library by the WPS Office promecefpluginhost.exe
 * Data Source: Sysmon
 * Resources: Investigation Guide
 
-*Version*: 105
+*Version*: 106
 
 *Rule authors*: 
 
@@ -52,47 +52,79 @@ Identifies the load of a remote library by the WPS Office promecefpluginhost.exe
 *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 WPS Office Exploitation via DLL Hijack*
 
 
-DLL hijacking exploits the way applications load dynamic link libraries (DLLs), allowing adversaries to execute malicious code. In WPS Office, attackers may exploit vulnerabilities by loading a rogue DLL via the promecefpluginhost.exe process, leveraging the ksoqing protocol. The detection rule identifies suspicious DLL loads from temporary or network paths, signaling potential exploitation attempts.
-
 
 *Possible investigation steps*
 
 
-- Review the alert details to confirm the process name is promecefpluginhost.exe and check if the event category is either "library" or "process" with the action "Image loaded*".
-- Examine the DLL or file path involved in the alert to determine if it matches suspicious paths such as those in the user's Temp directory or network paths like \\Device\\Mup\\** or \\*.
-- Investigate the source of the DLL by checking the file's origin, creation date, and any associated network activity to identify potential malicious downloads or transfers.
-- Analyze the process tree to understand the parent and child processes of promecefpluginhost.exe, looking for any unusual or unexpected behavior that might indicate exploitation.
-- Check for any other alerts or logs related to the same host or user account to identify patterns or repeated attempts of exploitation.
-- Correlate the findings with known vulnerabilities CVE-2024-7262 and CVE-2024-7263 to assess if the observed activity aligns with known exploitation techniques.
+- What WPS library-load path did the alert capture?
+  - Why: WPS loading from cache, device, or UNC paths defines the likely abuse route before identity checks.
+  - Focus: `process.name`, `process.executable`, `process.command_line`, `dll.path`, and `dll.name`.
+  - Implication: escalate when "promecefpluginhost.exe" loads from "Temp\wps\INetCache", "\Device\Mup\", or a UNC path outside the WPS install tree; lower suspicion only when normalized `dll.path` resolves to the same Kingsoft-controlled component path as the loader and no protocol-abuse arguments appear.
+
+- Is the WPS loader the expected Kingsoft component?
+  - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
+  - Implication: escalate when the loader is unsigned, renamed, outside the installed WPS Office directory, or signed by an unexpected publisher; lower suspicion when identity matches a stable Kingsoft WPS component, but continue because a trusted loader can still load an attacker DLL.
+
+- Does the command line and parentage show "ksoqing" protocol abuse?
+  - Focus: loader process events for `host.id` and `process.entity_id`, then `process.command_line`, `process.parent.executable`, and `process.parent.command_line`. !{investigate{"description":"","label":"Process events for the WPS loader","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when "wps.exe" or "et.exe" opens user content with arguments exposing "ksoqing", plugin-service paths, encoded paths, or remote paths; lower suspicion only when parentage and arguments match a recognized controlled-share launch without document-driven protocol handling.
+
+- Does the loaded DLL identity fit a legitimate WPS dependency?
+  - Focus: `dll.hash.sha256`, `dll.pe.original_file_name`, `dll.code_signature.subject_name`, `dll.code_signature.trusted`, and `dll.Ext.relative_file_creation_time`.
+  - Hint: if endpoint file telemetry is available, use `host.id` and `dll.path` to identify the writer or rename event. Missing file telemetry is unresolved, not benign. !{investigate{"description":"","label":"File events for the loaded DLL path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{dll.path}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+  - Implication: escalate when the DLL is unsigned, non-Kingsoft, recently created, recently renamed in `dll.Ext.relative_file_name_modify_time`, or loaded as an unexpected WPS dependency from a remote share; if recency metadata is absent, rely on path, hash, signer, and parentage.
+
+- If local evidence is suspicious or incomplete, do related alerts show follow-on activity?
+  - Focus: child process events from the WPS loader and related alerts for `user.id`, especially WPS document execution, additional library loads, downloader behavior, or child-process alerts from the same workstation.
+    - !{investigate{"description":"","label":"Child process events from the WPS loader","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
+    - !{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 user context is missing or ambiguous, review same-host alerts for `host.id` across the last 48 hours. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
+  - Implication: broaden scope when the same user or host shows repeated WPS-triggered loads, the same `dll.hash.sha256`, the same suspicious path pattern, or follow-on execution; lower urgency when isolated, but do not close if local path or DLL identity remains unresolved.
+
+- Escalate when load path, loader identity, protocol or parentage, DLL signer/hash/recency, or related-alert evidence supports attacker-controlled DLL loading from INetCache, a device path, or UNC path; close only when the same evidence binds to one authorized validation, sandbox, or controlled-share workflow with no contradictory artifacts; preserve artifacts and escalate if evidence is mixed or incomplete.
 
 
 *False positive analysis*
 
 
-- Legitimate software updates or installations may temporarily load DLLs from network paths or temporary directories. Users can create exceptions for known update processes or trusted software installations to prevent false alerts.
-- Some enterprise environments use network-based storage solutions that may trigger alerts when legitimate DLLs are loaded from these paths. Administrators can whitelist specific network paths or devices that are known to host trusted libraries.
-- Custom scripts or automation tools that interact with WPS Office might inadvertently load DLLs from temporary directories. Identifying and excluding these scripts or tools from monitoring can reduce false positives.
-- Security software or system maintenance tools may perform scans or operations that mimic the behavior of DLL hijacking. Users should verify and exclude these tools if they are known to cause benign alerts.
-- In environments where WPS Office is heavily used, consider monitoring the frequency and context of alerts to distinguish between normal usage patterns and potential threats, adjusting the rule parameters accordingly.
+- Authorized vulnerability validation or sandbox detonation can reproduce this load pattern. Confirm scope with outside records when available, and require telemetry alignment on `host.id`, `user.id`, `process.executable`, `process.command_line`, `dll.path`, `dll.hash.sha256`, and `dll.code_signature.subject_name`. If not a known test, default to suspicious.
+- Controlled software distribution or application virtualization can serve WPS components from a managed share. Confirm `dll.path` stays on that exact share, `dll.hash.sha256` and `dll.code_signature.subject_name` match the expected Kingsoft component, and parentage lacks document-driven protocol or plugin-path arguments. Without inventories, use recurrence only to validate the same stable share, hash, signer, `process.executable`, `host.id`, and `user.id` workflow before exceptioning.
+- Build exceptions only from the minimum confirmed workflow: stable `process.executable`, `process.code_signature.subject_name`, `dll.path`, `dll.hash.sha256`, `dll.code_signature.subject_name`, and bounded `host.id` or `user.id` scope. Avoid exceptions on `process.name` alone for "promecefpluginhost.exe", "Temp\wps\INetCache", or UNC prefixes.
 
 
 *Response and remediation*
 
 
-- Isolate the affected system from the network immediately to prevent further exploitation or lateral movement by the attacker.
-- Terminate the promecefpluginhost.exe process to stop any ongoing malicious activity and prevent further DLL hijacking attempts.
-- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious DLLs or other malware.
-- Review and clean up the temporary and network paths identified in the detection query, specifically focusing on the AppData\Local\Temp\wps\INetCache directory and any suspicious network shares.
-- Apply patches or updates for WPS Office to address the vulnerabilities CVE-2024-7262 and CVE-2024-7263, ensuring that the software is up to date and less susceptible to exploitation.
-- Monitor for any further suspicious activity related to the ksoqing protocol or similar DLL hijacking attempts, using enhanced logging and alerting mechanisms.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- If confirmed benign, record the exact workflow evidence first: loader identity, `process.command_line`, DLL path/hash/signer, and bounded `host.id` or `user.id` scope. Then reverse temporary containment and create an exception only for that bounded workflow.
+- If suspicious but unconfirmed, preserve the alert, host/user scope, `process.entity_id`, parent lineage, `dll.path`, `dll.hash.sha256`, and DLL signer/recency evidence before containment. Use reversible actions first, such as restricting a non-business remote share named in `dll.path`, quarantining a recovered lure document, or temporarily restricting WPS on the affected host; isolate only when follow-on execution or repeated malicious loads justify the interruption.
+- If confirmed malicious, isolate the host through endpoint response after evidence preservation, then terminate the WPS loader chain if it is still active and block confirmed malicious `dll.hash.sha256` values and remote shares from `dll.path`. If endpoint response is unavailable, hand off the preserved process, DLL, host, and user identifiers to the team that can contain the system or share.
+- Eradicate only artifacts tied to the investigation: remove the malicious DLL, recovered lure document, and staged WPS abuse files after scope review for the same `dll.hash.sha256`, `dll.path`, WPS parentage, `host.id`, and `user.id`. Upgrade WPS Office to a vendor-supported release that remediates both CVE-2024-7262 and CVE-2024-7263.
+- Post-incident hardening: restrict WPS Office library loads from user-writable and UNC paths where feasible, retain process and library-load telemetry, and document any adjacent variant observed during triage, such as alternate WPS protocol arguments or related "promecefpluginhost.exe" load paths.
+
+
+==== 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-7-setup[Sysmon Event ID 7 - Image Loaded]
+
 
 ==== Rule query
 
diff --git a/docs/index.asciidoc b/docs/index.asciidoc
index 6b5e540159..9f95b7ee35 100644
--- a/docs/index.asciidoc
+++ b/docs/index.asciidoc
@@ -129,3 +129,5 @@ include::detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rules-
 include::detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rules-8-19-22-appendix.asciidoc[]
 
 include::detections/prebuilt-rules/downloadable-packages/8-19-23/prebuilt-rules-8-19-23-appendix.asciidoc[]
+
+include::detections/prebuilt-rules/downloadable-packages/8-19-24/prebuilt-rules-8-19-24-appendix.asciidoc[]