From 00bd73940c40b9bb2691ccb18676de155488b1e4 Mon Sep 17 00:00:00 2001
From: tradebot-elastic <178941316+tradebot-elastic@users.noreply.github.com>
Date: Tue, 24 Feb 2026 16:52:26 +0000
Subject: [PATCH] Update latest docs

---
 ...ed-default-telnet-port-connection.asciidoc | 138 +++++++
 ...tegrations-by-destination-address.asciidoc | 117 ++++++
 ...le-integrations-by-source-address.asciidoc | 118 ++++++
 ...ultiple-integrations-by-user-name.asciidoc | 128 +++++++
 ...-different-att-ck-tactics-by-host.asciidoc | 136 +++++++
 ...dduty-member-account-manipulation.asciidoc | 163 ++++++++
 ...idc-provider-created-by-rare-user.asciidoc | 165 ++++++++
 ...-16-aws-iam-saml-provider-created.asciidoc | 161 ++++++++
 ...erations-performed-via-cloudshell.asciidoc | 165 ++++++++
 ...ntory-reconnaissance-by-rare-user.asciidoc | 145 ++++++++
 ...f-program-or-map-load-via-bpftool.asciidoc | 137 +++++++
 ...bpf-program-tampering-via-bpftool.asciidoc | 131 +++++++
 ...-clearing-windows-console-history.asciidoc | 152 ++++++++
 ...g-interpreter-via-windows-scripts.asciidoc | 156 ++++++++
 ...on-large-language-model-endpoints.asciidoc | 186 +++++++++
 ...alerts-on-similar-user-identities.asciidoc | 162 ++++++++
 ...t-modification-by-an-unusual-user.asciidoc | 110 ++++++
 ...precated-adobe-hijack-persistence.asciidoc | 153 ++++++++
 ...executable-stored-in-the-registry.asciidoc | 125 +++++++
 ...-m365-exchange-dlp-policy-deleted.asciidoc | 113 ++++++
 ...orted-by-user-as-malware-or-phish.asciidoc | 123 ++++++
 ...nce-potential-ransomware-activity.asciidoc | 117 ++++++
 ...e-unusual-volume-of-file-deletion.asciidoc | 117 ++++++
 ...ser-restricted-from-sending-email.asciidoc | 112 ++++++
 ...365-teams-external-access-enabled.asciidoc | 118 ++++++
 ...d-m365-teams-guest-access-enabled.asciidoc | 117 ++++++
 ...tial-powershell-obfuscated-script.asciidoc | 164 ++++++++
 ...-service-executable-file-creation.asciidoc | 122 ++++++
 ...on-a-process-exhibiting-cpu-spike.asciidoc | 169 +++++++++
 ...tection-via-registry-modification.asciidoc | 136 +++++++
 ...count-creation-by-an-unusual-user.asciidoc | 109 ++++++
 ...truction-via-method-string-access.asciidoc | 223 +++++++++++
 ...-elastic-agent-service-terminated.asciidoc | 146 ++++++++
 ...-alert-followed-by-telemetry-loss.asciidoc | 131 +++++++
 ...twork-security-alerts-correlation.asciidoc | 156 ++++++++
 ...entity-credential-issuer-modified.asciidoc | 145 ++++++++
 ...-authentication-by-unusual-client.asciidoc | 152 ++++++++
 ...edrive-accessed-by-unusual-client.asciidoc | 158 ++++++++
 ...unusual-cloud-device-registration.asciidoc | 143 +++++++
 ...n-via-windows-subsystem-for-linux.asciidoc | 156 ++++++++
 ...s-traffic-from-an-unusual-process.asciidoc | 111 ++++++
 ...in-followed-by-siem-alert-by-user.asciidoc | 104 ++++++
 ...ocess-arguments-in-an-rdp-session.asciidoc | 138 +++++++
 ...high-mean-of-rdp-session-duration.asciidoc | 139 +++++++
 ...-variance-in-rdp-session-duration.asciidoc | 139 +++++++
 ...discovery-via-kprobes-and-tracefs.asciidoc | 130 +++++++
 ...module-load-from-unusual-location.asciidoc | 179 +++++++++
 ...-module-load-via-built-in-utility.asciidoc | 226 +++++++++++
 ...m-a-newly-observed-source-address.asciidoc | 142 +++++++
 ...alerts-from-a-newly-observed-user.asciidoc | 124 ++++++
 ...so-authentication-errors-for-user.asciidoc | 142 +++++++
 ...rts-in-same-att-ck-tactic-by-host.asciidoc | 126 +++++++
 ...-multiple-alerts-involving-a-user.asciidoc | 121 ++++++
 ...ts-on-a-host-exhibiting-cpu-spike.asciidoc | 171 +++++++++
 ...tiple-external-edr-alerts-by-host.asciidoc | 131 +++++++
 ...arning-alerts-by-influencer-field.asciidoc | 103 +++++
 ...16-newly-observed-fortigate-alert.asciidoc | 119 ++++++
 ...ved-high-severity-detection-alert.asciidoc | 122 ++++++
 ...rved-high-severity-suricata-alert.asciidoc | 118 ++++++
 ...ful-login-after-credential-attack.asciidoc | 250 +++++++++++++
 ...-user-assigned-administrator-role.asciidoc | 120 ++++++
 ...3-bucket-ransomware-note-uploaded.asciidoc | 169 +++++++++
 ...ruction-via-environment-variables.asciidoc | 210 +++++++++++
 ...or-port-forwarding-via-ssh-option.asciidoc | 164 ++++++++
 ...-tunneling-and-or-port-forwarding.asciidoc | 216 +++++++++++
 ...rshell-based-on-alert-correlation.asciidoc | 170 +++++++++
 ...notepad-markdown-rce-exploitation.asciidoc | 117 ++++++
 ...brute-force-device-token-rotation.asciidoc | 158 ++++++++
 ...ial-okta-brute-force-multi-source.asciidoc | 168 +++++++++
 ...credential-stuffing-single-source.asciidoc | 185 +++++++++
 ...-okta-password-spray-multi-source.asciidoc | 173 +++++++++
 ...okta-password-spray-single-source.asciidoc | 188 ++++++++++
 ...ershell-hacktool-script-by-author.asciidoc | 190 ++++++++++
 ...hacktool-script-by-function-names.asciidoc | 352 ++++++++++++++++++
 ...bfuscated-script-via-high-entropy.asciidoc | 190 ++++++++++
 ...cktick-escaped-variable-expansion.asciidoc | 211 +++++++++++
 ...ia-character-array-reconstruction.asciidoc | 194 ++++++++++
 ...enated-dynamic-command-invocation.asciidoc | 221 +++++++++++
 ...high-numeric-character-proportion.asciidoc | 208 +++++++++++
 ...tion-via-invalid-escape-sequences.asciidoc | 226 +++++++++++
 ...-obfuscation-via-reverse-keywords.asciidoc | 213 +++++++++++
 ...ion-via-special-character-overuse.asciidoc | 227 +++++++++++
 ...uscation-via-string-concatenation.asciidoc | 213 +++++++++++
 ...obfuscation-via-string-reordering.asciidoc | 235 ++++++++++++
 ...-process-injection-via-powershell.asciidoc | 198 ++++++++++
 ...ial-timestomp-in-executable-files.asciidoc | 166 +++++++++
 ...ia-negative-index-string-reversal.asciidoc | 204 ++++++++++
 ...19-16-powershell-psreflect-script.asciidoc | 184 +++++++++
 ...ell-script-block-logging-disabled.asciidoc | 187 ++++++++++
 ...ncryption-decryption-capabilities.asciidoc | 184 +++++++++
 ...-token-impersonation-capabilities.asciidoc | 227 +++++++++++
 ...s-defender-tampering-capabilities.asciidoc | 207 ++++++++++
 ...wershell-share-enumeration-script.asciidoc | 215 +++++++++++
 ...ery-related-windows-api-functions.asciidoc | 246 ++++++++++++
 ...us-payload-encoded-and-compressed.asciidoc | 203 ++++++++++
 ...gram-files-directory-masquerading.asciidoc | 147 ++++++++
 ...connections-made-from-a-source-ip.asciidoc | 139 +++++++
 ...nections-made-to-a-destination-ip.asciidoc | 138 +++++++
 ...er-of-processes-in-an-rdp-session.asciidoc | 138 +++++++
 ...16-spike-in-remote-file-transfers.asciidoc | 139 +++++++
 ...al-movement-from-compromised-host.asciidoc | 147 ++++++++
 ...command-prompt-network-connection.asciidoc | 179 +++++++++
 ...s-execution-from-a-mounted-device.asciidoc | 153 ++++++++
 ...ous-net-reflection-via-powershell.asciidoc | 205 ++++++++++
 ...able-encoded-in-powershell-script.asciidoc | 176 +++++++++
 ...ious-windows-powershell-arguments.asciidoc | 226 +++++++++++
 ...y-via-dmidecode-from-parent-shell.asciidoc | 173 +++++++++
 ...-16-unusual-remote-file-directory.asciidoc | 139 +++++++
 ...-16-unusual-remote-file-extension.asciidoc | 139 +++++++
 ...-8-19-16-unusual-remote-file-size.asciidoc | 138 +++++++
 ...al-time-or-day-for-an-rdp-session.asciidoc | 139 +++++++
 .../prebuilt-rules-8-19-16-appendix.asciidoc  | 117 ++++++
 .../prebuilt-rules-8-19-16-summary.asciidoc   | 234 ++++++++++++
 ...ebuilt-rules-downloadable-updates.asciidoc |   5 +
 .../prebuilt-rules-reference.asciidoc         | 294 ++++++++-------
 .../prebuilt-rules/rule-desc-index.asciidoc   |  73 ++--
 ...ed-default-telnet-port-connection.asciidoc |   4 +-
 ...tegrations-by-destination-address.asciidoc |   5 +-
 ...le-integrations-by-source-address.asciidoc |   5 +-
 ...ultiple-integrations-by-user-name.asciidoc |  16 +-
 ...-different-att-ck-tactics-by-host.asciidoc |   8 +-
 ...dduty-member-account-manipulation.asciidoc | 163 ++++++++
 ...idc-provider-created-by-rare-user.asciidoc | 165 ++++++++
 .../aws-iam-saml-provider-created.asciidoc    | 161 ++++++++
 ...erations-performed-via-cloudshell.asciidoc | 165 ++++++++
 ...ntory-reconnaissance-by-rare-user.asciidoc | 145 ++++++++
 ...f-program-or-map-load-via-bpftool.asciidoc | 137 +++++++
 ...bpf-program-tampering-via-bpftool.asciidoc | 131 +++++++
 .../clearing-windows-console-history.asciidoc |  11 +-
 ...g-interpreter-via-windows-scripts.asciidoc |  22 +-
 ...on-large-language-model-endpoints.asciidoc |  19 +-
 ...alerts-on-similar-user-identities.asciidoc | 162 ++++++++
 ...t-modification-by-an-unusual-user.asciidoc |   2 +-
 ...precated-adobe-hijack-persistence.asciidoc | 153 ++++++++
 ...executable-stored-in-the-registry.asciidoc | 125 +++++++
 ...-m365-exchange-dlp-policy-deleted.asciidoc | 113 ++++++
 ...orted-by-user-as-malware-or-phish.asciidoc | 123 ++++++
 ...nce-potential-ransomware-activity.asciidoc | 117 ++++++
 ...e-unusual-volume-of-file-deletion.asciidoc | 117 ++++++
 ...ser-restricted-from-sending-email.asciidoc | 112 ++++++
 ...365-teams-external-access-enabled.asciidoc | 118 ++++++
 ...d-m365-teams-guest-access-enabled.asciidoc | 117 ++++++
 ...ge-transport-agent-install-script.asciidoc | 100 +++++
 ...tial-powershell-obfuscated-script.asciidoc | 164 ++++++++
 ...cript-with-discovery-capabilities.asciidoc | 238 ++++++++++++
 ...-execution-capabilities-via-winrm.asciidoc | 106 ++++++
 ...-service-executable-file-creation.asciidoc | 122 ++++++
 ...nusual-discovery-activity-by-user.asciidoc |  62 +++
 ...on-a-process-exhibiting-cpu-spike.asciidoc |   3 +-
 ...tection-via-registry-modification.asciidoc |   8 +-
 ...t-capabilities-via-built-in-tools.asciidoc |   5 +-
 ...count-creation-by-an-unusual-user.asciidoc |   2 +-
 ...truction-via-method-string-access.asciidoc | 109 ++++--
 .../elastic-agent-service-terminated.asciidoc |  16 +-
 ...-alert-followed-by-telemetry-loss.asciidoc | 131 +++++++
 ...twork-security-alerts-correlation.asciidoc |  16 +-
 ...or-token-user-impersonation-abuse.asciidoc |   2 +-
 ...entity-credential-issuer-modified.asciidoc | 145 ++++++++
 ...-authentication-by-unusual-client.asciidoc | 152 ++++++++
 ...edrive-accessed-by-unusual-client.asciidoc | 158 ++++++++
 ...unusual-cloud-device-registration.asciidoc | 143 +++++++
 .../execution-of-an-unsigned-service.asciidoc |   2 +-
 ...n-via-windows-subsystem-for-linux.asciidoc |  14 +-
 ...s-traffic-from-an-unusual-process.asciidoc | 111 ++++++
 ...in-followed-by-siem-alert-by-user.asciidoc | 104 ++++++
 ...ocess-arguments-in-an-rdp-session.asciidoc |   8 +-
 ...high-mean-of-rdp-session-duration.asciidoc |   8 +-
 ...-variance-in-rdp-session-duration.asciidoc |   8 +-
 ...discovery-via-kprobes-and-tracefs.asciidoc | 130 +++++++
 ...module-load-from-unusual-location.asciidoc | 179 +++++++++
 ...-module-load-via-built-in-utility.asciidoc | 226 +++++++++++
 ...m-a-newly-observed-source-address.asciidoc |  18 +-
 ...alerts-from-a-newly-observed-user.asciidoc |   5 +-
 ...so-authentication-errors-for-user.asciidoc | 142 +++++++
 ...rts-in-same-att-ck-tactic-by-host.asciidoc |   5 +-
 .../multiple-alerts-involving-a-user.asciidoc |   5 +-
 ...ts-on-a-host-exhibiting-cpu-spike.asciidoc |   3 +-
 ...tiple-external-edr-alerts-by-host.asciidoc |   5 +-
 ...arning-alerts-by-influencer-field.asciidoc |   5 +-
 .../newly-observed-fortigate-alert.asciidoc   |   7 +-
 ...ved-high-severity-detection-alert.asciidoc |   8 +-
 ...rved-high-severity-suricata-alert.asciidoc |   6 +-
 .../okta-admin-console-login-failure.asciidoc | 122 ++++++
 ...ful-login-after-credential-attack.asciidoc | 250 +++++++++++++
 ...-user-assigned-administrator-role.asciidoc | 120 ++++++
 ...3-bucket-ransomware-note-uploaded.asciidoc |   3 +-
 ...ruction-via-environment-variables.asciidoc | 104 ++++--
 ...or-port-forwarding-via-ssh-option.asciidoc |   4 +-
 ...-tunneling-and-or-port-forwarding.asciidoc |  17 +-
 ...rshell-based-on-alert-correlation.asciidoc | 105 +++---
 ...notepad-markdown-rce-exploitation.asciidoc | 117 ++++++
 ...brute-force-device-token-rotation.asciidoc | 158 ++++++++
 ...ial-okta-brute-force-multi-source.asciidoc | 168 +++++++++
 ...credential-stuffing-single-source.asciidoc | 185 +++++++++
 ...-okta-password-spray-multi-source.asciidoc | 173 +++++++++
 ...okta-password-spray-single-source.asciidoc | 188 ++++++++++
 ...ershell-hacktool-script-by-author.asciidoc |  99 +++--
 ...hacktool-script-by-function-names.asciidoc | 125 +++----
 ...bfuscated-script-via-high-entropy.asciidoc | 190 ++++++++++
 ...cktick-escaped-variable-expansion.asciidoc | 109 ++++--
 ...ia-character-array-reconstruction.asciidoc |  90 +++--
 ...enated-dynamic-command-invocation.asciidoc | 118 ++++--
 ...high-numeric-character-proportion.asciidoc |  90 +++--
 ...high-special-character-proportion.asciidoc | 124 +++++-
 ...tion-via-invalid-escape-sequences.asciidoc | 118 ++++--
 ...-obfuscation-via-reverse-keywords.asciidoc | 112 ++++--
 ...ion-via-special-character-overuse.asciidoc | 120 ++++--
 ...uscation-via-string-concatenation.asciidoc | 112 ++++--
 ...obfuscation-via-string-reordering.asciidoc | 112 ++++--
 ...-process-injection-via-powershell.asciidoc |  95 +++--
 ...ial-timestomp-in-executable-files.asciidoc | 166 +++++++++
 ...ia-negative-index-string-reversal.asciidoc |  96 +++--
 .../powershell-psreflect-script.asciidoc      | 123 +++---
 ...ell-script-block-logging-disabled.asciidoc |  88 +++--
 ...-archive-compression-capabilities.asciidoc | 146 +++++++-
 ...ncryption-decryption-capabilities.asciidoc |  84 ++++-
 ...cript-with-log-clear-capabilities.asciidoc | 106 +++++-
 ...ord-policy-discovery-capabilities.asciidoc |  98 ++++-
 ...-token-impersonation-capabilities.asciidoc | 125 ++++---
 ...s-defender-tampering-capabilities.asciidoc | 126 ++++---
 ...wershell-share-enumeration-script.asciidoc | 111 ++++--
 ...ery-related-windows-api-functions.asciidoc | 103 +++--
 ...us-payload-encoded-and-compressed.asciidoc | 133 ++++---
 ...gram-files-directory-masquerading.asciidoc |  20 +-
 ...connections-made-from-a-source-ip.asciidoc |   8 +-
 ...nections-made-to-a-destination-ip.asciidoc |   8 +-
 ...er-of-processes-in-an-rdp-session.asciidoc |   8 +-
 .../spike-in-remote-file-transfers.asciidoc   |   8 +-
 ...al-movement-from-compromised-host.asciidoc |  20 +-
 ...command-prompt-network-connection.asciidoc | 179 +++++++++
 ...s-execution-from-a-mounted-device.asciidoc |  27 +-
 ...ous-net-reflection-via-powershell.asciidoc | 152 ++++----
 ...able-encoded-in-powershell-script.asciidoc | 121 +++---
 ...ious-windows-powershell-arguments.asciidoc |  11 +-
 ...y-via-dmidecode-from-parent-shell.asciidoc |  13 +-
 .../unusual-remote-file-directory.asciidoc    |   8 +-
 .../unusual-remote-file-extension.asciidoc    |   8 +-
 .../unusual-remote-file-size.asciidoc         |   8 +-
 ...al-time-or-day-for-an-rdp-session.asciidoc |   8 +-
 docs/index.asciidoc                           |   2 +
 240 files changed, 27768 insertions(+), 1458 deletions(-)
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-accepted-default-telnet-port-connection.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-destination-address.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-source-address.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-user-name.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-alerts-in-different-att-ck-tactics-by-host.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-guardduty-member-account-manipulation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-iam-oidc-provider-created-by-rare-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-iam-saml-provider-created.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-bpf-program-or-map-load-via-bpftool.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-bpf-program-tampering-via-bpftool.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-clearing-windows-console-history.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-command-and-scripting-interpreter-via-windows-scripts.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-connection-to-common-large-language-model-endpoints.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-correlated-alerts-on-similar-user-identities.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-adobe-hijack-persistence.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-encoded-executable-stored-in-the-registry.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-exchange-dlp-policy-deleted.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-teams-external-access-enabled.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-teams-guest-access-enabled.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-potential-powershell-obfuscated-script.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-detection-alert-on-a-process-exhibiting-cpu-spike.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-disabling-lsa-protection-via-registry-modification.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-dmsa-account-creation-by-an-unusual-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-dynamic-iex-reconstruction-via-method-string-access.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-elastic-agent-service-terminated.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-elastic-defend-alert-followed-by-telemetry-loss.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-elastic-defend-and-network-security-alerts-correlation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-entra-id-federated-identity-credential-issuer-modified.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-entra-id-unusual-cloud-device-registration.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-execution-via-windows-subsystem-for-linux.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-fortigate-socks-traffic-from-an-unusual-process.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-high-mean-of-process-arguments-in-an-rdp-session.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-high-mean-of-rdp-session-duration.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-high-variance-in-rdp-session-duration.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-kernel-module-load-from-unusual-location.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-kernel-module-load-via-built-in-utility.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-lateral-movement-alerts-from-a-newly-observed-source-address.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-lateral-movement-alerts-from-a-newly-observed-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-m365-identity-unusual-sso-authentication-errors-for-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-alerts-involving-a-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-alerts-on-a-host-exhibiting-cpu-spike.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-external-edr-alerts-by-host.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-machine-learning-alerts-by-influencer-field.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-newly-observed-fortigate-alert.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-newly-observed-high-severity-detection-alert.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-newly-observed-high-severity-suricata-alert.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-okta-successful-login-after-credential-attack.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-okta-user-assigned-administrator-role.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-linux-tunneling-and-or-port-forwarding.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-malicious-powershell-based-on-alert-correlation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-notepad-markdown-rce-exploitation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-brute-force-device-token-rotation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-brute-force-multi-source.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-credential-stuffing-single-source.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-password-spray-multi-source.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-password-spray-single-source.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-hacktool-script-by-author.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-hacktool-script-by-function-names.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscated-script-via-high-entropy.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-reverse-keywords.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-special-character-overuse.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-string-concatenation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-string-reordering.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-process-injection-via-powershell.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-timestomp-in-executable-files.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-obfuscation-via-negative-index-string-reversal.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-psreflect-script.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-script-block-logging-disabled.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-script-with-encryption-decryption-capabilities.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-script-with-token-impersonation-capabilities.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-script-with-windows-defender-tampering-capabilities.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-share-enumeration-script.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-suspicious-discovery-related-windows-api-functions.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-suspicious-payload-encoded-and-compressed.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-program-files-directory-masquerading.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-spike-in-number-of-connections-made-from-a-source-ip.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-spike-in-number-of-connections-made-to-a-destination-ip.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-spike-in-number-of-processes-in-an-rdp-session.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-spike-in-remote-file-transfers.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspected-lateral-movement-from-compromised-host.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspicious-command-prompt-network-connection.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspicious-execution-from-a-mounted-device.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspicious-net-reflection-via-powershell.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspicious-portable-executable-encoded-in-powershell-script.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspicious-windows-powershell-arguments.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-system-information-discovery-via-dmidecode-from-parent-shell.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-unusual-remote-file-directory.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-unusual-remote-file-extension.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-unusual-remote-file-size.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-unusual-time-or-day-for-an-rdp-session.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rules-8-19-16-appendix.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rules-8-19-16-summary.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-guardduty-member-account-manipulation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-iam-oidc-provider-created-by-rare-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-iam-saml-provider-created.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/bpf-program-or-map-load-via-bpftool.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/bpf-program-tampering-via-bpftool.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/correlated-alerts-on-similar-user-identities.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-adobe-hijack-persistence.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-encoded-executable-stored-in-the-registry.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-m365-exchange-dlp-policy-deleted.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-m365-teams-external-access-enabled.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-m365-teams-guest-access-enabled.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-microsoft-exchange-transport-agent-install-script.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-potential-powershell-obfuscated-script.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-powershell-script-with-discovery-capabilities.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-powershell-script-with-remote-execution-capabilities-via-winrm.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/deprecated-unusual-discovery-activity-by-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/elastic-defend-alert-followed-by-telemetry-loss.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/entra-id-federated-identity-credential-issuer-modified.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/entra-id-unusual-cloud-device-registration.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/fortigate-socks-traffic-from-an-unusual-process.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/kernel-module-load-from-unusual-location.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/kernel-module-load-via-built-in-utility.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/m365-identity-unusual-sso-authentication-errors-for-user.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/okta-admin-console-login-failure.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/okta-successful-login-after-credential-attack.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/okta-user-assigned-administrator-role.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-notepad-markdown-rce-exploitation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-okta-brute-force-device-token-rotation.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-okta-brute-force-multi-source.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-okta-credential-stuffing-single-source.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-okta-password-spray-multi-source.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-okta-password-spray-single-source.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscated-script-via-high-entropy.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/potential-timestomp-in-executable-files.asciidoc
 create mode 100644 docs/detections/prebuilt-rules/rule-details/suspicious-command-prompt-network-connection.asciidoc

diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-accepted-default-telnet-port-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-accepted-default-telnet-port-connection.asciidoc
new file mode 100644
index 0000000000..128d7966ba
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-accepted-default-telnet-port-connection.asciidoc
@@ -0,0 +1,138 @@
+[[prebuilt-rule-8-19-16-accepted-default-telnet-port-connection]]
+=== Accepted Default Telnet Port Connection
+
+This rule detects network events that may indicate the use of Telnet traffic. Telnet is commonly used by system administrators to remotely control older or embedded systems using the command line shell. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. As a plain-text protocol, it may also expose usernames and passwords to anyone capable of observing the traffic.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* packetbeat-*
+* auditbeat-*
+* filebeat-*
+* logs-network_traffic.*
+* logs-panw.panos*
+* logs-fortinet_fortigate.log-*
+* logs-sonicwall_firewall.log-*
+* logs-suricata.*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* Use Case: Threat Detection
+* Tactic: Command and Control
+* Tactic: Lateral Movement
+* Tactic: Initial Access
+* Data Source: PAN-OS
+* Data Source: Fortinet
+* Data Source: SonicWall
+* Data Source: Suricata
+* Resources: Investigation Guide
+
+*Version*: 111
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Accepted Default Telnet Port Connection*
+
+
+Telnet, a protocol for remote command-line access, is often used in legacy systems. Its lack of encryption makes it vulnerable, allowing attackers to intercept credentials or use it as a backdoor. The detection rule identifies unencrypted Telnet traffic on port 23, flagging connections that bypass typical security measures, thus highlighting potential unauthorized access attempts.
+
+
+*Possible investigation steps*
+
+
+- Review the network traffic logs to identify the source IP address associated with the Telnet connection on port 23. Determine if the source IP is internal or external to the organization.
+- Check the destination IP address to ascertain if it belongs to a critical system or a legacy device that might still use Telnet for management purposes.
+- Investigate the timeline of the connection event to see if there are any patterns or repeated attempts, which could indicate a persistent threat or automated attack.
+- Analyze any associated user accounts or credentials used during the Telnet session to verify if they are legitimate and authorized for remote access.
+- Correlate the Telnet connection event with other security alerts or logs to identify any related suspicious activities, such as failed login attempts or unusual data transfers.
+- Assess the network segment where the Telnet traffic was detected to determine if it is appropriately segmented and secured against unauthorized access.
+- Consider implementing network security measures, such as disabling Telnet on devices or replacing it with secure alternatives like SSH, to prevent future unauthorized access attempts.
+
+
+*False positive analysis*
+
+
+- Legacy systems or devices that require Telnet for management may trigger alerts. To manage this, create exceptions for specific IP addresses or subnets known to host these systems.
+- Internal network monitoring tools that use Telnet for legitimate purposes might be flagged. Identify these tools and exclude their traffic from the rule to prevent unnecessary alerts.
+- Lab environments or test networks where Telnet is used for educational or testing purposes can cause false positives. Implement network segmentation and apply exceptions to these environments to reduce noise.
+- Automated scripts or maintenance tasks that utilize Telnet for routine operations may be mistakenly identified. Document these tasks and whitelist their associated traffic patterns to avoid false alerts.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any active Telnet sessions on the affected system to disrupt potential attacker activities.
+- Conduct a thorough review of system logs and network traffic to identify any unauthorized access or data manipulation that may have occurred.
+- Change all credentials that may have been exposed through Telnet traffic, prioritizing those with administrative privileges.
+- Implement network segmentation to restrict Telnet access to only necessary internal systems, ensuring it is not exposed to the internet.
+- Deploy encryption protocols such as SSH to replace Telnet for remote command-line access, enhancing security for remote management.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for additional security measures.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+(event.dataset:(fortinet_fortigate.log or network_traffic.flow
+        or sonicwall_firewall.log or suricata.eve or panw.panos)
+    or event.category:(network or network_traffic))
+    and event.type:(connection and not end) and not event.action:(
+        flow_dropped or flow_denied or denied or deny or
+        flow_terminated or timeout or Reject or network_flow)
+    and destination.port:23
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Command and Control
+** ID: TA0011
+** Reference URL: https://attack.mitre.org/tactics/TA0011/
+* Tactic:
+** Name: Lateral Movement
+** ID: TA0008
+** Reference URL: https://attack.mitre.org/tactics/TA0008/
+* Technique:
+** Name: Remote Services
+** ID: T1021
+** Reference URL: https://attack.mitre.org/techniques/T1021/
+* 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-16/prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-destination-address.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-destination-address.asciidoc
new file mode 100644
index 0000000000..1ac4cb6fee
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-destination-address.asciidoc
@@ -0,0 +1,117 @@
+[[prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-destination-address]]
+=== Alerts From Multiple Integrations by Destination Address
+
+This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same destination.ip are triggered. Analysts can use this to prioritize triage and response, as these IP address is more likely to be related to a compromise.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 30m
+
+*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* 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 Alerts From Multiple Integrations by Destination Address*
+
+
+The detection rule uses alert data to determine when multiple alerts from different integrations involving the same destination.ip are triggered.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific host involved and the different modules and rules that triggered the alert.
+- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
+- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
+- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
+- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
+- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
+
+
+*False positive analysis*
+
+
+- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.
+- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
+- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
+- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
+- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.
+
+
+*Response and remediation*
+
+
+- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
+- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
+- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from .alerts-security.*
+
+// any alerts excluding low severity, threat_match and machine_learning rules 
+| where kibana.alert.rule.name is not null and destination.ip is not null and kibana.alert.risk_score > 21 and not kibana.alert.rule.type in ("threat_match", "machine_learning") and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
+
+// group alerts by destination.ip and extract values of interest for alert triage
+| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
+        Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
+        Esql.event_category_distinct_count = COUNT_DISTINCT(event.category),
+        Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),
+        Esql.event_module_values = VALUES(event.module),
+        Esql.rule_name_values = VALUES(kibana.alert.rule.name),
+        Esql.message_values = VALUES(message),
+        Esql.event_category_values = VALUES(event.category),
+        Esql.event_action_values = VALUES(event.action),
+        Esql.source_ip_values = VALUES(source.ip),
+        Esql.host_id_values = VALUES(host.id),
+        Esql.agent_id_values = VALUES(agent.id),
+        Esql.user_name_values = VALUES(user.name),
+        Esql.rule_severity_values = VALUES(kibana.alert.risk_score) by destination.ip
+
+// filter for alerts from same destination.ip reported by different integrations with unique categories and with different severity levels or presence of high severity alerts
+| where Esql.event_module_distinct_count >= 2 and Esql.event_category_distinct_count >= 2 and (Esql.rule_risk_score_distinct_count >= 2 or Esql.rule_severity_values == 73 or Esql.rule_severity_values == 99)
+| keep destination.ip, Esql.*
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-source-address.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-source-address.asciidoc
new file mode 100644
index 0000000000..cdda0ec671
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-source-address.asciidoc
@@ -0,0 +1,118 @@
+[[prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-source-address]]
+=== Alerts From Multiple Integrations by Source Address
+
+This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same source.ip are triggered. Analysts can use this to prioritize triage and response, as these IP addresses are more likely to be related to a compromise.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 30m
+
+*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* 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 Alerts From Multiple Integrations by Source Address*
+
+
+The detection rule uses alert data to determine when multiple alerts from different integrations involving the same source.ip are triggered.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific host involved and the different modules and rules that triggered the alert.
+- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
+- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
+- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
+- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
+- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
+
+
+*False positive analysis*
+
+
+- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.
+- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
+- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
+- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
+- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.
+
+
+*Response and remediation*
+
+
+- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
+- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
+- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from .alerts-security.*
+
+// any alerts excluding low severity and the noisy ones
+| where kibana.alert.rule.name is not null and source.ip is not null and kibana.alert.risk_score > 21 and
+        not kibana.alert.rule.type in ("threat_match", "machine_learning") and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
+
+// group alerts by source.ip and extract values of interest for alert triage
+| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
+        Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
+        Esql.event_category_distinct_count = COUNT_DISTINCT(event.category),
+        Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),
+        Esql.event_module_values = VALUES(event.module),
+        Esql.rule_name_values = VALUES(kibana.alert.rule.name),
+        Esql.message_values = VALUES(message),
+        Esql.event_category_values = VALUES(event.category),
+        Esql.event_action_values = VALUES(event.action),
+        Esql.destination_ip_values = VALUES(destination.ip),
+        Esql.host_id_values = VALUES(host.id),
+        Esql.agent_id_values = VALUES(agent.id),
+        Esql.user_name_values = VALUES(user.name),
+        Esql.rule_severity_values = VALUES(kibana.alert.risk_score) by source.ip
+
+// filter for alerts from same source.ip reported by different integrations with unique categories and with different severity levels
+| where Esql.event_module_distinct_count >= 2 and Esql.event_category_distinct_count >= 2 and (Esql.rule_risk_score_distinct_count >= 2 or Esql.rule_severity_values == 73 or Esql.rule_severity_values == 99)
+| keep source.ip, Esql.*
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-user-name.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-user-name.asciidoc
new file mode 100644
index 0000000000..a77480c552
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-user-name.asciidoc
@@ -0,0 +1,128 @@
+[[prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-user-name]]
+=== Alerts From Multiple Integrations by User Name
+
+This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same user.name are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 30m
+
+*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* 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 Alerts From Multiple Integrations by User Name*
+
+
+The detection rule uses alert data to determine when multiple alerts from different integrations involving the same user.name are triggered.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific user involved and the different modules and rules that triggered the alert.
+- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
+- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
+- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
+- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
+- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
+
+
+*False positive analysis*
+
+
+- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.
+- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
+- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
+- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
+- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.
+
+
+*Response and remediation*
+
+
+- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
+- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
+- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from .alerts-security.*
+
+// any alerts excluding low severity and the noisy ones
+| where kibana.alert.rule.name is not null and user.name is not null and kibana.alert.risk_score > 21 and
+        not kibana.alert.rule.type in ("threat_match", "machine_learning") and 
+        not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0") and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) and
+        // Top noisy influencing rules
+        // Agent Spoofing - Mismatched Agent ID
+        // Compression DLL Loaded by Unusual Process
+        // Process Termination followed by Deletion 
+        // Suspicious PrintSpooler Service Executable File Creation
+        // Potential PrintNightmare File Modification
+        // Multiple Vault Web Credentials Read
+        // Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score
+        not kibana.alert.rule.rule_id in ("3115bd2c-0baa-4df0-80ea-45e474b5ef93", "d197478e-39f0-4347-a22f-ba654718b148", "09443c92-46b3-45a4-8f25-383b028b258d", "5bb4a95d-5a08-48eb-80db-4c3a63ec78a8", "5e87f165-45c2-4b80-bfa5-52822552c997", "44fc462c-1159-4fa8-b1b7-9b6296ab4f96", "994e40aa-8c85-43de-825e-15f665375ee8")
+        
+// group alerts by user.name and extract values of interest for alert triage
+| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
+        Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
+        Esql.event_category_distinct_count = COUNT_DISTINCT(event.category),
+        Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),
+        Esql.event_module_values = VALUES(event.module),
+        Esql.rule_name_values = VALUES(kibana.alert.rule.name),
+        Esql.message_values = VALUES(message),
+        Esql.event_category_values = VALUES(event.category),
+        Esql.event_action_values = VALUES(event.action),
+        Esql.source_ip_values = VALUES(source.ip),
+        Esql.destination_ip_values = VALUES(destination.ip),
+        Esql.host_id_values = VALUES(host.id),
+        Esql.agent_id_values = VALUES(agent.id),
+        Esql.rule_severity_values = VALUES(kibana.alert.risk_score) by user.name, user.id
+
+// filter for alerts from same destination.ip reported by different integrations with unique categories and with different severity levels
+| where Esql.event_module_distinct_count >= 2 and Esql.event_category_distinct_count >= 2 and (Esql.rule_risk_score_distinct_count >= 2 or Esql.rule_severity_values == 73 or Esql.rule_severity_values == 99)
+| keep user.name, Esql.*
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-alerts-in-different-att-ck-tactics-by-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-alerts-in-different-att-ck-tactics-by-host.asciidoc
new file mode 100644
index 0000000000..2f0b3783a4
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-alerts-in-different-att-ck-tactics-by-host.asciidoc
@@ -0,0 +1,136 @@
+[[prebuilt-rule-8-19-16-alerts-in-different-att-ck-tactics-by-host]]
+=== Alerts in Different ATT&CK Tactics by Host
+
+This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered and where the accumulated risk score is higher than a defined threshold. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 1h
+
+*Searches indices from*: now-8h ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* 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 Alerts in Different ATT&CK Tactics by Host*
+
+
+The detection rule identifies hosts with alerts across various attack phases, indicating potential compromise. Adversaries exploit system vulnerabilities, moving through different tactics like execution, persistence, and exfiltration. This rule prioritizes hosts with diverse tactic alerts, aiding analysts in focusing on high-risk threats by correlating alert data to detect complex attack patterns.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts.
+- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
+- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
+- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
+- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
+- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
+
+
+*False positive analysis*
+
+
+- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.
+- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
+- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
+- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
+- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.
+
+
+*Response and remediation*
+
+
+- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
+- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
+- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from .alerts-security.*  metadata _id
+
+// filter for alerts with populated risk score, excluding threat_match rules, deprecated and some other noisy ones.
+| where kibana.alert.risk_score > 0 and
+        kibana.alert.rule.name IS NOT NULL and
+        host.id is not null and event.dataset is not null and
+        kibana.alert.rule.type != "threat_match" and
+        // Top noisy influencing rules
+        not kibana.alert.rule.name in ("Agent Spoofing - Mismatched Agent ID", "Compression DLL Loaded by Unusual Process", "Process Termination followed by Deletion", "Suspicious PrintSpooler Service Executable File Creation", "Potential PrintNightmare File Modification") and
+        not kibana.alert.rule.name like "Deprecated - *" and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
+
+// extract unique counts and values by host.id
+| stats Esql.alerts_count = COUNT(*),
+        Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
+        Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
+        Esql.event_module_values = VALUES(event.module),
+        Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name),
+        Esql.threat_tactic_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.threat.tactic.id),
+        Esql.threat_tactic_name_values = VALUES(kibana.alert.rule.threat.tactic.name),
+        Esql.kibana_alert_risk_score_sum = sum(kibana.alert.risk_score),
+        Esql.process_executable_values = VALUES(process.executable),
+        Esql.process_parent_executable_values = VALUES(process.parent.executable),
+        Esql.process_command_line_values = VALUES(process.command_line),
+        Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id
+
+// divide the sum of risk scores by the total number of alerts
+| eval Esql.risk_alerts_count_ratio = Esql.kibana_alert_risk_score_sum/Esql.alerts_count
+
+// filter for risky hosts by risk score and unique count of rules and tactics
+| where Esql.kibana_alert_rule_name_distinct_count >= 5 and Esql.threat_tactic_id_distinct_count >= 3 and Esql.threat_tactic_id_distinct_count >= 3 and Esql.alerts_count <= 500 and Esql.risk_alerts_count_ratio >= 50
+
+// fiels populated in the resulting alert
+| keep host.id,
+       Esql.alerts_count,
+       Esql.kibana_alert_risk_score_sum,
+       Esql.risk_alerts_count_ratio,
+       Esql.kibana_alert_rule_name_distinct_count,
+       Esql.event_module_values,
+       Esql.kibana_alert_rule_name_values,
+       Esql.threat_tactic_name_values,
+       Esql.process_executable_values,
+       Esql.process_parent_executable_values,
+       Esql.process_command_line_values
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-guardduty-member-account-manipulation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-guardduty-member-account-manipulation.asciidoc
new file mode 100644
index 0000000000..fe5a3db2e8
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-guardduty-member-account-manipulation.asciidoc
@@ -0,0 +1,163 @@
+[[prebuilt-rule-8-19-16-aws-guardduty-member-account-manipulation]]
+=== AWS GuardDuty Member Account Manipulation
+
+Detects attempts to disassociate or manipulate Amazon GuardDuty member accounts within an AWS organization. In multi-account GuardDuty deployments, a delegated administrator account aggregates findings from member accounts. Adversaries may attempt to disassociate member accounts, delete member relationships, stop monitoring members, or delete pending invitations to break this centralized visibility. These actions can be precursors to or alternatives for deleting GuardDuty detectors entirely, allowing attackers to operate undetected in member accounts while the administrator account loses visibility. This rule identifies successful API calls that manipulate GuardDuty member relationships, which are rare in normal operations and warrant immediate investigation.
+
+*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/guardduty/latest/APIReference/API_DisassociateFromAdministratorAccount.html
+* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteMembers.html
+* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_StopMonitoringMembers.html
+* https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html
+* https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS GuardDuty
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating AWS GuardDuty Member Account Manipulation*
+
+
+In AWS Organizations with GuardDuty enabled, a delegated administrator account receives and aggregates security findings from all member accounts. This centralized visibility is critical for detecting threats across the organization. Adversaries who compromise a member account may attempt to break this relationship to operate without triggering alerts visible to the security team.
+
+This rule detects several API actions that manipulate GuardDuty member relationships:
+- `DisassociateFromMasterAccount` / `DisassociateFromAdministratorAccount`: Member account breaks its connection to the administrator
+- `DeleteMembers`: Administrator removes member accounts from GuardDuty
+- `StopMonitoringMembers`: Administrator stops monitoring specific member accounts without fully removing them
+- `DeleteInvitations`: Member account deletes pending invitations, preventing association
+
+These actions are extremely rare in normal operations and can indicate either a compromised account or an attacker preparing to disable GuardDuty entirely.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine who performed the action.
+  - Determine whether the action originated from a member account (disassociation) or the administrator account (deletion/stop monitoring).
+
+- **Review request context**
+  - Check `aws.cloudtrail.request_parameters` to identify which member accounts were affected.
+  - Determine the scope: single account or multiple accounts targeted.
+
+- **Analyze source and access patterns**
+  - Review `source.ip` and `user_agent.original` for anomalous access patterns.
+  - Check if the action occurred outside normal business hours or maintenance windows.
+
+- **Correlate with related activity**
+  - Search for subsequent `DeleteDetector` API calls in the affected member accounts.
+  - Look for other defense evasion indicators: CloudTrail modifications, Config rule deletions, Security Hub changes.
+  - Check for privilege escalation or credential access events preceding this action.
+
+- **Verify business justification**
+  - Confirm with the identified user or team whether there was a legitimate organizational change.
+  - Check for related change tickets or migration documentation.
+
+
+*False positive analysis*
+
+
+- **Organizational restructuring**
+  - Member relationships may change during account migrations or delegated administrator transitions.
+  - Validate against documented organizational changes.
+
+- **Account decommissioning**
+  - Accounts being retired may be removed from GuardDuty before closure.
+  - Confirm this aligns with account lifecycle management processes.
+
+
+*Response and remediation*
+
+
+- **Immediate containment**
+  - If unauthorized, immediately re-associate the affected member accounts with the administrator.
+  - For `StopMonitoringMembers`, use `StartMonitoringMembers` to restore visibility.
+
+- **Investigation**
+  - Audit the affected member accounts for suspicious activity during the visibility gap.
+  - Review CloudTrail for any actions taken while GuardDuty monitoring was disrupted.
+
+- **Hardening**
+  - Restrict `guardduty:DisassociateFromAdministratorAccount`, `guardduty:DeleteMembers`, and related permissions.
+  - Use SCPs to prevent member accounts from disassociating from GuardDuty administrators.
+  - Implement Security Hub controls to detect changes to GuardDuty organization configuration.
+
+
+*Additional information*
+
+- **https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html[AWS GuardDuty Multi-Account Documentation]**
+- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]**
+- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]**
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: "aws.cloudtrail"
+    and event.provider: "guardduty.amazonaws.com"
+    and event.action: (
+        "DisassociateFromAdministratorAccount" or
+        "DeleteMembers" or
+        "StopMonitoringMembers" or
+        "DeleteInvitations" or
+        "DisassociateMembers"
+    )
+    and event.outcome: "success"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
+* Sub-technique:
+** Name: Disable or Modify Tools
+** ID: T1562.001
+** Reference URL: https://attack.mitre.org/techniques/T1562/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-iam-oidc-provider-created-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-iam-oidc-provider-created-by-rare-user.asciidoc
new file mode 100644
index 0000000000..45e4af6985
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-iam-oidc-provider-created-by-rare-user.asciidoc
@@ -0,0 +1,165 @@
+[[prebuilt-rule-8-19-16-aws-iam-oidc-provider-created-by-rare-user]]
+=== AWS IAM OIDC Provider Created by Rare User
+
+Detects when an uncommon user or role creates an OpenID Connect (OIDC) Identity Provider in AWS IAM. OIDC providers enable web identity federation, allowing users authenticated by external identity providers (such as Google, GitHub, or custom OIDC-compliant providers) to assume IAM roles and access AWS resources. Adversaries who have gained administrative access may create rogue OIDC providers to establish persistent, federated access that survives credential rotation. This technique allows attackers to assume roles using tokens from an IdP they control. While OIDC provider creation is benign in some environments, it should still be validated against authorized infrastructure changes.
+
+*Rule type*: new_terms
+
+*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/IAM/latest/APIReference/API_CreateOpenIDConnectProvider.html
+* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html
+* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS IAM
+* Use Case: Identity and Access Audit
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating AWS IAM OIDC Provider Created by Rare User*
+
+
+OpenID Connect (OIDC) providers in AWS IAM enable web identity federation, allowing external identity providers to authenticate users who then assume IAM roles. Common legitimate use cases include GitHub Actions accessing AWS resources, Kubernetes pods authenticating to AWS, and web applications using social login.
+
+This rule detects the first time a specific user or role creates an OIDC provider within an account. While OIDC provider creation is common in some environments, a new user creating one for the first time warrants validation to ensure it's authorized.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` to determine who created the OIDC provider.
+  - Check if this user has created OIDC providers before in other accounts.
+
+- **Review the OIDC provider details**
+  - Examine `aws.cloudtrail.request_parameters` for the provider URL and client IDs.
+  - Identify the external IdP (e.g., GitHub, Google, custom provider).
+
+- **Validate business justification**
+  - Confirm with DevOps or platform teams whether this aligns with CI/CD pipeline setup.
+  - Check for related change tickets or infrastructure-as-code deployments.
+
+- **Check for follow-on activity**
+  - Search for `CreateRole` or `UpdateAssumeRolePolicy` calls that trust the new OIDC provider.
+  - Look for `AssumeRoleWithWebIdentity` calls using the newly created provider.
+
+- **Correlate with other suspicious activity**
+  - Check for preceding privilege escalation or credential access events.
+  - Look for other persistence mechanisms being established concurrently.
+
+
+*False positive analysis*
+
+
+- **CI/CD pipeline integration**
+  - GitHub Actions, GitLab CI, and other CI/CD systems commonly use OIDC for AWS authentication.
+  - Validate against known DevOps workflows.
+
+- **Kubernetes federation**
+  - EKS and self-managed Kubernetes clusters may use OIDC providers for pod identity.
+  - Confirm with platform engineering teams.
+
+- **Infrastructure-as-code deployments**
+  - Terraform, CloudFormation, or other IaC tools may create OIDC providers.
+  - Verify via CI/CD logs.
+
+
+*Response and remediation*
+
+
+- **Immediate containment**
+  - If unauthorized, delete the OIDC provider using `DeleteOpenIDConnectProvider`.
+  - Review and remove any IAM roles that trust the rogue provider.
+
+- **Investigation**
+  - Audit CloudTrail for any `AssumeRoleWithWebIdentity` calls using this provider.
+  - Review all IAM roles with web identity trust relationships.
+
+- **Hardening**
+  - Restrict `iam:CreateOpenIDConnectProvider` permissions to authorized roles.
+  - Implement SCPs to control OIDC provider creation in member accounts.
+  - Enable AWS Config rules to monitor identity provider configurations.
+
+
+*Additional information*
+
+- **https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html[AWS IAM OIDC Providers Documentation]**
+- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]**
+- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]**
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: "aws.cloudtrail"
+    and event.provider: "iam.amazonaws.com"
+    and event.action: "CreateOpenIDConnectProvider"
+    and event.outcome: "success"
+
+----------------------------------
+
+*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: Cloud Accounts
+** ID: T1078.004
+** Reference URL: https://attack.mitre.org/techniques/T1078/004/
+* 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: Trust Modification
+** ID: T1484.002
+** Reference URL: https://attack.mitre.org/techniques/T1484/002/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-iam-saml-provider-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-iam-saml-provider-created.asciidoc
new file mode 100644
index 0000000000..e1a2502d71
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-iam-saml-provider-created.asciidoc
@@ -0,0 +1,161 @@
+[[prebuilt-rule-8-19-16-aws-iam-saml-provider-created]]
+=== AWS IAM SAML Provider Created
+
+Detects the creation of a new SAML Identity Provider (IdP) in AWS IAM. SAML providers enable federated authentication between AWS and external identity providers, allowing users to access AWS resources using credentials from the external IdP. Adversaries who have gained administrative access may create rogue SAML providers to establish persistent, federated access to AWS accounts that survives credential rotation. This technique allows attackers to assume roles and access resources by forging SAML assertions from an IdP they control. Creating a SAML provider is a rare administrative action that should be closely monitored and validated against authorized infrastructure changes.
+
+*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/IAM/latest/APIReference/API_CreateSAMLProvider.html
+* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html
+* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS IAM
+* Use Case: Identity and Access Audit
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating AWS IAM SAML Provider Created*
+
+
+SAML (Security Assertion Markup Language) providers in AWS IAM enable federated authentication, allowing users from external identity providers to access AWS resources without separate AWS credentials. Creating a SAML provider establishes a trust relationship between AWS and the external IdP.
+
+This rule detects successful `CreateSAMLProvider` API calls. In most environments, SAML provider creation is extremely rare—typically only occurring during initial SSO setup or major infrastructure changes. An unauthorized SAML provider creation could enable an attacker to maintain persistent access by forging SAML assertions from an IdP they control.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` to determine who created the SAML provider.
+  - Verify whether this principal is authorized to manage identity federation.
+
+- **Review the SAML provider details**
+  - Examine `aws.cloudtrail.request_parameters` for the SAML provider name and metadata document.
+  - Identify the external IdP URL and signing certificate in the metadata.
+
+- **Validate business justification**
+  - Confirm with identity management or platform teams whether this aligns with planned SSO integration.
+  - Check for related change tickets or infrastructure-as-code deployments.
+
+- **Check for follow-on activity**
+  - Search for `CreateRole` or `UpdateAssumeRolePolicy` calls that reference the new SAML provider.
+  - Look for `AssumeRoleWithSAML` calls using the newly created provider.
+
+- **Correlate with other suspicious activity**
+  - Check for preceding privilege escalation or credential access events.
+  - Look for other persistence mechanisms being established concurrently.
+
+
+*False positive analysis*
+
+
+- **Planned SSO integration**
+  - SAML providers are created during initial setup of identity federation with Okta, Azure AD, or other IdPs.
+  - Validate against documented SSO integration projects.
+
+- **Infrastructure-as-code deployments**
+  - Terraform, CloudFormation, or other IaC tools may create SAML providers as part of automated deployments.
+  - Confirm via CI/CD logs.
+
+
+*Response and remediation*
+
+
+- **Immediate containment**
+  - If unauthorized, delete the SAML provider using `DeleteSAMLProvider`.
+  - Review and remove any IAM roles that trust the rogue provider.
+
+- **Investigation**
+  - Audit CloudTrail for any `AssumeRoleWithSAML` calls using this provider.
+  - Review all IAM roles with SAML trust relationships.
+
+- **Hardening**
+  - Restrict `iam:CreateSAMLProvider` permissions to a limited set of administrative roles.
+  - Implement SCPs to control SAML provider creation in member accounts.
+  - Enable AWS Config rules to monitor identity provider configurations.
+
+
+*Additional information*
+
+- **https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html[AWS IAM SAML Providers Documentation]**
+- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]**
+- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]**
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: "aws.cloudtrail"
+    and event.provider: "iam.amazonaws.com"
+    and event.action: "CreateSAMLProvider"
+    and event.outcome: "success"
+
+----------------------------------
+
+*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: Cloud Accounts
+** ID: T1078.004
+** Reference URL: https://attack.mitre.org/techniques/T1078/004/
+* 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: Trust Modification
+** ID: T1484.002
+** Reference URL: https://attack.mitre.org/techniques/T1484/002/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc
new file mode 100644
index 0000000000..b380872c6f
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc
@@ -0,0 +1,165 @@
+[[prebuilt-rule-8-19-16-aws-sensitive-iam-operations-performed-via-cloudshell]]
+=== AWS Sensitive IAM Operations Performed via CloudShell
+
+Identifies sensitive AWS IAM operations performed via AWS CloudShell based on the user agent string. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. While convenient for administrators, CloudShell access from compromised console sessions can enable attackers to perform privileged operations without installing tools or using programmatic credentials. This rule detects high-risk actions such as creating IAM users, access keys, roles, or attaching policies when initiated from CloudShell, which may indicate post-compromise credential harvesting or privilege escalation activity.
+
+*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/cloudshell/latest/userguide/welcome.html
+* https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud
+* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS CloudTrail
+* Data Source: AWS IAM
+* Tactic: Persistence
+* Tactic: Privilege Escalation
+* Use Case: Threat Detection
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating AWS Sensitive IAM Operations Performed via CloudShell*
+
+
+AWS CloudShell is a browser-based shell environment that provides instant command-line access to AWS resources without requiring local CLI installation or credential configuration. While this is convenient for legitimate administrators, it also provides adversaries with a powerful tool if they gain access to a compromised AWS console session. Attackers can use CloudShell to perform sensitive operations without leaving artifacts on their local systems.
+
+This rule detects high-risk IAM operations performed via CloudShell, including credential creation, user management, and policy attachment. These actions are commonly seen in post-compromise scenarios where attackers establish persistence or escalate privileges.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` to determine which IAM principal performed the action.
+  - Check `source.ip` and `source.geo` fields to verify the request origin matches expected administrator locations.
+  - Investigate the console login event that established the CloudShell session.
+
+- **Analyze the specific action**
+  - Review `event.action` to understand exactly what operation was performed.
+  - For `CreateAccessKey` or `CreateUser`, identify the target principal and assess whether this was authorized.
+  - For policy attachments, review which policies were attached and to which entities.
+
+- **Review request and response details**
+  - Examine `aws.cloudtrail.request_parameters` for specifics like user names, policy ARNs, or role configurations.
+  - Check `aws.cloudtrail.response_elements` for created resource identifiers.
+
+- **Correlate with surrounding activity**
+  - Search for preceding events such as `ConsoleLogin` from the same session or IP address.
+  - Look for MFA bypass indicators or unusual login patterns before CloudShell usage.
+  - Check for subsequent use of any created credentials or roles.
+
+- **Assess the broader context**
+  - Determine if this CloudShell usage pattern is typical for this user.
+  - Review recent access patterns for the console session that initiated CloudShell.
+
+
+*False positive analysis*
+
+
+- Routine administrative tasks using CloudShell are common in some organizations. Create baseline profiles for users who regularly use CloudShell.
+- Infrastructure automation testing may involve CloudShell for quick validation. Verify with the user.
+
+
+
+*Response and remediation*
+
+
+- If unauthorized, immediately terminate the console session and revoke any created credentials.
+- Rotate credentials for any IAM users or roles that may have been compromised.
+- Review and remove any unauthorized users, access keys, roles, or policy attachments.
+- Consider restricting CloudShell access via SCPs or IAM policies for sensitive accounts.
+- Implement session duration limits to reduce the window of opportunity for console session abuse.
+
+
+*Additional information*
+
+
+- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]**
+- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** 
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: "aws.cloudtrail"
+    and event.provider: "iam.amazonaws.com"
+    and event.action: (
+        "CreateAccessKey" or
+        "CreateUser" or
+        "AttachUserPolicy" or
+        "PutUserPolicy" or
+        "CreateRole" or
+        "AttachRolePolicy" or
+        "PutRolePolicy" or
+        "CreateInstanceProfile" or
+        "AddRoleToInstanceProfile"
+    )
+    and event.outcome: "success"
+    and user_agent.original: *CloudShell*
+
+----------------------------------
+
+*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: Cloud Account
+** ID: T1136.003
+** Reference URL: https://attack.mitre.org/techniques/T1136/003/
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Sub-technique:
+** Name: Additional Cloud Roles
+** ID: T1098.003
+** Reference URL: https://attack.mitre.org/techniques/T1098/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc
new file mode 100644
index 0000000000..6c8eca1ff0
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc
@@ -0,0 +1,145 @@
+[[prebuilt-rule-8-19-16-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.
+
+*Rule type*: new_terms
+
+*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://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud
+* https://www.cisa.gov/sites/default/files/2023-11/aa23-320a_scattered_spider_0.pdf
+* https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS SSM
+* 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 AWS SSM Inventory Reconnaissance by Rare User*
+
+
+AWS Systems Manager (SSM) Inventory provides detailed information about managed EC2 instances, including installed 
+applications, network configurations, OS details, and patch compliance status. Threat actors, including Scattered 
+Spider (LUCR-3), leverage these APIs to discover targets for lateral movement.
+
+This rule detects the first time a specific user (identified by `cloud.account.id` and `user.name`) accesses SSM 
+inventory reconnaissance APIs or runs inventory collection commands. These APIs are typically used by automation 
+systems, not interactively by humans.
+
+
+*Possible investigation steps*
+
+
+- **Verify User Identity**: Check `aws.cloudtrail.user_identity.arn` or `user.name` to determine who performed the action.
+    - Is this a service account, automation role, or human user?
+    - Does this user typically interact with SSM or EC2 infrastructure?
+- **Review Source Context**: Examine `source.ip` and `source.geo` to determine where the request originated.
+    - Does the source IP match expected locations for this user?
+    - Is the source IP from an EC2 instance (potentially compromised) or an external location?
+- **Analyze User Agent**: Check `user_agent.original` for suspicious values.
+    - AWS CLI, SDK, or CloudShell usage from unexpected users is suspicious.
+    - Custom or unusual user agents may indicate attacker tooling.
+- **Correlate with Other Events**: Look for other reconnaissance or lateral movement activity from the same user.
+    - Check for `StartSession`, `SendCommand`, or other SSM execution APIs.
+    - Look for `GetCallerIdentity` calls which often precede reconnaissance.
+- **Review Timeline**: Investigate activity 30 minutes before and after this event.
+    - Was there an initial access event (e.g., console login, `AssumeRole`)?
+    - Did the user proceed to access secrets or attempt lateral movement?
+
+
+*False positive analysis*
+
+
+- Automation and Monitoring: Legitimate monitoring tools, asset management systems, or compliance scanners may query SSM inventory regularly. These should use dedicated service accounts.
+- Administrator Activity: Cloud administrators may occasionally query inventory for troubleshooting. Verify with the user whether this was intentional.
+- CI/CD Pipelines: Deployment pipelines may check patch compliance before deployments.
+- SSM Associations: The `AWS-GatherSoftwareInventory` document is normally deployed via IaC tools (Terraform, CloudFormation) or the AWS Console during initial setup. Interactive `CreateAssociation` calls outside of these contexts warrant investigation.
+
+
+*Response and remediation*
+
+
+- Immediate Verification: Contact the user to verify whether they performed this action intentionally.
+- Review Permissions: If unauthorized, review and restrict the user's IAM permissions following least privilege.
+- Investigate Credential Compromise: If the user did not perform this action, treat their credentials as compromised.
+    - Rotate access keys and session tokens.
+    - Review recent activity for data exfiltration or privilege escalation.
+- Enhanced Monitoring: Add the user or role to enhanced monitoring if suspicious activity is confirmed.
+
+
+*Additional information*
+
+- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** 
+- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** 
+- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]**
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: "aws.cloudtrail"
+    and event.provider: "ssm.amazonaws.com"
+    and (
+        event.action: ("GetInventory" or "GetInventorySchema" or "ListInventoryEntries" or "DescribeInstancePatches" or "ListCommands")
+        or (event.action: "CreateAssociation"
+            and aws.cloudtrail.request_parameters: *AWS-GatherSoftwareInventory*)
+    )
+    and not aws.cloudtrail.user_identity.type : "AWSService" 
+    and event.outcome: "success"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Discovery
+** ID: TA0007
+** Reference URL: https://attack.mitre.org/tactics/TA0007/
+* Technique:
+** Name: Cloud Service Dashboard
+** ID: T1538
+** Reference URL: https://attack.mitre.org/techniques/T1538/
+* Technique:
+** Name: Cloud Infrastructure Discovery
+** ID: T1580
+** Reference URL: https://attack.mitre.org/techniques/T1580/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-bpf-program-or-map-load-via-bpftool.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-bpf-program-or-map-load-via-bpftool.asciidoc
new file mode 100644
index 0000000000..00d8915654
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-bpf-program-or-map-load-via-bpftool.asciidoc
@@ -0,0 +1,137 @@
+[[prebuilt-rule-8-19-16-bpf-program-or-map-load-via-bpftool]]
+=== BPF Program or Map Load via bpftool
+
+Detects execution of bpftool commands used to load, attach, run, or pin eBPF programs, as well as create or update eBPF maps and links. These operations interact directly with the Linux eBPF subsystem and can modify kernel-level behavior. While commonly used by legitimate networking or observability tooling, unexpected or interactive usage may indicate eBPF-based rootkit activity, policy tampering, or unauthorized kernel instrumentation.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* auditbeat-*
+* endgame-*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+* logs-sentinel_one_cloud_funnel.*
+* logs-crowdstrike.fdr*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://manpages.ubuntu.com/manpages/jammy/man8/bpftool-prog.8.html
+* https://manpages.ubuntu.com/manpages/noble/man8/bpftool-map.8.html
+* https://man.archlinux.org/man/bpftool-link.8.en
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Defense Evasion
+* Threat: Rootkit
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Auditd Manager
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 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 BPF Program or Map Load via bpftool*
+
+
+This rule flags bpftool executions that load, attach, run, or pin eBPF programs and that create or pin maps/links, actions that can change kernel behavior without traditional user-space artifacts. Adversaries can use bpftool to load a malicious eBPF object, attach it to a tracepoint or traffic control hook, and pin the program and maps in bpffs so it persists and hides or filters activity across reboots.
+
+
+*Possible investigation steps*
+
+
+- Capture full command line, parent process, user context, TTY/session, and current working directory to determine whether execution was interactive administration or automated tooling.  
+- Enumerate loaded and pinned eBPF artifacts and their attachment points using `bpftool prog show`, `bpftool map show`, `bpftool link show`, and a filesystem review of `/sys/fs/bpf` to identify unexpected persistence.  
+- Identify the eBPF object/source used for the load (path, inode, hash, package origin) and retrieve a copy for analysis, including checking for recent writes or downloads in the same directory tree.  
+- Correlate the event time with system logs and other telemetry for follow-on activity such as privilege escalation, module loads, network filtering changes, or suspicious process hiding indicators.  
+- Hunt for persistence mechanisms that would reload the same eBPF program after reboot (systemd units/timers, cron, init scripts, container entrypoints) and validate against known legitimate observability/network stacks in the environment.
+
+
+*False positive analysis*
+
+
+- A system administrator or SRE may run `bpftool prog load/attach/pin` or `bpftool map create/pin` during planned troubleshooting or performance investigation to temporarily instrument kernel events and persist objects under `/sys/fs/bpf` for multi-step validation.  
+- A legitimate system service or boot-time automation may invoke `bpftool` to load and pin eBPF programs/maps as part of expected networking, security policy enforcement, or observability initialization, especially after upgrades or configuration changes that trigger reloading.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the host or container from the network and stop the initiating service/session, then detach any active hooks by removing pinned artifacts under `/sys/fs/bpf` and verifying with `bpftool prog show` and `bpftool link show` that the suspicious program/link is no longer attached.  
+- Preserve evidence by collecting the full `bpftool` command line and parent chain, a recursive copy of `/sys/fs/bpf`, and the exact eBPF object file used for the load (path, hash, permissions, timestamps) before deleting or modifying artifacts.  
+- Eradicate persistence by removing malicious eBPF pins, deleting or quarantining the associated `.o`/loader binaries, and disabling the boot-time mechanism that reloads them (systemd unit/timer, cron, init scripts, container entrypoint) followed by a controlled reboot to clear any remaining in-kernel state.  
+- Recover by restoring the system to a known-good configuration, validating expected networking/observability behavior, and monitoring that no new pinned programs/maps/links reappear under `/sys/fs/bpf` after reboot or service restarts.  
+- Escalate to incident response and kernel/rootkit specialists if the program attaches to security-relevant hooks (e.g., tracepoints/kprobes/LSM/tc) or if pinned objects reappear after removal, indicating an active persistence mechanism or compromised privileged runtime.  
+- Harden by restricting `bpftool` availability and access to bpffs, enforcing least-privilege for CAP_BPF/CAP_SYS_ADMIN, requiring signed/managed eBPF loaders, and enabling controls that limit eBPF usage to approved components in production images and hosts.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and
+event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+process.name == "bpftool" and (
+  (process.args == "prog" and process.args in ("load", "loadall", "attach", "run", "pin")) or
+  (process.args == "map" and process.args in ("create", "pin")) or
+  (process.args == "link" and process.args == "pin")
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Boot or Logon Autostart Execution
+** ID: T1547
+** Reference URL: https://attack.mitre.org/techniques/T1547/
+* Sub-technique:
+** Name: Kernel Modules and Extensions
+** ID: T1547.006
+** Reference URL: https://attack.mitre.org/techniques/T1547/006/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Rootkit
+** ID: T1014
+** Reference URL: https://attack.mitre.org/techniques/T1014/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-bpf-program-tampering-via-bpftool.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-bpf-program-tampering-via-bpftool.asciidoc
new file mode 100644
index 0000000000..4ff786f457
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-bpf-program-tampering-via-bpftool.asciidoc
@@ -0,0 +1,131 @@
+[[prebuilt-rule-8-19-16-bpf-program-tampering-via-bpftool]]
+=== BPF Program Tampering via bpftool
+
+Detects execution of bpftool commands used to detach eBPF programs or links, or to delete or modify eBPF maps. These actions can disable, alter, or interfere with kernel-level instrumentation and enforcement mechanisms implemented through eBPF. In environments relying on eBPF-based networking, observability, or security controls, unexpected use of these operations may indicate defense evasion or runtime tampering.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* auditbeat-*
+* endgame-*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+* logs-sentinel_one_cloud_funnel.*
+* logs-crowdstrike.fdr*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://manpages.ubuntu.com/manpages/jammy/man8/bpftool-prog.8.html
+* https://manpages.ubuntu.com/manpages/noble/man8/bpftool-map.8.html
+* https://man.archlinux.org/man/bpftool-link.8.en
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Threat: Rootkit
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Auditd Manager
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*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 BPF Program Tampering via bpftool*
+
+
+This rule detects bpftool executions that detach eBPF programs/links or delete/update eBPF maps, actions that can silently disable kernel-level visibility and enforcement built on eBPF. Attackers use these operations to evade detection or weaken runtime controls by removing loaded probes or rewriting map contents that drive policy decisions. A common pattern is running bpftool to detach a program from a hook or detach a link shortly before other suspicious activity.
+
+
+*Possible investigation steps*
+
+
+- Pull the full bpftool command line and correlate it with the invoking user, session (TTY/SSH), parent process chain, and any preceding privilege escalation to determine whether it was interactive admin work or automated tampering.  
+- Capture current eBPF state (`bpftool prog show`, `bpftool link show`, `bpftool map show -j`) and compare with recent snapshots/logs to identify which program/link/map changed and what controls (sensor, CNI, LSM, XDP/TC) may have been impacted.  
+- Identify the affected attachment point by mapping the detached program/link ID to its hook (e.g., tc/xdp/cgroup/tracepoint/kprobe) and validate operational impact by checking for missing telemetry, policy gaps, or network behavior changes around the event time.  
+- Review audit/system logs and package history for installation or recent execution of bpftool, kernel/debug tooling, or custom eBPF loaders, and look for nearby suspicious binaries/scripts that could be orchestrating repeated detach/update actions.  
+- If malicious activity is suspected, preserve artifacts by exporting bpftool JSON output and relevant `/sys/fs/bpf` entries, then hunt for follow-on persistence or rootkit-like behavior (new eBPF loads, altered maps, hidden processes, unexpected kernel module activity) on the host.
+
+
+*False positive analysis*
+
+
+- A system administrator or SRE running bpftool during incident response or troubleshooting may detach a program/link or update/delete a map to temporarily disable an eBPF hook and validate whether it is causing network drops, performance regressions, or incorrect enforcement.
+- A maintenance workflow during kernel, CNI, or eBPF policy rollouts may use bpftool to detach and replace existing attachments or refresh map entries as part of a controlled upgrade/rollback, especially when reloading pinned objects under `/sys/fs/bpf`.
+
+
+*Response and remediation*
+
+
+- Contain by isolating the host from the network or restricting outbound access while preserving access for forensics if bpftool detach/map operations are unexpected or coincide with loss of eBPF-based enforcement/telemetry.  
+- Eradicate by stopping and removing the controlling process/script (inspect the bpftool parent chain and cron/systemd units), revoking the initiating account’s sudo/root access, and deleting any unauthorized pinned objects under `/sys/fs/bpf` after exporting them for evidence.  
+- Recover by reloading the approved eBPF components (agent/CNI/LSM/XDP/TC) from trusted packages or images, reattaching required programs/links, and restoring known-good map contents from backups or redeploying policy to repopulate maps.  
+- Escalate to incident response and platform owners immediately if repeated bpftool tampering persists after containment, you find unknown pinned maps/programs with suspicious names/owners, or multiple hosts show simultaneous detach/update activity.  
+- Harden by limiting bpftool availability (remove from production images where not needed), enforcing least-privilege on CAP_BPF/CAP_SYS_ADMIN and sudoers, and adding immutable monitoring of `/usr/sbin/bpftool` and `/sys/fs/bpf` plus periodic snapshots of `bpftool prog/link/map show` for drift detection.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and
+event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+process.name == "bpftool" and (
+  (process.args == "prog" and process.args == "detach") or
+  (process.args == "map" and process.args in ("delete", "update")) or
+  (process.args == "link" and process.args == "detach")
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
+* Sub-technique:
+** Name: Disable or Modify Tools
+** ID: T1562.001
+** Reference URL: https://attack.mitre.org/techniques/T1562/001/
+* Technique:
+** Name: Rootkit
+** ID: T1014
+** Reference URL: https://attack.mitre.org/techniques/T1014/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-clearing-windows-console-history.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-clearing-windows-console-history.asciidoc
new file mode 100644
index 0000000000..1d46fcbd4d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-clearing-windows-console-history.asciidoc
@@ -0,0 +1,152 @@
+[[prebuilt-rule-8-19-16-clearing-windows-console-history]]
+=== Clearing Windows Console History
+
+Identifies when a user attempts to clear console history. An adversary may clear the command history of a compromised account to conceal the actions undertaken during an intrusion.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* endgame-*
+* logs-crowdstrike.fdr*
+* logs-endpoint.events.process-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-system.security*
+* logs-windows.forwarded*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://stefanos.cloud/kb/how-to-clear-the-powershell-command-history/
+* https://www.shellhacks.com/clear-history-powershell/
+* https://community.sophos.com/sophos-labs/b/blog/posts/powershell-command-history-forensics
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Tactic: Execution
+* Resources: Investigation Guide
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Windows Security Event Logs
+* Data Source: Microsoft Defender for Endpoint
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+
+*Version*: 318
+
+*Rule authors*: 
+
+* Austin Songer
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Clearing Windows Console History*
+
+
+PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code.
+
+Attackers can try to cover their tracks by clearing PowerShell console history. PowerShell has two different ways of logging commands: the built-in history and the command history managed by the PSReadLine module. This rule looks for the execution of commands that can clear the built-in PowerShell logs or delete the `ConsoleHost_history.txt` file.
+
+
+*Possible investigation steps*
+
+
+- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Contact the account owner and confirm whether they are aware of this activity.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+  - Verify if any other anti-forensics behaviors were observed.
+- Investigate the PowerShell logs on the SIEM to determine if there was suspicious behavior that an attacker may be trying to cover up.
+
+
+*False positive analysis*
+
+
+- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+
+
+*Response and remediation*
+
+
+- Initiate the incident response process based on the outcome of the triage.
+- Isolate the involved host to prevent further post-compromise behavior.
+- 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).
+  - Ensure that PowerShell auditing policies and log collection are in place to grant future visibility.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+  (
+    process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") or
+    ?process.pe.original_file_name in ("PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE")
+  ) and
+  (
+    process.command_line : "*Clear-History*" or
+    (
+      process.command_line : ("*Remove-Item*", "* rm *") and
+      process.command_line : ("*ConsoleHost_history.txt*", "*(Get-PSReadlineOption).HistorySavePath*")
+    ) or
+    (process.command_line : "*Set-PSReadlineOption*" and process.command_line : "*SaveNothing*")
+  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Indicator Removal
+** ID: T1070
+** Reference URL: https://attack.mitre.org/techniques/T1070/
+* Sub-technique:
+** Name: Clear Command History
+** ID: T1070.003
+** Reference URL: https://attack.mitre.org/techniques/T1070/003/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-command-and-scripting-interpreter-via-windows-scripts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-command-and-scripting-interpreter-via-windows-scripts.asciidoc
new file mode 100644
index 0000000000..226258e92a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-command-and-scripting-interpreter-via-windows-scripts.asciidoc
@@ -0,0 +1,156 @@
+[[prebuilt-rule-8-19-16-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.
+
+*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 for Endpoint
+* Data Source: Elastic Endgame
+* Data Source: Crowdstrike
+
+*Version*: 208
+
+*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 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.
+
+
+*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.
+
+
+*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.
+
+==== 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 event.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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-connection-to-common-large-language-model-endpoints.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-connection-to-common-large-language-model-endpoints.asciidoc
new file mode 100644
index 0000000000..7a08c7149d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-connection-to-common-large-language-model-endpoints.asciidoc
@@ -0,0 +1,186 @@
+[[prebuilt-rule-8-19-16-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.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* endgame-*
+* logs-endpoint.events.network-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://malpedia.caad.fkie.fraunhofer.de/details/py.lamehug
+
+*Tags*: 
+
+* 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
+
+*Version*: 3
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Connection to Common Large Language Model Endpoints*
+
+
+
+*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.
+
+
+*False positive analysis*
+
+
+- Trusted applications from an expected process running in the environment.
+
+
+*Response and remediation*
+
+
+- Initiate the incident response process based on the outcome of the triage.
+- Isolate the involved host to prevent further post-compromise behavior.
+- 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).
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+network where host.os.type in ("macos", "windows") and dns.question.name != null and
+(
+  process.name : ("MSBuild.exe", "mshta.exe", "wscript.exe", "powershell.exe", "pwsh.exe", "msiexec.exe", "rundll32.exe",
+  "bitsadmin.exe", "InstallUtil.exe", "RegAsm.exe", "vbc.exe", "RegSvcs.exe", "regsvr32.exe", "dllhost.exe",
+  "node.exe", "javaw.exe", "java.exe", "*.pif", "*.com", "python*", "osascript", "Script Editor", "curl", "curl.exe", "deno", 
+  "deno.exe", "node", "bun", "bun.exe") or
+
+  ?process.code_signature.subject_name : ("AutoIt Consulting Ltd", "OpenJS Foundation", "Python Software Foundation") or
+
+  (
+    process.executable : ("?:\\Users\\*.exe", "?:\\ProgramData\\*.exe", "/Users/Shared/*", "/Library/WebServer/*", 
+                          "/Users/*/Library/WebServer/*", "/Library/Graphics/*", "/Users/*/Library/Graphics/*", "/Library/Fonts/*", 
+                          "/Users/*/Library/Fonts/*", "/private/var/root/Library/HTTPStorages/*", "/tmp/*", "/var/tmp/*", "/private/tmp/*") and
+    (?process.code_signature.trusted == false or ?process.code_signature.exists == false)
+  )
+ ) and
+    dns.question.name : (
+    // Major LLM APIs
+    "api.openai.com",
+    "*.openai.azure.com",
+    "api.anthropic.com",
+    "api.mistral.ai",
+    "api.cohere.ai",
+    "api.ai21.com",
+    "api.groq.com",
+    "api.perplexity.ai",
+    "api.x.ai",
+    "api.deepseek.com",
+    "api.gemini.google.com",
+    "generativelanguage.googleapis.com",
+    "api.azure.com",
+    "api.bedrock.aws",
+    "bedrock-runtime.amazonaws.com",
+
+    // Hugging Face & other ML infra
+    "api-inference.huggingface.co",
+    "inference-endpoint.huggingface.cloud",
+    "*.hf.space",
+    "*.replicate.com",
+    "api.replicate.com",
+    "api.runpod.ai",
+    "*.runpod.io",
+    "api.modal.com",
+    "*.forefront.ai",
+
+    // Consumer-facing AI chat portals
+    "chat.openai.com",
+    "chatgpt.com",
+    "copilot.microsoft.com",
+    "bard.google.com",
+    "gemini.google.com",
+    "claude.ai",
+    "perplexity.ai",
+    "poe.com",
+    "chat.forefront.ai",
+    "chat.deepseek.com",
+
+    // OpenClaw
+    "openclaw.ai"
+  ) and
+
+  not process.executable : (
+          "?:\\Program Files\\*.exe",
+          "?:\\Program Files (x86)\\*.exe",
+          "?:\\Windows\\System32\\svchost.exe",
+          "?:\\Windows\\SystemApps\\Microsoft.LockApp_*\\LockApp.exe",
+          "?:\\Users\\*\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe",
+          "?:\\Users\\*\\AppData\\Local\\BraveSoftware\\*\\Application\\brave.exe",
+          "?:\\Users\\*\\AppData\\Local\\Vivaldi\\Application\\vivaldi.exe",
+          "?:\\Users\\*\\AppData\\Local\\Programs\\Opera*\\opera.exe",
+          "?:\\Users\\*\\AppData\\Local\\Programs\\Fiddler\\Fiddler.exe"
+        ) and
+    not (?process.code_signature.trusted == true and
+         ?process.code_signature.subject_name : ("Anthropic, PBC", "Google LLC", "Mozilla Corporation", "Brave Software, Inc.", "Island Technology Inc.", "Opera Norway AS"))
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Command and Control
+** ID: TA0011
+** Reference URL: https://attack.mitre.org/tactics/TA0011/
+* Technique:
+** Name: Web Service
+** ID: T1102
+** Reference URL: https://attack.mitre.org/techniques/T1102/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-correlated-alerts-on-similar-user-identities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-correlated-alerts-on-similar-user-identities.asciidoc
new file mode 100644
index 0000000000..17fd3753a7
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-correlated-alerts-on-similar-user-identities.asciidoc
@@ -0,0 +1,162 @@
+[[prebuilt-rule-8-19-16-correlated-alerts-on-similar-user-identities]]
+=== Correlated Alerts on Similar User Identities
+
+This rule correlates alerts from multiple integrations and event categories that involve different user.name values which may represent the same real-world identity. It uses an LLM-based similarity analysis to evaluate whether multiple user identifiers (e.g. naming variations, formats, aliases, or domain differences) likely belong to the same person.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 30m
+
+*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.elastic.co/docs/reference/query-languages/esql/esql-commands#esql-completion
+* https://www.elastic.co/security-labs/elastic-advances-llm-security
+
+*Tags*: 
+
+* Domain: Identity
+* Domain: LLM
+* Use Case: Threat Detection
+* Use Case: Identity and Access Audit
+* Resources: Investigation Guide
+* Rule Type: Higher-Order Rule
+
+*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, analysts should validate findings against their environment and identity architecture.
+
+
+*Investigating Correlated Alerts on Similar User Identities*
+
+
+This rule identifies alerts from multiple integrations and event categories involving different `user.name` values that may represent the same real-world identity.
+An LLM is used to assess string similarity and naming patterns to determine whether multiple user identifiers likely belong to the same person, which may indicate account compromise, credential abuse, or identity misuse across systems.
+
+
+*Possible investigation steps*
+
+
+- Review the correlated `user.name` values and validate whether they represent naming variations, aliases, or identity mappings.
+- Examine the LLM output fields (`verdict`, `confidence`, `summary`) as decision support, not ground truth.
+- Analyze the diversity of alert sources, event categories, and detection rules involved.
+- Reconstruct the alert timeline to identify potential stages such as initial access, lateral movement, privilege escalation, or persistence.
+- Correlate with authentication logs, IAM/SSO telemetry, EDR data, and network logs to identify shared sessions, IPs, devices, or hosts.
+- Validate identities against directory services, identity providers, and federation mappings.
+
+
+*False positive analysis*
+
+
+- Identity format variations across systems (e.g., `first.last`, `flast`, `user@domain`).
+- Federated identity mappings between on-prem, cloud, and SaaS platforms.
+- Service, automation, and CI/CD accounts with similar naming conventions.
+- Separate admin and standard user accounts for the same individual.
+- Shared credentials or naming templates in development and test environments.
+
+
+*Response and remediation*
+
+
+- Temporarily disable or suspend correlated accounts if compromise is suspected.
+- Revoke active sessions, tokens, and credentials.
+- Investigate access scope, privileges, and lateral movement paths.
+- Perform endpoint and identity forensics to identify persistence mechanisms.
+- Remediate IAM misconfigurations and federation issues.
+- Enhance monitoring for identity correlation, credential misuse, and cross-platform abuse..
+
+==== Setup
+
+
+
+*Setup*
+
+
+
+*LLM Configuration*
+
+
+This rule uses the ES|QL COMPLETION command with Elastic's managed General Purpose LLM v2 (`.gp-llm-v2-completion`),
+which is available out-of-the-box in Elastic Cloud deployments with an appropriate subscription.
+
+To use a different LLM provider (Azure OpenAI, Amazon Bedrock, OpenAI, or Google Vertex), configure a connector
+following the https://www.elastic.co/docs/explore-analyze/ai-features/llm-guides/llm-connectors[LLM connector documentation]
+and update the `inference_id` parameter in the query to reference your configured connector.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from .alerts-security.*
+
+// truncate timestamp to 5-minute window
+| eval Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp)
+
+// high severity alerts excluding system standard user.ids
+| where kibana.alert.rule.name is not null and user.name is not null and kibana.alert.risk_score >= 73 and kibana.alert.workflow_status == "open" and 
+        not kibana.alert.rule.type in ("threat_match", "machine_learning") and
+        not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0")
+
+// group alerts by short time window and extract values of interest for alert triage
+| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
+        Esql.user_name_distinct_count = COUNT_DISTINCT(user.name),
+        Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
+        Esql.event_category_distinct_count = COUNT_DISTINCT(event.category),
+        Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),
+        Esql.event_module_values = VALUES(event.module),
+        Esql.rule_name_values = VALUES(kibana.alert.rule.name),
+        Esql.message_values = VALUES(message),
+        Esql.event_category_values = VALUES(event.category),
+        Esql.event_action_values = VALUES(event.action),
+        Esql.source_ip_values = VALUES(source.ip),
+        Esql.destination_ip_values = VALUES(destination.ip),
+        Esql.host_id_values = VALUES(host.id),
+        Esql.agent_id_values = VALUES(agent.id),
+        Esql.rule_severity_values = VALUES(kibana.alert.risk_score),
+        Esql.user_name_values = VALUES(user.name) by Esql.time_window_date_trunc
+
+// filter for alerts from different integrations with unique categories
+| where Esql.event_module_distinct_count >= 2 and Esql.user_name_distinct_count >= 2 and Esql.event_category_distinct_count >= 2
+
+// build context for LLM analysis
+| eval users_list = MV_CONCAT(Esql.user_name_values, ",")
+
+// LLM analysis
+| eval instructions = "Analyze the provided user names and return a boolean value true if at least 2 of them are similar and they may belong to the same human identify or false if not, do not compare user names that may look like service accounts. If the list of users has more than 2 users and only 2 of them are similar consider this as true. Structure the output as follows: verdict=<verdict> confidence=<score> summary=<short reason max 500 words> without any other response statements on a single line."
+| eval prompt = CONCAT("User identities extracted from different alerts: ", users_list, instructions)
+| COMPLETION triage_result = prompt WITH { "inference_id": ".gp-llm-v2-completion"}
+
+// parse LLM response
+| DISSECT triage_result """verdict=%{Esql.verdict} confidence=%{Esql.confidence} summary=%{Esql.summary}"""
+
+// filter for similar user values
+| where TO_LOWER(Esql.verdict) == "true"
+| keep Esql.*
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc
new file mode 100644
index 0000000000..0f954ec616
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc
@@ -0,0 +1,110 @@
+[[prebuilt-rule-8-19-16-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.
+
+*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*: 3
+
+*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*
+
+- 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.
+
+
+*False positive analysis*
+
+
+- Migration of legacy service accounts using delegated managed service account.
+
+
+*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.
+
+==== 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-16/prebuilt-rule-8-19-16-deprecated-adobe-hijack-persistence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-adobe-hijack-persistence.asciidoc
new file mode 100644
index 0000000000..afbe6290ca
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-adobe-hijack-persistence.asciidoc
@@ -0,0 +1,153 @@
+[[prebuilt-rule-8-19-16-deprecated-adobe-hijack-persistence]]
+=== Deprecated - Adobe Hijack Persistence
+
+Detects writing executable files that will be automatically launched by Adobe on launch.
+
+*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*: 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://twitter.com/pabraeken/status/997997818362155008
+
+*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: SentinelOne
+* Data Source: Microsoft Defender for Endpoint
+* Data Source: Crowdstrike
+
+*Version*: 419
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Deprecated - Adobe Hijack Persistence*
+
+
+Attackers can replace the `RdrCEF.exe` executable with their own to maintain their access, which will be launched whenever Adobe Acrobat Reader is executed.
+
+> **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.
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
+- 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.
+
+
+*False positive analysis*
+
+
+- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+
+
+*Response and remediation*
+
+
+- Initiate the incident response process based on the outcome of the triage.
+- Isolate the involved host to prevent further post-compromise behavior.
+- If the triage identified malware, search the environment for additional compromised hosts.
+  - Implement temporary network rules, procedures, and segmentation to contain the malware.
+  - Stop suspicious processes.
+  - Immediately block the identified indicators of compromise (IoCs).
+  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
+- Remove and block malicious artifacts identified during triage.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
+- 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).
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+file where host.os.type == "windows" and event.type == "creation" and
+  file.path : (
+    "?:\\Program Files (x86)\\Adobe\\Acrobat Reader DC\\Reader\\AcroCEF\\RdrCEF.exe",
+    "?:\\Program Files\\Adobe\\Acrobat Reader DC\\Reader\\AcroCEF\\RdrCEF.exe",
+
+    /* Crowdstrike specific condition as it uses NT Object paths */
+    "\\Device\\HarddiskVolume*\\Program Files (x86)\\Adobe\\Acrobat Reader DC\\Reader\\AcroCEF\\RdrCEF.exe",
+    "\\Device\\HarddiskVolume*\\Program Files\\Adobe\\Acrobat Reader DC\\Reader\\AcroCEF\\RdrCEF.exe"
+  ) and
+  not process.name : ("msiexec.exe", "AdobeARM.exe")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Compromise Host Software Binary
+** ID: T1554
+** Reference URL: https://attack.mitre.org/techniques/T1554/
+* 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-encoded-executable-stored-in-the-registry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-encoded-executable-stored-in-the-registry.asciidoc
new file mode 100644
index 0000000000..de0e06d956
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-encoded-executable-stored-in-the-registry.asciidoc
@@ -0,0 +1,125 @@
+[[prebuilt-rule-8-19-16-deprecated-encoded-executable-stored-in-the-registry]]
+=== Deprecated - Encoded Executable Stored in the Registry
+
+Identifies registry write modifications to hide an encoded portable executable. This could be indicative of adversary defense evasion by avoiding the storing of malicious content directly on disk.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.registry-*
+* endgame-*
+* logs-windows.sysmon_operational-*
+* logs-sentinel_one_cloud_funnel.*
+* winlogbeat-*
+* logs-m365_defender.event-*
+* logs-crowdstrike.fdr*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* 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 for Endpoint
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 416
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Deprecated - Encoded Executable Stored in the Registry*
+
+
+Windows Registry is a hierarchical database storing low-level settings for the OS and applications. Adversaries exploit it to hide encoded executables, evading detection by avoiding direct disk storage. The detection rule identifies suspicious registry modifications, specifically targeting encoded patterns indicative of hidden executables, thus flagging potential defense evasion tactics.
+
+
+*Possible investigation steps*
+
+
+- Review the registry path and key where the modification was detected to understand the context and potential impact on the system.
+- Analyze the encoded data string "TVqQAAMAAAAEAAAA*" to determine if it corresponds to a known malicious executable or pattern.
+- Check the modification timestamp to correlate with any other suspicious activities or events on the system around the same time.
+- Investigate the process or user account responsible for the registry modification to assess if it is associated with legitimate activity or known threats.
+- Cross-reference the alert with other data sources such as Sysmon, Microsoft Defender for Endpoint, or SentinelOne for additional context or corroborating evidence of malicious behavior.
+- Evaluate the system's network activity and connections during the time of the registry modification to identify any potential command and control communications or data exfiltration attempts.
+
+
+*False positive analysis*
+
+
+- Legitimate software installations or updates may write encoded executables to the registry as part of their normal operation. Users can create exceptions for known software by identifying their specific registry paths and excluding them from the detection rule.
+- Security tools and system management software might store encoded data in the registry for legitimate purposes. Review the registry paths and data associated with these tools and exclude them if they are verified as non-threatening.
+- Custom scripts or enterprise applications developed in-house may use encoded executables in the registry for deployment or configuration purposes. Work with development teams to identify these scripts and add exceptions for their registry modifications.
+- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking potential threats.
+
+
+*Response and remediation*
+
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the encoded executable.
+- Remove the malicious registry entry by using a trusted registry editor or automated script to ensure the encoded executable is no longer stored in the registry.
+- Conduct a full system scan using updated antivirus and anti-malware tools to identify and remove any additional threats or remnants of the attack.
+- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through cleaning.
+- Monitor the system and network for any signs of re-infection or similar registry modifications, adjusting detection rules if necessary to enhance future threat identification.
+- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further analysis and to determine if additional systems are affected.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+registry where host.os.type == "windows" and
+/* update here with encoding combinations */
+ registry.data.strings : "TVqQAAMAAAAEAAAA*"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* 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: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-exchange-dlp-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-exchange-dlp-policy-deleted.asciidoc
new file mode 100644
index 0000000000..17c31b7069
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-exchange-dlp-policy-deleted.asciidoc
@@ -0,0 +1,113 @@
+[[prebuilt-rule-8-19-16-deprecated-m365-exchange-dlp-policy-deleted]]
+=== Deprecated - M365 Exchange DLP Policy Deleted
+
+Identifies when a Data Loss Prevention (DLP) policy is removed in Microsoft 365. An adversary may remove a DLP policy to evade existing DLP monitoring.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+* filebeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/powershell/module/exchange/remove-dlppolicy?view=exchange-ps
+* https://docs.microsoft.com/en-us/microsoft-365/compliance/data-loss-prevention-policies?view=o365-worldwide
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: Microsoft 365
+* Use Case: Configuration Audit
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+
+*Version*: 212
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Deprecated - M365 Exchange DLP Policy Deleted*
+
+
+Data Loss Prevention (DLP) in Microsoft 365 Exchange is crucial for safeguarding sensitive information by monitoring and controlling data transfers. Adversaries may exploit this by removing DLP policies to bypass data monitoring, facilitating unauthorized data exfiltration. The detection rule identifies such actions by analyzing audit logs for specific events indicating successful DLP policy removal, thus alerting security teams to potential defense evasion tactics.
+
+
+*Possible investigation steps*
+
+
+- Review the audit logs for the specific event.action "Remove-DlpPolicy" to identify the user account responsible for the action.
+- Check the event.outcome field to confirm the success of the DLP policy removal and gather additional context from related logs.
+- Investigate the user account's recent activities in Microsoft 365 to identify any other suspicious actions or anomalies.
+- Verify if the removed DLP policy was critical for protecting sensitive data and assess the potential impact of its removal.
+- Contact the user or their manager to confirm if the DLP policy removal was authorized and legitimate.
+- Examine any recent changes in permissions or roles for the user account to determine if they had the necessary privileges to remove the DLP policy.
+
+
+*False positive analysis*
+
+
+- Routine administrative changes to DLP policies by authorized personnel can trigger alerts. To manage this, maintain a list of authorized users and correlate their activities with policy changes to verify legitimacy.
+- Scheduled updates or maintenance activities might involve temporary removal of DLP policies. Document these activities and create exceptions in the monitoring system for the duration of the maintenance window.
+- Automated scripts or third-party tools used for policy management can inadvertently trigger false positives. Ensure these tools are properly documented and their actions are logged to differentiate between legitimate and suspicious activities.
+- Changes in organizational policy or compliance requirements may necessitate the removal of certain DLP policies. Keep a record of such changes and adjust the monitoring rules to accommodate these legitimate actions.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected Microsoft 365 account to prevent further unauthorized actions and data exfiltration.
+- Review the audit logs to identify any additional unauthorized changes or suspicious activities associated with the account or related accounts.
+- Restore the removed DLP policy from a backup or recreate it based on the organization's standard configuration to re-enable data monitoring.
+- Conduct a thorough investigation to determine the scope of data exposure and identify any data that may have been exfiltrated during the period the DLP policy was inactive.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional containment measures are necessary.
+- Implement enhanced monitoring and alerting for similar events, focusing on unauthorized changes to security policies and configurations.
+- Review and strengthen access controls and permissions for accounts with the ability to modify DLP policies to prevent unauthorized changes in the future.
+
+==== Setup
+
+
+The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Remove-DlpPolicy" and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish.asciidoc
new file mode 100644
index 0000000000..190efd0532
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish.asciidoc
@@ -0,0 +1,123 @@
+[[prebuilt-rule-8-19-16-deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish]]
+=== Deprecated - M365 Security Compliance Email Reported by User as Malware or Phish
+
+Detects the occurrence of emails reported as Phishing or Malware by Users. Security Awareness training is essential to stay ahead of scammers and threat actors, as security products can be bypassed, and the user can still receive a malicious message. Educating users to report suspicious messages can help identify gaps in security controls and prevent malware infections and Business Email Compromise attacks.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+* filebeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://support.microsoft.com/en-us/office/use-the-report-message-add-in-b5caa9f1-cdf3-4443-af8c-ff724ea719d2?ui=en-us&rs=en-us&ad=us
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: Microsoft 365
+* Tactic: Initial Access
+* 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 Deprecated - M365 Security Compliance Email Reported by User as Malware or Phish*
+
+
+Microsoft 365's email services are integral to business communication, but they can be exploited by adversaries through phishing or malware-laden emails. Attackers may bypass security measures, reaching users who might unwittingly engage with malicious content. The detection rule leverages user reports of suspicious emails, correlating them with security events to identify potential threats, thus enhancing the organization's ability to respond to phishing attempts and malware distribution.
+
+
+*Possible investigation steps*
+
+
+- Review the details of the alert triggered by the rule "Email reported by user as malware or phish" in the SecurityComplianceCenter to understand the context and specifics of the reported email.
+- Examine the event dataset from o365.audit to gather additional information about the email, such as sender, recipient, subject line, and any attachments or links included.
+- Correlate the reported email with other security events or alerts to identify any patterns or related incidents that might indicate a broader phishing campaign or malware distribution attempt.
+- Check the user's report against known phishing or malware indicators, such as suspicious domains or IP addresses, using threat intelligence sources to assess the credibility of the threat.
+- Investigate the user's activity following the receipt of the email to determine if any actions were taken that could have compromised the system, such as clicking on links or downloading attachments.
+- Assess the effectiveness of current security controls and awareness training by analyzing how the email bypassed existing defenses and was reported by the user.
+
+
+*False positive analysis*
+
+
+- User-reported emails from trusted internal senders can trigger false positives. Encourage users to verify the sender's identity before reporting and consider adding these senders to an allowlist if they are consistently flagged.
+- Automated system notifications or newsletters may be mistakenly reported as phishing. Educate users on recognizing legitimate automated communications and exclude these sources from triggering alerts.
+- Emails containing marketing or promotional content from known vendors might be reported as suspicious. Train users to differentiate between legitimate marketing emails and phishing attempts, and create exceptions for verified vendors.
+- Frequent reports of emails from specific domains that are known to be safe can lead to unnecessary alerts. Implement domain-based exceptions for these trusted domains to reduce false positives.
+- Encourage users to provide detailed reasons for reporting an email as suspicious, which can help in refining detection rules and reducing false positives over time.
+
+
+*Response and remediation*
+
+
+- Isolate the affected email account to prevent further interaction with potentially malicious content and to stop any ongoing unauthorized access.
+- Quarantine the reported email and any similar emails identified in the system to prevent other users from accessing them.
+- Conduct a thorough scan of the affected user's device and network for any signs of malware or unauthorized access, using endpoint detection and response tools.
+- Reset the credentials of the affected user account and any other accounts that may have been compromised to prevent further unauthorized access.
+- Notify the security team and relevant stakeholders about the incident, providing details of the threat and actions taken, to ensure coordinated response efforts.
+- Review and update email filtering and security policies to address any identified gaps that allowed the malicious email to bypass existing controls.
+- Monitor for any further suspicious activity related to the incident, using enhanced logging and alerting mechanisms to detect similar threats in the future.
+
+==== Setup
+
+
+The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:o365.audit and event.provider:SecurityComplianceCenter and event.action:AlertTriggered and rule.name:"Email reported by user as malware or phish"
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc
new file mode 100644
index 0000000000..f6fdee2b8d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc
@@ -0,0 +1,117 @@
+[[prebuilt-rule-8-19-16-deprecated-m365-security-compliance-potential-ransomware-activity]]
+=== Deprecated - M365 Security Compliance Potential Ransomware Activity
+
+Identifies when Microsoft Cloud App Security flags potential ransomware activity in Microsoft 365. This rule detects events where the Security Compliance Center reports a "Ransomware activity" or "Potential ransomware activity" alert, which may indicate file encryption, mass file modifications, or uploads of ransomware-infected files to cloud services such as SharePoint or OneDrive.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+* filebeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy
+* https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference
+* https://www.microsoft.com/en-us/security/blog/threat-intelligence/ransomware/
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: SaaS
+* Data Source: Microsoft 365
+* Data Source: Microsoft 365 Audit Logs
+* Use Case: Threat Detection
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 213
+
+*Rule authors*: 
+
+* Elastic
+* Austin Songer
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Deprecated - M365 Security Compliance Potential Ransomware Activity*
+
+
+Microsoft 365's cloud services can be exploited by adversaries to distribute ransomware by uploading infected files. This detection rule leverages Microsoft Cloud App Security to identify suspicious uploads, focusing on successful events flagged as potential ransomware activity. By monitoring specific event datasets and actions, it helps security analysts pinpoint and mitigate ransomware threats, aligning with MITRE ATT&CK's impact tactics.
+
+
+*Possible investigation steps*
+
+
+- Identify the affected user account and review their recent file activity in Microsoft 365 for signs of mass file encryption, renaming with unusual extensions, or rapid file modifications.
+- Examine the file names, extensions, and metadata of the flagged uploads to determine if they match known ransomware patterns (e.g., `.encrypted`, `.locked`, or ransom note files like `README.txt` or `DECRYPT_INSTRUCTIONS.html`).
+- Correlate this alert with other security events from the same user or source IP, such as impossible travel, failed login attempts, or suspicious inbox rules, to identify potential account compromise.
+- Check whether the affected user's endpoint shows signs of ransomware execution, such as high CPU usage, mass file system changes, or known ransomware process names.
+- Review SharePoint or OneDrive file version history to determine the scope of encrypted or modified files and whether recovery via version rollback is possible.
+- Contact the user to verify whether the activity is legitimate or if their account or device may have been compromised.
+
+
+*False positive analysis*
+
+
+- Legitimate file uploads by trusted users may trigger alerts if the files are mistakenly flagged as ransomware. To manage this, create exceptions for specific users or groups who frequently upload large volumes of files.
+- Automated backup processes that upload encrypted files to the cloud can be misidentified as ransomware activity. Exclude these processes by identifying and whitelisting the associated service accounts or IP addresses.
+- Certain file types or extensions commonly used in business operations might be flagged. Review and adjust the detection rule to exclude these file types if they are consistently identified as false positives.
+- Collaborative tools that sync files across devices may cause multiple uploads that appear suspicious. Monitor and exclude these tools by recognizing their typical behavior patterns and adjusting the rule settings accordingly.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected user account to prevent further uploads and potential spread of ransomware within the cloud environment.
+- Quarantine the uploaded files flagged as potential ransomware to prevent access and further distribution.
+- Conduct a thorough scan of the affected user's devices and cloud storage for additional signs of ransomware or other malicious activity.
+- Notify the security operations team to initiate a deeper investigation into the source and scope of the ransomware activity.
+- Restore any affected files from secure backups, ensuring that the backups are clean and free from ransomware.
+- Review and update access controls and permissions for the affected user and related accounts to minimize the risk of future incidents.
+- Escalate the incident to senior security management and, if necessary, involve legal or compliance teams to assess any regulatory implications.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:o365.audit and
+    event.provider:SecurityComplianceCenter and
+    event.category:web and
+    rule.name:("Ransomware activity" or "Potential ransomware activity") and
+    event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Data Encrypted for Impact
+** ID: T1486
+** Reference URL: https://attack.mitre.org/techniques/T1486/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc
new file mode 100644
index 0000000000..e1e2f3292b
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc
@@ -0,0 +1,117 @@
+[[prebuilt-rule-8-19-16-deprecated-m365-security-compliance-unusual-volume-of-file-deletion]]
+=== Deprecated - M365 Security Compliance Unusual Volume of File Deletion
+
+Identifies that a user has deleted an unusually large volume of files as reported by Microsoft Cloud App Security.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+* filebeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy
+* https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: Microsoft 365
+* Use Case: Configuration Audit
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 212
+
+*Rule authors*: 
+
+* Austin Songer
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Deprecated - M365 Security Compliance Unusual Volume of File Deletion*
+
+
+Microsoft 365's cloud environment facilitates file storage and collaboration, but its vast data handling capabilities can be exploited by adversaries for data destruction. Attackers may delete large volumes of files to disrupt operations or cover their tracks. The detection rule leverages audit logs to identify anomalies in file deletion activities, flagging successful, unusual deletion volumes as potential security incidents, thus enabling timely investigation and response.
+
+
+*Possible investigation steps*
+
+
+- Review the audit logs for the specific user associated with the alert to confirm the volume and context of the file deletions, focusing on entries with event.action:"Unusual volume of file deletion" and event.outcome:success.
+- Correlate the timestamps of the deletion events with other activities in the user's account to identify any suspicious patterns or anomalies, such as unusual login locations or times.
+- Check for any recent changes in user permissions or roles that might explain the ability to delete a large volume of files, ensuring these align with the user's typical responsibilities.
+- Investigate any recent security alerts or incidents involving the same user or related accounts to determine if this activity is part of a broader attack or compromise.
+- Contact the user or their manager to verify if the deletions were intentional and authorized, and gather any additional context that might explain the activity.
+- Assess the impact of the deletions on business operations and data integrity, and determine if any recovery actions are necessary to restore critical files.
+
+
+*False positive analysis*
+
+
+- High-volume legitimate deletions during data migration or cleanup projects can trigger false positives. To manage this, create exceptions for users or groups involved in these activities during the specified time frame.
+- Automated processes or scripts that perform bulk deletions as part of routine maintenance may be flagged. Identify these processes and whitelist them to prevent unnecessary alerts.
+- Users with roles in data management or IT support may regularly delete large volumes of files as part of their job responsibilities. Establish a baseline for these users and adjust the detection thresholds accordingly.
+- Temporary spikes in file deletions due to organizational changes, such as department restructuring, can be mistaken for malicious activity. Monitor these events and temporarily adjust the rule parameters to accommodate expected changes.
+- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded from alerts, maintaining the effectiveness of the detection rule.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected user account to prevent further unauthorized file deletions. This can be done by disabling the account or changing the password.
+- Review the audit logs to identify the scope of the deletion and determine if any critical or sensitive files were affected. Restore these files from backups if available.
+- Conduct a thorough review of the affected user's recent activities to identify any other suspicious actions or potential indicators of compromise.
+- Escalate the incident to the security operations team for further investigation and to determine if the deletion is part of a larger attack or breach.
+- Implement additional monitoring on the affected account and similar high-risk accounts to detect any further unusual activities.
+- Review and update access controls and permissions to ensure that users have the minimum necessary access to perform their job functions, reducing the risk of large-scale deletions.
+- Coordinate with the IT and security teams to conduct a post-incident review, identifying any gaps in the response process and implementing improvements to prevent recurrence.
+
+==== Setup
+
+
+The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:o365.audit and event.provider:SecurityComplianceCenter and event.category:web and event.action:"Unusual volume of file deletion" and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Data Destruction
+** ID: T1485
+** Reference URL: https://attack.mitre.org/techniques/T1485/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc
new file mode 100644
index 0000000000..fea1fd3d73
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc
@@ -0,0 +1,112 @@
+[[prebuilt-rule-8-19-16-deprecated-m365-security-compliance-user-restricted-from-sending-email]]
+=== Deprecated - M365 Security Compliance User Restricted from Sending Email
+
+Identifies when a user has been restricted from sending email due to exceeding sending limits of the service policies per the Security Compliance Center.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+* filebeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy
+* https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: Microsoft 365
+* Use Case: Configuration Audit
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 212
+
+*Rule authors*: 
+
+* Austin Songer
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Deprecated - M365 Security Compliance User Restricted from Sending Email*
+
+
+Microsoft 365 enforces email sending limits to prevent abuse and ensure service integrity. Adversaries may exploit compromised accounts to send spam or phishing emails, triggering these limits. The detection rule monitors audit logs for successful restrictions by the Security Compliance Center, indicating potential misuse of valid accounts, aligning with MITRE ATT&CK's Initial Access tactic.
+
+
+*Possible investigation steps*
+
+
+- Review the audit logs in Microsoft 365 to confirm the event details, focusing on entries with event.dataset:o365.audit and event.provider:SecurityComplianceCenter to ensure the restriction was logged correctly.
+- Identify the user account that was restricted by examining the event.action:"User restricted from sending email" and event.outcome:success fields to understand which account triggered the alert.
+- Investigate the recent email activity of the restricted user account to determine if there was any unusual or suspicious behavior, such as a high volume of outbound emails or patterns consistent with spam or phishing.
+- Check for any recent changes in account permissions or configurations that might indicate unauthorized access or compromise, aligning with the MITRE ATT&CK technique T1078 for Valid Accounts.
+- Assess whether there are any other related alerts or incidents involving the same user or similar patterns, which could indicate a broader security issue or coordinated attack.
+
+
+*False positive analysis*
+
+
+- High-volume legitimate email campaigns by marketing or communication teams can trigger sending limits. Coordinate with these teams to understand their schedules and create exceptions for known campaigns.
+- Automated systems or applications using Microsoft 365 accounts for sending notifications or alerts may exceed limits. Identify these accounts and consider using service accounts with appropriate permissions and limits.
+- Users with delegated access to multiple mailboxes might inadvertently trigger restrictions. Review and adjust permissions or create exceptions for these users if their activity is verified as legitimate.
+- Temporary spikes in email activity due to business needs, such as end-of-quarter communications, can cause false positives. Monitor these periods and adjust thresholds or create temporary exceptions as needed.
+- Misconfigured email clients or scripts that repeatedly attempt to send emails can appear as suspicious activity. Ensure proper configuration and monitor for any unusual patterns that may need exceptions.
+
+
+*Response and remediation*
+
+
+- Immediately disable the compromised user account to prevent further unauthorized email activity and potential spread of phishing or spam.
+- Conduct a password reset for the affected account and enforce multi-factor authentication (MFA) to enhance security and prevent future unauthorized access.
+- Review the audit logs for any additional suspicious activities associated with the compromised account, such as unusual login locations or times, and investigate any anomalies.
+- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts.
+- Escalate the incident to the security operations team for further analysis and to determine if other accounts or systems have been compromised.
+- Implement additional email filtering rules to block similar phishing or spam patterns identified in the incident to prevent recurrence.
+- Update and enhance detection rules and monitoring to quickly identify and respond to similar threats in the future, leveraging insights from the current incident.
+
+==== Setup
+
+
+The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:o365.audit and event.provider:SecurityComplianceCenter and event.category:web and event.action:"User restricted from sending email" and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-teams-external-access-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-teams-external-access-enabled.asciidoc
new file mode 100644
index 0000000000..8e2c999612
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-teams-external-access-enabled.asciidoc
@@ -0,0 +1,118 @@
+[[prebuilt-rule-8-19-16-deprecated-m365-teams-external-access-enabled]]
+=== Deprecated - M365 Teams External Access Enabled
+
+Identifies when external access is enabled in Microsoft Teams. External access lets Teams and Skype for Business users communicate with other users that are outside their organization. An adversary may enable external access or add an allowed domain to exfiltrate data or maintain persistence in an environment.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+* filebeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/microsoftteams/manage-external-access
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: Microsoft 365
+* Use Case: Configuration Audit
+* Tactic: Defense Evasion
+* 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 Deprecated - M365 Teams External Access Enabled*
+
+
+Microsoft Teams' external access feature allows users to communicate with individuals outside their organization, facilitating collaboration. However, adversaries can exploit this by enabling external access or adding trusted domains to exfiltrate data or maintain persistence. The detection rule monitors audit logs for changes in federation settings, specifically when external access is successfully enabled, indicating potential misuse.
+
+
+*Possible investigation steps*
+
+
+- Review the audit logs for the specific event.action "Set-CsTenantFederationConfiguration" to identify when and by whom the external access was enabled.
+- Examine the o365.audit.Parameters.AllowFederatedUsers field to confirm that it is set to True, indicating that external access was indeed enabled.
+- Investigate the user account associated with the event to determine if the action was authorized and if the account has a history of suspicious activity.
+- Check the event.provider field to see if the change was made through SkypeForBusiness or MicrosoftTeams, which may provide additional context on the method used.
+- Assess the event.outcome field to ensure the action was successful and not a failed attempt, which could indicate a potential security threat.
+- Look into any recent changes in the list of allowed domains to identify if any unauthorized or suspicious domains have been added.
+
+
+*False positive analysis*
+
+
+- Routine administrative changes to federation settings can trigger alerts. Regularly review and document these changes to differentiate between legitimate and suspicious activities.
+- Organizations with frequent collaboration with external partners may see increased alerts. Consider creating exceptions for known trusted domains to reduce noise.
+- Scheduled updates or policy changes by IT teams might enable external access temporarily. Coordinate with IT to log these activities and exclude them from triggering alerts.
+- Automated scripts or tools used for configuration management can inadvertently enable external access. Ensure these tools are properly documented and monitored to prevent false positives.
+- Changes made during mergers or acquisitions can appear suspicious. Maintain a record of such events and adjust monitoring rules accordingly to account for expected changes.
+
+
+*Response and remediation*
+
+
+- Immediately disable external access in Microsoft Teams to prevent further unauthorized communication with external domains.
+- Review and remove any unauthorized or suspicious domains added to the allowed list in the Teams federation settings.
+- Conduct a thorough audit of recent changes in the Teams configuration to identify any other unauthorized modifications or suspicious activities.
+- Reset credentials and enforce multi-factor authentication for accounts involved in the configuration change to prevent further unauthorized access.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Escalate the incident to the incident response team if there is evidence of data exfiltration or if the scope of the breach is unclear.
+- Implement enhanced monitoring and alerting for changes in Teams federation settings to detect similar threats in the future.
+
+==== Setup
+
+
+The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:o365.audit and event.provider:(SkypeForBusiness or MicrosoftTeams) and
+event.category:web and event.action:"Set-CsTenantFederationConfiguration" and
+o365.audit.Parameters.AllowFederatedUsers:True and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-teams-guest-access-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-teams-guest-access-enabled.asciidoc
new file mode 100644
index 0000000000..c9841e4ca5
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-m365-teams-guest-access-enabled.asciidoc
@@ -0,0 +1,117 @@
+[[prebuilt-rule-8-19-16-deprecated-m365-teams-guest-access-enabled]]
+=== Deprecated - M365 Teams Guest Access Enabled
+
+Identifies when guest access is enabled in Microsoft Teams. Guest access in Teams allows people outside the organization to access teams and channels. An adversary may enable guest access to maintain persistence in an environment.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+* filebeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/powershell/module/skype/get-csteamsclientconfiguration?view=skype-ps
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: Microsoft 365
+* Use Case: Configuration Audit
+* Tactic: Persistence
+* 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 Deprecated - M365 Teams Guest Access Enabled*
+
+
+Microsoft Teams allows organizations to collaborate with external users through guest access, facilitating communication and teamwork. However, adversaries can exploit this feature to gain persistent access to sensitive environments by enabling guest access without authorization. The detection rule monitors audit logs for specific configurations that indicate guest access has been enabled, helping identify unauthorized changes and potential security breaches.
+
+
+*Possible investigation steps*
+
+
+- Review the audit logs to confirm the event.action "Set-CsTeamsClientConfiguration" was successfully executed with the parameter o365.audit.Parameters.AllowGuestUser set to True.
+- Identify the user account responsible for enabling guest access by examining the event logs for the user ID or account name associated with the action.
+- Check the user's activity history to determine if there are any other suspicious actions or patterns, such as changes to other configurations or unusual login times.
+- Investigate the context of the change by reviewing any related communications or requests that might justify enabling guest access, ensuring it aligns with organizational policies.
+- Assess the potential impact by identifying which teams and channels now have guest access enabled and evaluate the sensitivity of the information accessible to external users.
+- Contact the user or their manager to verify if the change was authorized and necessary, and document their response for future reference.
+
+
+*False positive analysis*
+
+
+- Legitimate collaboration with external partners may trigger alerts when guest access is enabled for business purposes. To manage this, create exceptions for known and approved external domains or specific projects that require guest access.
+- Routine administrative actions by IT staff to enable guest access for specific teams or channels can be mistaken for unauthorized changes. Implement a process to log and approve such changes internally, and exclude these from triggering alerts.
+- Automated scripts or third-party applications that configure Teams settings, including guest access, might cause false positives. Identify and whitelist these scripts or applications to prevent unnecessary alerts.
+- Changes made during scheduled maintenance windows can be misinterpreted as unauthorized. Define and exclude these time periods from monitoring to reduce false positives.
+
+
+*Response and remediation*
+
+
+- Immediately disable guest access in Microsoft Teams by updating the Teams client configuration to prevent unauthorized external access.
+- Conduct a thorough review of recent audit logs to identify any unauthorized changes or suspicious activities related to guest access settings.
+- Notify the security team and relevant stakeholders about the potential breach to ensure awareness and initiate further investigation.
+- Revoke any unauthorized guest accounts that have been added to Teams to eliminate potential persistence mechanisms.
+- Implement additional monitoring on Teams configurations to detect any future unauthorized changes to guest access settings.
+- Escalate the incident to the organization's incident response team for a comprehensive investigation and to determine if further containment actions are necessary.
+- Review and update access control policies to ensure that enabling guest access requires appropriate authorization and oversight.
+
+==== Setup
+
+
+The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:o365.audit and event.provider:(SkypeForBusiness or MicrosoftTeams) and
+event.category:web and event.action:"Set-CsTeamsClientConfiguration" and
+o365.audit.Parameters.AllowGuestUser:True and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-potential-powershell-obfuscated-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-potential-powershell-obfuscated-script.asciidoc
new file mode 100644
index 0000000000..912feb57e7
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-potential-powershell-obfuscated-script.asciidoc
@@ -0,0 +1,164 @@
+[[prebuilt-rule-8-19-16-deprecated-potential-powershell-obfuscated-script]]
+=== Deprecated - Potential PowerShell Obfuscated Script
+
+Identifies scripts that contain patterns and known methods that obfuscate PowerShell code. Attackers can use obfuscation techniques to bypass PowerShell security protections such as Antimalware Scan Interface (AMSI).
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.powershell*
+
+*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://github.com/danielbohannon/Invoke-Obfuscation
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: PowerShell Logs
+* 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 Deprecated - Potential PowerShell Obfuscated Script*
+
+
+PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its flexibility to obfuscate scripts, evading security measures like AMSI. The detection rule identifies obfuscation patterns, such as string manipulation and encoding techniques, to flag potentially malicious scripts, aiding in defense evasion detection.
+
+
+*Possible investigation steps*
+
+
+- Review the PowerShell script block text captured in the alert to identify any suspicious patterns or obfuscation techniques, such as string manipulation or encoding methods like "[string]::join" or "-Join".
+- Check the process execution details, including the parent process and command line arguments, to understand the context in which the PowerShell script was executed.
+- Investigate the source and destination of the script execution by examining the host and user details to determine if the activity aligns with expected behavior or if it originates from an unusual or unauthorized source.
+- Analyze any network connections or file modifications associated with the PowerShell process to identify potential data exfiltration or lateral movement activities.
+- Correlate the alert with other security events or logs, such as Windows Event Logs or network traffic logs, to gather additional context and identify any related suspicious activities.
+- Assess the risk and impact of the detected activity by considering the severity and risk score provided in the alert, and determine if immediate remediation actions are necessary.
+
+
+*False positive analysis*
+
+
+- Legitimate administrative scripts may use string manipulation and encoding techniques for benign purposes, such as data processing or configuration management. Review the context of the script execution and verify the source and intent before flagging it as malicious.
+- Scripts that automate complex tasks might use obfuscation-like patterns to handle data securely or efficiently. Consider whitelisting known scripts or trusted sources to reduce false positives.
+- Development and testing environments often run scripts with obfuscation patterns for testing purposes. Exclude these environments from the rule or create exceptions for specific users or groups involved in development.
+- Security tools and monitoring solutions might generate PowerShell scripts with obfuscation patterns as part of their normal operation. Identify these tools and exclude their activities from triggering the rule.
+- Regularly update the list of exceptions and whitelisted scripts to ensure that new legitimate scripts are not mistakenly flagged as threats.
+
+
+*Response and remediation*
+
+
+- Isolate the affected system from the network to prevent further spread of potentially malicious scripts.
+- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activity.
+- Conduct a thorough review of the PowerShell script block logs to identify and remove any obfuscated scripts or malicious code remnants.
+- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.
+- Update and patch the affected system to ensure all security vulnerabilities are addressed, reducing the risk of exploitation.
+- Monitor the system and network for any signs of re-infection or similar obfuscation patterns to ensure the threat has been fully mitigated.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+
+==== 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 : (
+    "[string]::join" or
+    "-Join" or
+    "[convert]::toint16" or
+    "[char][int]$_" or
+    ("ConvertTo-SecureString" and "PtrToStringAuto") or
+    "-BXor" or
+    ("replace" and "char") or
+    "[array]::reverse" or
+    "-replace"
+  ) and
+  powershell.file.script_block_text : (
+    ("$pSHoMe[" and "+$pSHoMe[") or
+    ("$ShellId[" and "+$ShellId[") or
+    ("$env:ComSpec[4" and "25]-Join") or
+    (("Set-Variable" or "SV" or "Set-Item") and "OFS") or
+    ("*MDR*" and "Name[3,11,2]") or
+    ("$VerbosePreference" and "[1,3]+'X'-Join''") or
+    ("rahc" or "ekovin" or "gnirts" or "ecnereferpesobrev" or "ecalper" or "cepsmoc" or "dillehs") or
+    ("System.Management.Automation.$([cHAr]" or "System.$([cHAr]" or ")+[cHAR]([byte]")
+  ) and
+  not powershell.file.script_block_text : (
+        ("Copyright (c) 2018 Ansible Project" or "Export-ModuleMember -Function Add-CSharpType") and
+        ("[Object]$AnsibleModule" or "$AnsibleModule.Tmpdir")
+  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc
new file mode 100644
index 0000000000..71824d4ae3
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc
@@ -0,0 +1,122 @@
+[[prebuilt-rule-8-19-16-deprecated-suspicious-printspooler-service-executable-file-creation]]
+=== Deprecated - Suspicious PrintSpooler Service Executable File Creation
+
+Detects attempts to exploit privilege escalation vulnerabilities related to the Print Spooler service. For more information refer to the following CVE's - CVE-2020-1048, CVE-2020-1337 and CVE-2020-1300 and verify that the impacted system is patched.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-endpoint.events.file-*
+* logs-windows.sysmon_operational-*
+* endgame-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://voidsec.com/cve-2020-1337-printdemon-is-dead-long-live-printdemon/
+* https://www.thezdi.com/blog/2020/7/8/cve-2020-1300-remote-code-execution-through-microsoft-windows-cab-files
+
+*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
+* Data Source: Microsoft Defender for Endpoint
+* Data Source: SentinelOne
+* Resources: Investigation Guide
+
+*Version*: 320
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Deprecated - Suspicious PrintSpooler Service Executable File Creation*
+
+
+The Print Spooler service in Windows manages print jobs, but vulnerabilities like CVE-2020-1048 can be exploited for privilege escalation. Adversaries may create malicious DLL files executed by the spooler to gain elevated privileges. The detection rule identifies such threats by monitoring file creation events linked to the spooler process, focusing on DLL files, which are common vectors for exploitation.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to confirm the presence of a file creation event with the extension "dll" associated with the "spoolsv.exe" process on a Windows host.
+- Check the file path and name of the created DLL to determine if it matches known malicious patterns or locations typically used for exploitation.
+- Investigate the source of the spoolsv.exe process by examining the parent process and any associated user accounts to identify potential unauthorized access or activity.
+- Analyze recent system logs and security events for any other suspicious activities or anomalies around the time of the DLL creation, such as unexpected user logins or privilege changes.
+- Verify the patch status of the affected system against the vulnerabilities CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300 to ensure it is up to date and not susceptible to known exploits.
+- If the DLL is confirmed to be malicious, isolate the affected system to prevent further exploitation and begin remediation efforts, including removing the malicious file and any associated threats.
+
+
+*False positive analysis*
+
+
+- Legitimate DLL updates by trusted software can trigger the rule. Users should verify the source of the DLL and, if confirmed safe, add the software's update process to an exception list.
+- System maintenance activities, such as Windows updates, may create DLLs that match the rule's criteria. Users can exclude these activities by identifying the associated update processes and adding them to the exception list.
+- Custom in-house applications that interact with the Print Spooler service might generate DLLs during normal operation. Users should validate these applications and exclude their file creation events if they are deemed non-threatening.
+- Security software or monitoring tools that interact with the Print Spooler service could inadvertently create DLLs. Users should confirm the legitimacy of these tools and configure exceptions for their operations.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Terminate the spoolsv.exe process if it is confirmed to be executing a malicious DLL, to halt any ongoing malicious activity.
+- Remove the malicious DLL file from the system to prevent re-execution and further exploitation.
+- Apply the latest security patches and updates to the affected system, specifically addressing CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300, to close the vulnerabilities exploited by the adversary.
+- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized privilege escalation has occurred.
+- Monitor the network for any signs of similar exploitation attempts or related suspicious activity, using enhanced logging and alerting mechanisms.
+- Report the incident to the appropriate internal security team or external authorities if required, providing details of the exploit and actions taken for further investigation and response.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.category : "file" and host.os.type : "windows" and event.type : "creation" and
+  process.name : "spoolsv.exe" and file.extension : "dll"
+
+----------------------------------
+
+*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-16/prebuilt-rule-8-19-16-detection-alert-on-a-process-exhibiting-cpu-spike.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-detection-alert-on-a-process-exhibiting-cpu-spike.asciidoc
new file mode 100644
index 0000000000..0aea48af4c
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-detection-alert-on-a-process-exhibiting-cpu-spike.asciidoc
@@ -0,0 +1,169 @@
+[[prebuilt-rule-8-19-16-detection-alert-on-a-process-exhibiting-cpu-spike]]
+=== Detection Alert on a Process Exhibiting CPU Spike
+
+This rule correlates security alerts with processes exhibiting unusually high CPU utilization on the same host and process ID within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise.
+
+*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*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+* Domain: Endpoint
+* Tactic: Impact
+
+*Version*: 3
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Detection Alert on a Process Exhibiting CPU Spike*
+
+
+This rule identifies processes that both triggered a security alert and exhibited unusually high CPU utilization on the
+same host and process ID within a short time window. This combination may indicate malicious execution, resource abuse, or
+post-compromise activity.
+
+
+*Possible investigation steps*
+
+- Review the correlated alert(s) to understand why the process was flagged by Elastic Defend.
+- Examine the process name, command line, and SHA-256 hash to determine whether the process is expected or known to be malicious.
+- Validate the observed CPU usage and duration to determine whether the spike is abnormal for this process and host.
+- Check for related process activity such as parent/child processes, suspicious process spawning, or privilege escalation attempts.
+- Review additional host telemetry including:
+  - Network connections initiated by the process
+  - File creation or modification events
+  - Persistence mechanisms (services, scheduled tasks, registry keys)
+- Determine whether similar activity is observed on other hosts, which may indicate a broader compromise.
+
+
+*False positive analysis*
+
+- Legitimate high-CPU processes such as software updates, backup agents, security scans, or system maintenance tasks.
+- Resource-intensive but benign applications (e.g., compilers, video encoding, data processing jobs).
+- Security tools or monitoring agents temporarily consuming high CPU.
+
+
+*Response and remediation*
+
+- If malicious activity is confirmed, isolate the affected host to prevent further impact.
+- Terminate the offending process if safe to do so.
+- Remove any identified malicious binaries or artifacts and eliminate persistence mechanisms.
+- Apply relevant patches or configuration changes to remediate the root cause.
+- Monitor the environment for recurrence of similar high-CPU processes combined with security alerts.
+- Escalate the incident if multiple hosts or indicators suggest coordinated or widespread activity.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires host CPU metrics collected via the Elastic Agent **System** integration.
+
+
+*System Metrics Integration Setup*
+
+The System integration collects host-level metrics such as CPU usage, load, memory, and process statistics and sends them to Elasticsearch using Elastic Agent.
+
+
+*Prerequisite Requirements:*
+
+- Elastic Agent managed by Fleet
+- A Fleet Server configured and reachable
+  Refer to the Fleet Server setup guide:
+  https://www.elastic.co/guide/en/fleet/current/fleet-server.html
+
+
+*The following steps should be executed in order to enable CPU metrics collection:*
+
+- Go to the Kibana home page and click **Add integrations**.
+- In the search bar, enter **System** and select the **System** integration.
+- Click **Add System**.
+- Configure an integration name and optionally add a description.
+- Under **Metrics**, ensure the following datasets are enabled:
+  - `system.cpu`
+  - `system.load` (optional but recommended)
+  - `system.process` (optional, if process-level CPU is required)
+- Review optional and advanced settings as needed.
+- Add the integration to an existing agent policy or create a new agent policy.
+- Deploy the Elastic Agent to the hosts from which CPU metrics should be collected.
+- Click **Save and Continue** to finalize the setup.
+
+
+*Validation*
+
+After deployment, verify CPU metrics ingestion by confirming the presence of documents in:
+- `metrics-system.cpu-*`
+- `metrics-system.load-*` (if enabled)
+
+For more details on the System integration and available metrics, refer to the documentation:
+https://docs.elastic.co/integrations/system
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM metrics-*, .alerts-security.* METADATA _index
+| where not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
+| eval
+       // processes with more than 70% total CPU use
+       cpu_metrics_pids = CASE(_index like ".ds-metrics-system.process-*" and system.process.cpu.total.norm.pct >= 0.7, process.pid, null),
+       // any security alert with process.name and ID populated excluding low severity ones
+       alerts_pids = CASE(_index like ".internal.alerts-security.*" and kibana.alert.rule.name is not null and process.name is not null and process.pid is not null and host.id is not null and kibana.alert.risk_score > 21, process.pid, null)
+| stats pid_with_cpu_spike = COUNT_DISTINCT(cpu_metrics_pids), pid_with_alerts = COUNT_DISTINCT(alerts_pids),
+        Esql.max_cpu_pct = MAX(system.process.cpu.total.norm.pct),
+        Esql.alerts = VALUES(kibana.alert.rule.name),
+        Esql.process_hash_sha256 = VALUES(process.hash.sha256),
+        process_path = VALUES(process.executable),
+        parent_process_path = VALUES(process.parent.executable),
+        user_name = VALUES(user.name),
+        cmdline = VALUES(process.command_line) by process.pid, process.name, host.id
+| where pid_with_cpu_spike > 0 and pid_with_alerts > 0
+// populate fields to use in rule exceptions
+| eval process.hash.sha256 = MV_FIRST(Esql.process_hash_sha256),
+       process.executable = MV_FIRST(process_path),
+       process.parent.executable = MV_FIRST(parent_process_path),
+       process.command_line = MV_FIRST(cmdline),
+       user.name = MV_FIRST(user_name)
+| KEEP user.name, host.id, process.*, Esql.*
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-disabling-lsa-protection-via-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-disabling-lsa-protection-via-registry-modification.asciidoc
new file mode 100644
index 0000000000..2d6da8dd37
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-disabling-lsa-protection-via-registry-modification.asciidoc
@@ -0,0 +1,136 @@
+[[prebuilt-rule-8-19-16-disabling-lsa-protection-via-registry-modification]]
+=== Disabling Lsa Protection via Registry Modification
+
+LSA protecton is provided to prevent nonprotected processes from reading memory and injecting code. This feature provides added security for the credentials that LSA stores and manages. Adversaries may modify the RunAsPPL registry and wait or initiate a system restart to enable Lsass credentials access.
+
+*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*: 
+
+* https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection
+
+*Tags*: 
+
+* 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 for Endpoint
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+
+*Version*: 4
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Disabling Lsa Protection via Registry Modification*
+
+
+For more information about the Lsa Protection and how it works, check the https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection[official Microsoft docs page].
+
+Attackers may disable Lsa protection to access Lsass memory for credentals. This rule identifies RunAsPPL registry value modifications.
+
+
+*Possible investigation steps*
+
+
+- Verify the context of the change and if it's related to a planned system administration activity.
+- 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 behaviors in the alert timeframe.
+- Investigate abnormal behaviors observed by the subject process such as network connections, registry or file modifications, and any spawned child processes.
+
+
+*False positive analysis*
+
+
+- Approved changes to relax the Lsa protection for compatibility with third party solutions such as authentication plugins or alike.
+
+
+*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.
+- Restore UAC settings to the desired state.
+- 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).
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+registry where host.os.type == "windows" and event.type == "change" and
+  registry.data.strings != null and process.name != null and
+  registry.value : "RunAsPPL" and
+  registry.path : "*\\SYSTEM\\*ControlSet*\\Control\\Lsa\\RunAsPPL" and
+  not registry.data.strings : ("1", "0x00000001", "2", "0x00000002") and
+  not process.executable : "?:\\Windows\\System32\\SecurityHealthService.exe"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* 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: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
+* Sub-technique:
+** Name: Disable or Modify Tools
+** ID: T1562.001
+** Reference URL: https://attack.mitre.org/techniques/T1562/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-dmsa-account-creation-by-an-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-dmsa-account-creation-by-an-unusual-user.asciidoc
new file mode 100644
index 0000000000..daf7830ce6
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-dmsa-account-creation-by-an-unusual-user.asciidoc
@@ -0,0 +1,109 @@
+[[prebuilt-rule-8-19-16-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.
+
+*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*: 3
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating dMSA Account Creation by an Unusual User*
+
+
+
+*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.
+
+
+*False positive analysis*
+
+
+- Migration of legacy service accounts using delegated managed service account.
+
+
+*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.
+
+==== 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-dynamic-iex-reconstruction-via-method-string-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-dynamic-iex-reconstruction-via-method-string-access.asciidoc
new file mode 100644
index 0000000000..1ea706c809
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-dynamic-iex-reconstruction-via-method-string-access.asciidoc
@@ -0,0 +1,223 @@
+[[prebuilt-rule-8-19-16-dynamic-iex-reconstruction-via-method-string-access]]
+=== Dynamic IEX Reconstruction via Method String Access
+
+Detects PowerShell scripts that rebuilds IEX by converting method references to strings (for example, ''.IndexOf.ToString()) and extracting multiple indexed characters (for example, [n,n,n]). Attackers use method-string reconstruction to conceal dynamic execution and bypass static detections and AMSI.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: PowerShell Logs
+* Resources: Investigation Guide
+
+*Version*: 11
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Dynamic IEX Reconstruction via Method String Access*
+
+
+This alert indicates PowerShell script block content that uses method-to-string conversion and indexed character extraction to assemble an execution primitive at runtime, commonly "IEX" (Invoke-Expression). This obfuscation technique can conceal dynamic execution intent and is often used to reduce obvious keywords in the script body.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
+
+
+*Possible investigation steps*
+
+
+- Establish execution context and scope:
+  - Review `host.name` and `host.id` to identify the affected endpoint and its role/criticality.
+  - Review `user.name`, `user.domain`, and `user.id` to determine whether the activity aligns with expected administrative or automation usage.
+  - Review `file.path`, `file.directory`, and `file.name` (when present) to understand whether the script originated from an on-disk file.
+  - Review `agent.id` to pivot to other telemetry from the same endpoint and timeframe.
+
+- Validate what matched and how extensively it appears:
+  - Review `Esql.script_block_pattern_count` to gauge how often the technique appears within the script block (higher counts can indicate heavier obfuscation).
+  - Use `Esql.script_block_tmp` to quickly locate the matched regions, then review the corresponding locations in `powershell.file.script_block_text` for the exact construct and nearby context.
+  - Review `powershell.file.script_block_length` alongside `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_unique_symbols` to help distinguish isolated string tricks from broader obfuscation.
+
+- Reconstruct the full script block when content is split:
+  - Pivot on `powershell.file.script_block_id` and order results by `powershell.sequence`.
+  - Use `powershell.total` to confirm you have all fragments before making a final assessment.
+  - Preserve the reassembled content from `powershell.file.script_block_text` for follow-on analysis and scoping.
+
+- Determine the reconstructed token and follow-on behavior:
+  - In `powershell.file.script_block_text`, identify the method string being indexed and the associated index list (for example, [n,n,n]) to determine what characters are being assembled.
+  - Identify how the reconstructed string is used (for example, invoked directly, assigned to a variable, or passed as an argument) and what content it ultimately executes.
+  - Capture any secondary artifacts referenced in the script content (for example, embedded payload strings, additional script blocks, or external resource locations) and use them to drive further correlation.
+
+- Validate likely origin and initiating source:
+  - If `file.path` is present, validate whether the script location is expected for the user and host, and whether it appears in a user-writable location or a standard administrative tooling path.
+  - If file origin fields are not present, the script may have been executed interactively or generated at runtime; rely on surrounding endpoint telemetry to identify the initiating process and any related activity.
+
+- Correlate with adjacent activity to understand impact:
+  - Review other PowerShell script blocks on the same `host.id` and `user.id` around the alert time to identify staging steps and any follow-on execution.
+  - If process telemetry is available, identify the PowerShell process and its parent process that initiated execution, and check for suspicious child processes near the alert time.
+  - If network or file telemetry is available, look for downloads, outbound connections, and file writes temporally aligned with the script block execution and the content referenced within `powershell.file.script_block_text`.
+
+- Assess prevalence across the environment:
+  - Search for similar patterns (including stable substrings from `powershell.file.script_block_text`) across other hosts and users.
+  - Prioritize results with higher `Esql.script_block_pattern_count` and higher obfuscation metrics to identify likely common tooling or shared payloads.
+
+
+*False positive analysis*
+
+
+- PowerShell developers or automation teams may experiment with unconventional string manipulation, but method-string indexing to assemble execution primitives is uncommon in routine administration.
+- Authorized security testing, malware analysis, or threat emulation activities can intentionally use this technique; validate against approved testing windows and operator accounts.
+- Some script packaging or code protection approaches can introduce non-standard string operations; treat as benign only when the script origin (`file.path` / `file.name`), execution context (`user.id`), and surrounding host activity support a known, approved workflow.
+
+
+*Response and remediation*
+
+
+- If malicious or suspicious activity is confirmed:
+  - Contain the affected host identified by `host.id` to prevent additional execution and lateral movement.
+  - Preserve evidence from the alert, including `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, `file.path`, and `Esql.script_block_pattern_count`.
+  - Scope for related activity by searching for similar content patterns across the environment and identifying additional impacted hosts and accounts.
+  - If an on-disk script is involved (`file.path` present), collect the file for analysis and remove or quarantine it according to your incident handling process.
+  - Review the associated account (`user.id`) for additional suspicious activity and remediate credential exposure as appropriate (for example, reset credentials and review recent authentication activity).
+
+- If the activity is determined to be benign:
+  - Document the legitimate script source, expected hosts, and operator accounts for future triage.
+  - Reduce noise with narrowly scoped suppression using stable characteristics available in the alert (for example, consistent `file.path` and repeatable non-sensitive substrings in `powershell.file.script_block_text`), while continuing to monitor for deviations.
+
+
+==== 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]
+----------------------------------
+from logs-windows.powershell_operational* metadata _id, _version, _index
+| where event.code == "4104"
+
+// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for
+| eval Esql.script_block_length = length(powershell.file.script_block_text)
+| where Esql.script_block_length > 500
+
+// replace the patterns we are looking for with the 🔥 emoji to enable counting them
+// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1
+| eval Esql.script_block_tmp = replace(
+    powershell.file.script_block_text,
+    """(?i)['"]['"].(Insert|Normalize|Chars|substring|Remove|LastIndexOfAny|LastIndexOf|IsNormalized|IndexOfAny|IndexOf)[^\[]+\[\d+,\d+,\d+\]""",
+    "🔥"
+)
+
+// count how many patterns were detected by calculating the number of 🔥 characters inserted
+| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", ""))
+
+// keep the fields relevant to the query, although this is not needed as the alert is populated using _id
+| keep
+    Esql.script_block_pattern_count,
+    Esql.script_block_length,
+    Esql.script_block_tmp,
+    powershell.file.*,
+    file.path,
+    file.directory,
+    powershell.sequence,
+    powershell.total,
+    _id,
+    _version,
+    _index,
+    host.name,
+    host.id,
+    agent.id,
+    user.id
+
+// Filter for scripts that match the pattern at least once
+| where Esql.script_block_pattern_count >= 1
+
+| where not (
+    file.directory like "C:\\\\Program Files\\\\WindowsPowerShell\\\\Modules\\\\Maester\\\\1.1.0*" or
+    file.directory like "C:\\\\Users\\\\*\\\\Documents\\\\WindowsPowerShell\\\\Modules\\\\Maester\\\\1.1.0*"
+  )
+  // ESQL requires this condition, otherwise it only returns matches where file.directory exists.
+  or file.directory is null
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-elastic-agent-service-terminated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-elastic-agent-service-terminated.asciidoc
new file mode 100644
index 0000000000..952541282e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-elastic-agent-service-terminated.asciidoc
@@ -0,0 +1,146 @@
+[[prebuilt-rule-8-19-16-elastic-agent-service-terminated]]
+=== Elastic Agent Service Terminated
+
+Identifies the Elastic endpoint agent has stopped and is no longer running on the host. Adversaries may attempt to disable security monitoring tools in an attempt to evade detection or prevention capabilities during an intrusion. This may also indicate an issue with the agent itself and should be addressed to ensure defensive measures are back in a stable state.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* OS: Windows
+* OS: macOS
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 112
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Elastic Agent Service Terminated*
+
+
+The Elastic Agent is a crucial component for monitoring and securing endpoints across various operating systems. It ensures continuous security oversight by collecting and analyzing data. Adversaries may attempt to disable this agent to evade detection, compromising system defenses. The detection rule identifies suspicious termination activities by monitoring specific processes and commands across Windows, Linux, and macOS, flagging potential defense evasion attempts.
+
+
+*Possible investigation steps*
+
+
+- Review the event logs to identify the exact process and command used to terminate the Elastic Agent, focusing on the process names and arguments such as "net.exe", "sc.exe", "systemctl", and "pkill" with arguments like "stop", "uninstall", or "disable".
+- Check the timeline of events around the termination to identify any preceding suspicious activities or anomalies that might indicate an adversary's presence or actions.
+- Investigate the user account associated with the process termination to determine if it was authorized or if there are signs of account compromise.
+- Examine the host for any other signs of tampering or compromise, such as unauthorized changes to system configurations or the presence of other malicious processes.
+- Verify the current status of the Elastic Agent on the affected host and attempt to restart it if it is not running, ensuring that security monitoring is restored.
+- Correlate this event with other alerts or logs from the same host or network to identify potential patterns or coordinated attack activities.
+
+
+*False positive analysis*
+
+
+- Routine maintenance activities may trigger the rule if administrators use commands like systemctl or service to stop the Elastic Agent for updates or configuration changes. To manage this, create exceptions for known maintenance windows or authorized personnel.
+- Automated scripts or deployment tools that temporarily disable the Elastic Agent during software installations or updates can cause false positives. Identify these scripts and whitelist their execution paths or specific arguments.
+- Testing environments where Elastic Agent is frequently started and stopped for development purposes might generate alerts. Exclude these environments by specifying their hostnames or IP addresses in the rule exceptions.
+- Security tools or processes that interact with the Elastic Agent, such as backup solutions or system monitoring tools, might inadvertently stop the service. Review these interactions and adjust the rule to ignore specific process names or arguments associated with these tools.
+- User-initiated actions, such as troubleshooting or system performance optimization, may involve stopping the Elastic Agent. Educate users on the impact of these actions and establish a protocol for notifying the security team when such actions are necessary.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or potential lateral movement by adversaries.
+- Verify the status of the Elastic Agent on the affected host and attempt to restart the service. If the service fails to restart, investigate potential causes such as corrupted files or missing dependencies.
+- Conduct a thorough review of recent process execution logs on the affected host to identify any unauthorized or suspicious activities that may have led to the termination of the Elastic Agent.
+- If malicious activity is confirmed, perform a comprehensive malware scan and remove any identified threats. Ensure that the host is clean before reconnecting it to the network.
+- Review and update endpoint security configurations to prevent unauthorized termination of security services. This may include implementing stricter access controls or using application whitelisting.
+- Escalate the incident to the security operations team for further analysis and to determine if additional hosts are affected or if there is a broader security incident underway.
+- Document the incident, including all actions taken and findings, to enhance future response efforts and update incident response plans as necessary.
+
+==== Setup
+
+
+
+*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
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where
+/* net, sc or wmic stopping or deleting Elastic Agent on Windows */
+(event.type == "start" and
+  process.name : ("net.exe", "sc.exe", "wmic.exe","powershell.exe","taskkill.exe","PsKill.exe","ProcessHacker.exe") and
+  process.args : ("stopservice","uninstall", "stop", "disabled","Stop-Process","terminate","suspend") and
+  process.args : ("elasticendpoint", "Elastic Agent","elastic-agent","elastic-endpoint"))
+or
+/* service or systemctl used to stop Elastic Agent on Linux */
+(event.type == "start" and
+  (process.name in ("systemctl", "service", "chkconfig", "update-rc.d") and
+    process.args : ("elastic-agent", "elastic-agent.service", "ElasticEndpoint") and
+    process.args : ("stop", "disable", "remove", "off", "kill", "mask"))
+  or
+  /* pkill , killall used to stop Elastic Agent or Endpoint on Linux */
+(event.type == "start" and process.name in ("pkill", "killall", "kill") and process.args : ("elastic-agent", "elastic-endpoint"))
+  or
+  /* Unload Elastic Defend extension on MacOS */
+(event.type == "start" and process.name : "kextunload" and process.args : "com.apple.iokit.EndpointSecurity"))
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
+* Sub-technique:
+** Name: Disable or Modify Tools
+** ID: T1562.001
+** Reference URL: https://attack.mitre.org/techniques/T1562/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-elastic-defend-alert-followed-by-telemetry-loss.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-elastic-defend-alert-followed-by-telemetry-loss.asciidoc
new file mode 100644
index 0000000000..0db50cd0df
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-elastic-defend-alert-followed-by-telemetry-loss.asciidoc
@@ -0,0 +1,131 @@
+[[prebuilt-rule-8-19-16-elastic-defend-alert-followed-by-telemetry-loss]]
+=== Elastic Defend Alert Followed by Telemetry Loss
+
+Detects when an Elastic Defend endpoint alert is generated on a host and is not followed by any subsequent endpoint telemetry (process, network, registry, library, or DNS events) within a short time window. This behavior may indicate endpoint security evasion, agent tampering, sensor disablement, service termination, system crash, or malicious interference with telemetry collection following detection.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.*
+
+*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/T1562/001/
+
+*Tags*: 
+
+* Domain: Endpoint
+* Data Source: Elastic Defend
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Tactic: Execution
+* Rule Type: Higher-Order Rule
+* 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 Elastic Defend Alert Followed by Telemetry Loss*
+
+
+This rule identifies situations where an Elastic Defend alert is generated on a host and is not followed by
+any normal endpoint activity events within a short time window. This may indicate agent tampering, sensor
+disablement, host shutdown, system crash, or defense evasion behavior.
+
+
+*Possible investigation steps*
+
+
+- Review the original `endpoint.alert` event and identify the detection that triggered the alert.
+- Check the host’s online status, uptime, and reboot history.
+- Verify the health and status of the Elastic Defend agent and related services.
+- Look for evidence of agent tampering, service stops, or security control modifications.
+- Correlate with activity immediately preceding the alert for signs of exploitation or evasion.
+- Determine if similar alert → silence patterns are occurring on other hosts.
+
+
+*False positive analysis*
+
+
+- Legitimate system reboots or shutdowns
+- Network connectivity loss
+- Elastic Agent upgrades or restarts
+- Endpoint service crashes
+- Maintenance or IT operations
+
+
+*Response and remediation*
+
+
+- Validate host and agent availability.
+- Reconnect or re-enroll the agent if telemetry is missing.
+- Isolate the host if malicious activity is suspected.
+- Investigate for security control tampering.
+- Perform broader environment hunting for similar patterns.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by host.id with maxspan=5m
+ [any where event.dataset == "endpoint.alerts"]
+ ![any where event.category in ("process", "library", "registry", "network", "dns")]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
+* Sub-technique:
+** Name: Disable or Modify Tools
+** ID: T1562.001
+** Reference URL: https://attack.mitre.org/techniques/T1562/001/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: 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-16/prebuilt-rule-8-19-16-elastic-defend-and-network-security-alerts-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-elastic-defend-and-network-security-alerts-correlation.asciidoc
new file mode 100644
index 0000000000..9533eed7be
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-elastic-defend-and-network-security-alerts-correlation.asciidoc
@@ -0,0 +1,156 @@
+[[prebuilt-rule-8-19-16-elastic-defend-and-network-security-alerts-correlation]]
+=== Elastic Defend and Network Security Alerts Correlation
+
+This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto Networks (PANW) and Fortinet Fortigate by host.ip and source.ip. This may indicate that this host is compromised and triggering multi-datasource alerts.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 10m
+
+*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+* Data Source: Elastic Defend
+* Data Source: Fortinet
+* Data Source: PAN-OS
+
+*Version*: 6
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Elastic Defend and Network Security Alerts Correlation*
+
+
+This rule correlate any Elastic Defend alert with suspicious events from Network Security datasources like Palo Alto Networks (PANW), Fortinet Fortigate and Suricata by host.ip and source.ip.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific host and users involved.
+- Investiguate the network alerts by destination.ip and message.
+- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
+- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
+- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
+- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
+
+
+*False positive analysis*
+
+
+- IP address ranges overlap where the host.ip value from the Elastic Defend alert is unrelated to the source.ip value from the Network Security alert.
+- Alerts from routine administrative tasks may trigger multiple alerts. Review and exclude known benign activities such as scheduled software updates or system maintenance.
+- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
+- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
+- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
+- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.
+
+
+*Response and remediation*
+
+
+- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
+- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
+- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM logs-* metadata _id
+| WHERE
+        // Elastic Defend Alerts
+        (event.module == "endpoint" and event.dataset == "endpoint.alerts") or
+
+        // PANW suspicious events
+        (event.dataset == "panw.panos" and
+         event.action in ("virus_detected", "wildfire_virus_detected", "c2_communication", "spyware_detected", "large_upload", "denied", "exploit_detected")) or
+
+        // Fortigate suspicious events
+        (event.dataset == "fortinet_fortigate.log" and
+         (event.action in ("outbreak-prevention", "infected", "blocked") or message like "backdoor*" or message like "Proxy*" or message like "anomaly*" or message like "P2P*" or message like "misc*" or message like "DNS.Over.HTTPS" or message like "Remote.Access")) or
+
+        // Suricata
+        (event.dataset == "suricata.eve" and message in ("Command and Control Traffic", "Potentially Bad Traffic", "A Network Trojan was detected", "Detection of a Network Scan", "Domain Observed Used for C2 Detected", "Malware Command and Control Activity Detected"))
+
+// extract source.ip from PANW or Fortigate events and host.ip from Elastic Defend alert
+|eval fw_alert_source_ip = CASE(event.dataset in ("panw.panos", "fortinet_fortigate.log"), source.ip, null),
+      elastic_defend_alert_host_ip = CASE(event.module == "endpoint" and event.dataset == "endpoint.alerts", host.ip, null)
+| eval Esql.source_ip = COALESCE(fw_alert_source_ip, elastic_defend_alert_host_ip)
+| where Esql.source_ip is not null
+
+// group by host_source_ip shared between FG/PANW and Elastic Defend
+| stats Esql.alerts_count = COUNT(*),
+        Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
+        Esql.message_values_distinct_count = COUNT_DISTINCT(message),
+        Esql.event_module_values = VALUES(event.module),
+        Esql.message_values = VALUES(message),
+        Esql.event_action_values = VALUES(event.action),
+        Esql.process_executable_values = VALUES(process.executable),
+        Esql.process_hash_sha256_values = VALUES(process.hash.sha256),
+        Esql.process_cmdline_values = VALUES(process.command_line),
+        Esql.file_path_values = VALUES(file.path),
+        Esql.file_hash_sha256_values = VALUES(file.hash.sha256),
+        Esql.host_id_values = VALUES(host.id),
+        Esql.user_name_values = VALUES(user.name),
+        Esql.destination_ip_values = VALUES(destination.ip)
+        by Esql.source_ip
+| where Esql.event_module_distinct_count >= 2 AND Esql.message_values_distinct_count >= 2
+| eval concat_module_values = MV_CONCAT(Esql.event_module_values, ",")
+// Make sure an endpoint alert is present along one of the network ones
+| where concat_module_values like "*endpoint*"
+
+// Move single values to their corresponding ECS fields for alerts exclusion
+| eval source.ip = mv_min(Esql.source_ip),
+       host.id = mv_min(Esql.host_id_values),
+       user.name = mv_min(Esql.user_name_values)
+
+| keep source.ip, host.id, user.name, Esql.*
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-entra-id-federated-identity-credential-issuer-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-entra-id-federated-identity-credential-issuer-modified.asciidoc
new file mode 100644
index 0000000000..ce507676b9
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-entra-id-federated-identity-credential-issuer-modified.asciidoc
@@ -0,0 +1,145 @@
+[[prebuilt-rule-8-19-16-entra-id-federated-identity-credential-issuer-modified]]
+=== Entra ID Federated Identity Credential Issuer Modified
+
+Detects when the issuer URL of a federated identity credential is changed on an Entra ID application. Adversaries may modify the issuer to point to an attacker-controlled identity provider, enabling them to authenticate as the application's service principal and gain persistent access to Azure resources. This technique allows bypassing traditional authentication controls by federating trust with a malicious external identity provider.
+
+*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*: 
+
+* https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/
+* https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Audit Logs
+* Use Case: Identity and Access Audit
+* Tactic: Persistence
+* Tactic: Privilege Escalation
+* Resources: Investigation Guide
+
+*Version*: 8
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Entra ID Federated Identity Credential Issuer Modified*
+
+
+This rule detects when the issuer URL within a federated identity credential is modified on an Entra ID application. Federated identity credentials allow applications to authenticate using tokens from external identity providers (like GitHub Actions, AWS, etc.) without managing secrets. Adversaries can abuse this by changing the issuer to an attacker-controlled identity provider, allowing them to generate valid tokens and authenticate as the application's service principal.
+
+This technique provides persistent access to Azure resources with the application's permissions and bypasses secret-based authentication controls.
+
+
+*Possible investigation steps*
+
+
+- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `ipAddress` to identify who made the change and from where.
+- Examine the `Esql.external_idp_old_issuer` and `Esql.external_idp_new_issuer` fields to determine if the new issuer is expected or potentially malicious.
+- Check if the new issuer domain is controlled by the organization or if it's an external/suspicious domain.
+- Review the application's assigned roles and permissions to understand the scope of access gained.
+- Use `azure.correlation_id` to pivot to related changes in the same session.
+- Check for subsequent Azure sign-in activity using the modified federated credential.
+- Investigate if the application has been used to access sensitive resources after the change.
+
+
+*False positive analysis*
+
+
+- Legitimate migrations from one identity provider to another (e.g., GitHub to GitLab) may trigger this detection.
+- DevOps teams may update issuer URLs as part of CI/CD pipeline changes.
+- Validate any changes with the application owner or DevOps team before taking action.
+
+
+*Response and remediation*
+
+
+- If the change is unauthorized, immediately remove or revert the federated identity credential.
+- Rotate any secrets or certificates associated with the application.
+- Review Azure sign-in logs and audit logs for any unauthorized activity using the application's identity.
+- Disable the application or service principal if compromise is confirmed.
+- Investigate how the unauthorized change occurred (e.g., compromised admin account, over-privileged service principal).
+- Implement conditional access policies and PIM (Privileged Identity Management) to protect application management operations.
+
+
+==== Setup
+
+
+
+*Microsft Entra ID Audit Logs*
+
+This rule requires the Azure integration with Microsoft Entra ID Audit Logs data stream ingesting in your Elastic Stack deployment. For more information, refer to the https://www.elastic.co/docs/reference/integrations/azure/adlogs[Microsoft Entra ID Audit Logs integration documentation].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-azure.auditlogs-* metadata _id, _version, _index
+| where event.action == "Update application"
+| where `azure.auditlogs.properties.target_resources.0.modified_properties.0.display_name` == "FederatedIdentityCredentials"
+| eval Esql.target_resources_old_value_clean = replace(`azure.auditlogs.properties.target_resources.0.modified_properties.0.old_value`, "\\\\", "")
+| eval Esql.target_resources_new_value_clean = replace(`azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`, "\\\\", "")
+| dissect Esql.target_resources_old_value_clean "%{}\"Issuer\":\"%{Esql.external_idp_old_issuer}\"%{}"
+| dissect Esql.target_resources_new_value_clean "%{}\"Issuer\":\"%{Esql.external_idp_new_issuer}\"%{}"
+| where Esql.external_idp_old_issuer is not null and Esql.external_idp_new_issuer is not null
+| where Esql.external_idp_old_issuer != Esql.external_idp_new_issuer
+| keep @timestamp, Esql.*, azure.*, event.*, cloud.*, related.*, tags, source.*, agent.*, client.*, _id, _version, _index, data_stream.namespace
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Sub-technique:
+** Name: Additional Cloud Credentials
+** ID: T1098.001
+** Reference URL: https://attack.mitre.org/techniques/T1098/001/
+* 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: Trust Modification
+** ID: T1484.002
+** Reference URL: https://attack.mitre.org/techniques/T1484/002/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc
new file mode 100644
index 0000000000..5b635be8ad
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc
@@ -0,0 +1,152 @@
+[[prebuilt-rule-8-19-16-entra-id-service-principal-federated-credential-authentication-by-unusual-client]]
+=== Entra ID Service Principal Federated Credential Authentication by Unusual Client
+
+Identifies when a service principal authenticates using a federated identity credential for the first time in the historical window. This indicates that Entra ID validated a JWT token potentially against an external OIDC identity provider and issued an access token. While legitimate for CI/CD workflows (GitHub Actions, Azure DevOps), adversaries may abuse this by configuring rogue identity providers (BYOIDP) to authenticate as compromised applications. First-time federated credential usage for a service principal warrants investigation to determine if the external identity provider is legitimate.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* logs-azure.signinlogs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/
+* https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation
+* https://github.com/dirkjanm/ROADtools
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Sign-In Logs
+* Use Case: Identity and Access Audit
+* Tactic: Initial Access
+* Tactic: Defense Evasion
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Entra ID Service Principal Federated Credential Authentication by Unusual Client*
+
+
+If this rule triggers, it indicates that a service principal has authenticated using a federated identity credential for the first time within the historical window. This means that Entra ID validated a JWT token potentially issued by an external OIDC identity provider and issued an access token for the service principal. While this can be legitimate for CI/CD workflows (e.g., GitHub Actions, Azure DevOps, Kubernetes OIDC), it can also indicate abuse by adversaries who have configured rogue identity providers (BYOIDP) to authenticate as compromised applications. For BYOIDP attacks, this is the moment the adversary's rogue identity provider is used to authenticate as the
+compromised application for the first time.
+
+
+*Possible investigation steps*
+
+
+- Identify the service principal using `azure.signinlogs.properties.app_id` and `app_display_name`.
+- Critical: Check the application's federated credential configuration in Entra ID:
+  - What is the issuer URL? Is it a known legitimate provider (GitHub Actions, Azure DevOps, Kubernetes)?
+  - When was the federated credential added? Was it recent?
+  - Who added the federated credential?
+- Review the `service_principal_credential_thumbprint` - does it match expected certificates?
+- Investigate the source IP (`azure.signinlogs.caller_ip_address`) - is it from expected CI/CD infrastructure?
+- Check what resources were accessed after authentication using `azure.signinlogs.properties.resource_display_name`.
+- Correlate with Graph Activity logs to see what API calls were made with this token.
+- Use the `correlation_id` to find related sign-in and activity events.
+- Review audit logs for recent changes to this application's federated credentials.
+
+
+*False positive analysis*
+
+
+- Legitimate CI/CD pipelines using GitHub Actions, Azure DevOps, or Kubernetes OIDC will trigger this rule on first use.
+- New application deployments with workload identity federation are expected to show as new behavior.
+- Validate the issuer URL against approved identity providers before dismissing.
+- Create baseline of applications expected to use federated credentials.
+
+
+*Response and remediation*
+
+
+- If this is unexpected federated auth for the application, immediately investigate the federated credential configuration.
+- Review the external IdP issuer URL configured on the application - is it legitimate?
+- If BYOIDP is confirmed:
+    - Remove the malicious federated credential immediately.
+    - Revoke active sessions and tokens for the affected service principal.
+    - Audit what actions were performed using the compromised identity.
+    - Investigate how the federated credential was added (compromised admin account).
+
+==== Setup
+
+
+
+*Required Microsoft Entra ID Sign-In Logs*
+
+To use this rule, ensure that Microsoft Entra ID Sign-In Logs are being collected and streamed into the Elastic Stack via the Azure integration.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: "azure.signinlogs"
+    and azure.signinlogs.category: "ServicePrincipalSignInLogs"
+    and azure.signinlogs.properties.client_credential_type: "federatedIdentityCredential"
+    and azure.signinlogs.result_signature: "SUCCESS"
+    and azure.signinlogs.properties.app_id: *
+    and not azure.signinlogs.properties.app_owner_tenant_id: (
+        "f8cdef31-a31e-4b4a-93e4-5f571e91255a" or
+        "72f988bf-86f1-41af-91ab-2d7cd011db47"
+    )
+
+----------------------------------
+
+*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-16/prebuilt-rule-8-19-16-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc
new file mode 100644
index 0000000000..f0c21c008a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc
@@ -0,0 +1,158 @@
+[[prebuilt-rule-8-19-16-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client]]
+=== Entra ID Sharepoint or OneDrive Accessed by Unusual Client
+
+Identifies when an application accesses SharePoint Online or OneDrive for Business for the first time in the tenant within a specified timeframe. This detects successful OAuth phishing campaigns, illicit consent grants, or compromised third-party applications gaining initial access to file storage. Adversaries often use malicious OAuth applications or phishing techniques to gain consent from users, allowing persistent access to organizational data repositories without traditional credential theft.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* logs-azure.signinlogs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/
+* https://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-oauth-applications-used-to-compromise-email-servers-and-spread-spam/
+* https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/manage-consent-requests
+* https://github.com/merill/microsoft-info/blob/main/_info/MicrosoftApps.json
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Domain: Storage
+* Use Case: Identity and Access Audit
+* Tactic: Collection
+* Tactic: Initial Access
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Sign-in Logs
+* Resources: Investigation Guide
+
+*Version*: 4
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Entra ID Sharepoint or OneDrive Accessed by Unusual Client*
+
+
+This rule identifies when an application accesses SharePoint Online or OneDrive for Business for the first time in the tenant. This is a critical signal for detecting successful OAuth phishing campaigns, where adversaries trick users into granting consent to malicious applications. Once consent is granted, the malicious app can persistently access file storage without further user interaction. This detection also catches illicit consent grants, compromised third-party applications, or custom malicious apps registered by adversaries.
+
+
+*Possible Investigation Steps:*
+
+
+- Identify the Application: Review `azure.signinlogs.properties.app_id` and `azure.signinlogs.properties.app_display_name` to determine which application accessed SharePoint. Cross-reference with known legitimate applications in your environment.
+- Check Application Registration: Search Entra ID app registrations for the app ID. Determine if it's a first-party Microsoft app, known third-party integration, or suspicious/unknown application.
+- Review Consent History: Investigate when and how consent was granted. Check `azure.auditlogs` for recent `Consent to application` events matching this app ID. Identify which user granted consent and whether it was admin or user consent.
+- Analyze Permissions Granted: Review the OAuth scopes and permissions granted to the application. Look for overly broad permissions (e.g., `Files.ReadWrite.All`, `Sites.ReadWrite.All`) that exceed business requirements.
+- Correlate with User Activity: Check if the user who granted consent recently received phishing emails, clicked suspicious links, or reported potential phishing attempts.
+- Inspect Source IP and Location: Review `source.ip` and `source.geo.*` fields. Determine if the sign-in originated from expected locations or suspicious infrastructure (VPNs, data centers, anonymizers).
+- Review Application Publisher: Check if the application is verified by Microsoft or has a suspicious/generic publisher name. Unverified applications with generic names (e.g., "File Viewer", "Document Manager") are common in phishing.
+- Check for Data Access: Review subsequent SharePoint audit logs to see what files/sites the application accessed after gaining consent.
+- Conditional Access Evaluation: Review `azure.signinlogs.properties.applied_conditional_access_policies` to determine if any security controls were bypassed or if the application should have been blocked.
+
+
+*False Positive Analysis*
+
+
+- New Legitimate Integrations: Newly deployed third-party SaaS applications (e.g., document management, collaboration tools) that integrate with SharePoint will trigger this detection during initial setup. Validate with IT/procurement teams.
+- Microsoft First-Party Applications: This rule excludes common Microsoft first-party apps (Office 365 SharePoint Online, OneDrive SyncEngine, OneDrive iOS App, Microsoft Office, SharePoint Web Client Extensibility, Microsoft Teams, Office 365 Exchange Online, and other Microsoft-owned app IDs). However, new Microsoft applications or features may still appear. Cross-reference unfamiliar app IDs against Microsoft's first-party app list.
+- Development/Testing: Developers testing OAuth flows or building internal applications may generate alerts in development or staging environments.
+- Organizational Changes: Mergers, acquisitions, or tenant migrations may introduce legitimate applications from partner organizations accessing SharePoint for the first time.
+
+
+*Response and Remediation*
+
+
+- Immediate Actions if Malicious:
+  - Revoke consent for the malicious application immediately via Entra ID > Enterprise Applications
+  - Revoke all active sessions and refresh tokens for affected users
+  - Disable the application's service principal to prevent further access
+  - Review and remediate any data accessed by the application using SharePoint audit logs
+- User Notification: Contact users who granted consent to inform them of the phishing attempt and provide security awareness training on identifying malicious OAuth consent requests
+- Conditional Access Hardening: Implement or strengthen Conditional Access policies to:
+  - Require admin consent for high-risk permissions (Files.ReadWrite.All, Sites.ReadWrite.All)
+  - Block unverified publishers from accessing sensitive resources
+  - Enforce device compliance and MFA for application access
+- Tenant-Wide Review: Audit all application consents across the tenant to identify other potentially malicious applications that may have gained access through similar campaigns
+- Monitor for Campaign Patterns: Check if the same malicious application targeted multiple users, indicating an organized phishing campaign. Coordinate with email security teams to identify and block phishing emails used in the campaign.
+
+
+
+==== Setup
+
+
+
+*Required Microsoft Entra ID Sign-In Logs*
+
+To use this rule, ensure that Microsoft Entra ID Sign-In Logs are being collected and streamed into the Elastic Stack via the Azure integration.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:azure.signinlogs
+    and azure.signinlogs.properties.resource_id: (
+        00000003-0000-0ff1-ce00-000000000000 or
+        6a9b9266-8161-4a7b-913a-a9eda19da220
+    ) and azure.signinlogs.properties.app_id: ( *
+        and not (
+            00000003-0000-0ff1-ce00-000000000000 or
+            08e18876-6177-487e-b8b5-cf950c1e598c or
+            ab9b8c07-8f02-4f72-87fa-80105867a763 or
+            af124e86-4e96-495a-b70a-90f90ab96707
+        )
+    )
+    and azure.signinlogs.properties.tenant_id:*
+    and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Collection
+** ID: TA0009
+** Reference URL: https://attack.mitre.org/tactics/TA0009/
+* Technique:
+** Name: Data from Information Repositories
+** ID: T1213
+** Reference URL: https://attack.mitre.org/techniques/T1213/
+* Sub-technique:
+** Name: Sharepoint
+** ID: T1213.002
+** Reference URL: https://attack.mitre.org/techniques/T1213/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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-entra-id-unusual-cloud-device-registration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-entra-id-unusual-cloud-device-registration.asciidoc
new file mode 100644
index 0000000000..aa36313a8e
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-entra-id-unusual-cloud-device-registration.asciidoc
@@ -0,0 +1,143 @@
+[[prebuilt-rule-8-19-16-entra-id-unusual-cloud-device-registration]]
+=== Entra ID Unusual Cloud Device Registration
+
+Detects a sequence of events in Microsoft Entra ID indicative of suspicious cloud-based device registration via automated tooling like ROADtools or similar frameworks. This behavior involves adding a device via the Device Registration Service, followed by the assignment of registered users and owners — a pattern consistent with techniques used to establish persistence or acquire a Primary Refresh Token (PRT). ROADtools and similar tooling leave distinct telemetry signatures such as the `Microsoft.OData.Client` user agent. These sequences are uncommon in typical user behavior and may reflect abuse of device trust for session hijacking or silent token replay.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-azure.auditlogs-*
+
+*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://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/
+* https://github.com/dirkjanm/ROADtools
+* https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Audit Logs
+* Use Case: Identity and Access Audit
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 3
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Entra ID Unusual Cloud Device Registration*
+
+
+This rule detects a sequence of Microsoft Entra ID audit events consistent with cloud device registration abuse via ROADtools or similar automation frameworks. The activity includes three correlated events:
+
+1. Add device operation from the Device Registration Service using suspicious user-agents (`Dsreg/*`, `DeviceRegistrationClient`, or `Microsoft.OData.Client/*`).
+2. Addition of a registered user with an `enterprise registration` URN.
+3. Assignment of a registered owner to the device.
+
+This pattern has been observed in OAuth phishing and PRT abuse campaigns where adversaries silently register a cloud device to obtain persistent, trusted access.
+
+
+*Possible investigation steps*
+
+
+- Identify the user principal associated with the device registration.
+- Review the `azure.auditlogs.identity` field to confirm the Device Registration Service initiated the request.
+- Check the user-agent in `azure.auditlogs.properties.additional_details.value`. Known attack tooling signatures include:
+  - `Dsreg/10.0 (Windows X.X.X)` - ROADtools Windows device registration
+  - `DeviceRegistrationClient` - ROADtools MacOS/Android device registration
+  - `Microsoft.OData.Client/*` - .NET-based tools or Graph SDK
+- Examine the OS version in the modified properties to identify potentially suspicious or outdated versions.
+- Verify the URN in the new value field (`urn:ms-drs:enterpriseregistration.windows.net`) is not being misused.
+- Use `azure.correlation_id` to pivot across all three steps of the registration flow.
+- Pivot to `azure.signinlogs` to detect follow-on activity using the new device, such as sign-ins involving refresh or primary refresh tokens.
+- Look for signs of persistence or lateral movement enabled by the newly registered device.
+- Identify the registered device name by reviewing `azure.auditlogs.properties.target_resources.0.display_name` and confirm it's expected for the user or organization.
+- Use the correlation ID `azure.correlation_id` to pivot into registered user events from Entra ID audit logs and check `azure.auditlogs.properties.target_resources.0.user_principal_name` to identify the user associated with the device registration.
+- Review any activity for this user from Entra ID sign-in logs, where the incoming token type is a `primaryRefreshToken`.
+
+
+*False positive analysis*
+
+
+- Some MDM, autopilot provisioning flows, or third-party device management tools may generate similar sequences. Validate against known provisioning tools, expected rollout windows, and device inventory.
+- Investigate whether the device name, OS version, and registration details align with normal IT workflows.
+- Check if the user-agent corresponds to legitimate automation or tooling used by your organization.
+
+
+*Response and remediation*
+
+
+- If confirmed malicious, remove the registered device from Entra ID.
+- Revoke refresh tokens and primary refresh tokens associated with the user and device.
+- Disable the user account and initiate password reset and identity verification procedures.
+- Review audit logs and sign-in activity for additional indicators of persistence or access from the rogue device.
+- Tighten conditional access policies to restrict device registration and enforce compliance or hybrid join requirements.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by azure.correlation_id with maxspan=5m
+[any where event.dataset == "azure.auditlogs" and
+    azure.auditlogs.identity == "Device Registration Service" and
+    azure.auditlogs.operation_name == "Add device" and
+    (
+        azure.auditlogs.properties.additional_details.value like "Microsoft.OData.Client/*" or
+        azure.auditlogs.properties.additional_details.value like "Dsreg/*" or
+        azure.auditlogs.properties.additional_details.value == "DeviceRegistrationClient"
+    ) and
+    `azure.auditlogs.properties.target_resources.0.modified_properties.1.display_name` == "CloudAccountEnabled" and
+    `azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value` == "[true]"]
+[any where event.dataset == "azure.auditlogs" and
+    azure.auditlogs.operation_name == "Add registered users to device" and
+    `azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value` like "*urn:ms-drs:enterpriseregistration.windows.net*"]
+[any where event.dataset == "azure.auditlogs" and
+    azure.auditlogs.operation_name == "Add registered owner to device"]
+
+----------------------------------
+
+*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-16/prebuilt-rule-8-19-16-execution-via-windows-subsystem-for-linux.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-execution-via-windows-subsystem-for-linux.asciidoc
new file mode 100644
index 0000000000..b6a3195cdd
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-execution-via-windows-subsystem-for-linux.asciidoc
@@ -0,0 +1,156 @@
+[[prebuilt-rule-8-19-16-execution-via-windows-subsystem-for-linux]]
+=== Execution via Windows Subsystem for Linux
+
+Detects attempts to execute a program on the host from the Windows Subsystem for Linux. Adversaries may enable and use WSL for Linux to avoid detection.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* endgame-*
+* logs-crowdstrike.fdr*
+* logs-endpoint.events.process-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-system.security*
+* logs-windows.forwarded*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://learn.microsoft.com/en-us/windows/wsl/wsl-config
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Windows Security Event Logs
+* Data Source: Microsoft Defender for Endpoint
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+* Data Source: Sysmon
+
+*Version*: 214
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Execution via Windows Subsystem for Linux*
+
+
+Windows Subsystem for Linux (WSL) allows users to run Linux binaries natively on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute malicious scripts or binaries, bypassing traditional Windows security mechanisms. The detection rule identifies suspicious executions initiated by WSL processes, excluding known safe executables, to flag potential misuse for defense evasion.
+
+
+*Possible investigation steps*
+
+
+- Review the process details to identify the executable path and determine if it matches any known malicious or suspicious binaries not listed in the safe executables.
+- Investigate the parent process, specifically wsl.exe or wslhost.exe, to understand how the execution was initiated and if it aligns with expected user behavior or scheduled tasks.
+- Check the user account associated with the process execution to verify if the activity is consistent with the user's typical behavior or if the account may have been compromised.
+- Analyze the event dataset, especially if it is from crowdstrike.fdr, to gather additional context about the process execution and any related activities on the host.
+- Correlate the alert with other security events or logs from data sources like Microsoft Defender for Endpoint or SentinelOne to identify any related suspicious activities or patterns.
+- Assess the risk score and severity in the context of the organization's environment to prioritize the investigation and response actions accordingly.
+
+
+*False positive analysis*
+
+
+- Legitimate administrative tasks using WSL may trigger alerts. Users can create exceptions for known administrative scripts or binaries that are frequently executed via WSL.
+- Development environments often use WSL for compiling or testing code. Exclude specific development tools or scripts that are regularly used by developers to prevent unnecessary alerts.
+- Automated system maintenance scripts running through WSL can be mistaken for malicious activity. Identify and whitelist these scripts to reduce false positives.
+- Security tools or monitoring solutions that leverage WSL for legitimate purposes should be identified and excluded from detection to avoid interference with their operations.
+- Frequent use of WSL by specific users or groups for non-malicious purposes can be managed by creating user-based exceptions, allowing their activities to proceed without triggering alerts.
+
+
+*Response and remediation*
+
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified as being executed via WSL that are not part of the known safe executables list.
+- Conduct a thorough review of the affected system's WSL configuration and installed Linux distributions to identify unauthorized changes or installations.
+- Remove any unauthorized or malicious scripts and binaries found within the WSL environment.
+- Restore the system from a known good backup if malicious activity has compromised system integrity.
+- Update and patch the system to ensure all software, including WSL, is up to date to mitigate known vulnerabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type : "start" and process.command_line != null and
+  process.parent.name : ("wsl.exe", "wslhost.exe") and
+  not process.executable : (
+        "?:\\Program Files (x86)\\*",
+        "?:\\Program Files\\*",
+        "?:\\Program Files*\\WindowsApps\\MicrosoftCorporationII.WindowsSubsystemForLinux_*\\wsl*.exe",
+        "?:\\Windows\\System32\\conhost.exe",
+        "?:\\Windows\\System32\\lxss\\wslhost.exe",
+        "?:\\Windows\\System32\\WerFault.exe",
+        "?:\\Windows\\System32\\wsl.exe",
+        "?:\\Windows\\Sys?????\\wslconfig.exe"
+  ) and
+  not (
+    /* Crowdstrike specific exclusion as it uses NT Object paths */
+    (event.dataset == "crowdstrike.fdr" or event.action == "ProcessRollup2") and
+      process.executable : (
+        "\\Device\\HarddiskVolume*\\Program Files (x86)\\*",
+        "\\Device\\HarddiskVolume*\\Program Files\\*",
+        "\\Device\\HarddiskVolume*\\Program Files*\\WindowsApps\\MicrosoftCorporationII.WindowsSubsystemForLinux_*\\wsl*.exe",
+        "\\Device\\HarddiskVolume*\\Windows\\System32\\conhost.exe",
+        "\\Device\\HarddiskVolume*\\Windows\\System32\\lxss\\wslhost.exe",
+        "\\Device\\HarddiskVolume*\\Windows\\System32\\WerFault.exe",
+        "\\Device\\HarddiskVolume*\\Windows\\System32\\wsl.exe",
+        "\\Device\\HarddiskVolume*\\Windows\\Sys?????\\wslconfig.exe"
+      )
+  ) and
+  not (
+    (process.name : "cmd.exe" and process.command_line : "*echo*%USERPROFILE%*") or
+    (process.name : "git.exe" and process.command_line : "git.exe -c log.*") or
+    (process.name : "powershell.exe" and process.command_line : "powershell.exe -Command $env:USERPROFILE") or
+    (process.name : "Code.exe" and process.command_line : ("*cli.js --folder-uri=vscode-remote://wsl*", "ms-vscode-remote.remote-wsl"))
+  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Indirect Command Execution
+** ID: T1202
+** Reference URL: https://attack.mitre.org/techniques/T1202/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-fortigate-socks-traffic-from-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-fortigate-socks-traffic-from-an-unusual-process.asciidoc
new file mode 100644
index 0000000000..1a096cb1d8
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-fortigate-socks-traffic-from-an-unusual-process.asciidoc
@@ -0,0 +1,111 @@
+[[prebuilt-rule-8-19-16-fortigate-socks-traffic-from-an-unusual-process]]
+=== FortiGate SOCKS Traffic from an Unusual Process
+
+This detection correlates FortiGate's application control SOCKS events with Elastic Defend network event to identify the source process performing SOCKS traffic. Adversaries may use a connection proxy to direct network traffic between systems or act as an intermediary for network communications to a command and control server to avoid direct connections to their infrastructure.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.network-*
+* logs-fortinet_fortigate.log-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1090/
+* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate
+* https://www.elastic.co/docs/reference/integrations/endpoint
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* OS: Windows
+* OS: macOS
+* Use Case: Threat Detection
+* Tactic: Command and Control
+* Data Source: Elastic Defend
+* Data Source: Fortinet
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating FortiGate SOCKS Traffic from an Unusual Process*
+
+
+
+*Possible investigation steps*
+
+
+- Review the process details like command_line, privileges, global relevance and reputation.
+- Review the parent process execution details like command_line, global relevance and reputation.
+- Examine all network connection details performed by the process during last 48h.
+- Examine all localhost network connections performed by the same process to verify if there is any port forwarding with another process on the same machine.
+- Correlate the alert with other security events or logs to identify any patterns or additional indicators of compromise related to the same process or network activity.
+
+
+*False positive analysis*
+
+
+- Browser proxy extensions and Add-ons.
+- Development and deployment tools.
+- Third party trusted tools using SOCKS for network communication.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the suspicious processes and all associated children and parents.
+- Conduct a thorough review of the system's configuration files to identify unauthorized changes.
+- Reset credentials for any accounts associated with the source machine.
+- Implement network-level controls to block traffic via SOCKS unless authorized.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by source.port, source.ip, destination.ip with maxspan=1m
+ [network where event.dataset == "fortinet_fortigate.log" and event.action == "signature" and network.application in ("SOCKS4", "SOCKS5")]
+ [network where event.module == "endpoint" and event.action in ("disconnect_received", "connection_attempted")]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Command and Control
+** ID: TA0011
+** Reference URL: https://attack.mitre.org/tactics/TA0011/
+* Technique:
+** Name: Proxy
+** ID: T1090
+** Reference URL: https://attack.mitre.org/techniques/T1090/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc
new file mode 100644
index 0000000000..54b3761250
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc
@@ -0,0 +1,104 @@
+[[prebuilt-rule-8-19-16-fortigate-ssl-vpn-login-followed-by-siem-alert-by-user]]
+=== FortiGate SSL VPN Login Followed by SIEM Alert by User
+
+Detects when a FortiGate SSL VPN login event is followed by any SIEM detection alert for the same user name within a short time window. This correlation can indicate abuse of VPN access for malicious activity, credential compromise used from a VPN session, or initial access via VPN followed by post-compromise behavior.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-fortinet_fortigate.log-*
+* .alerts-security.*
+
+*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/tactics/TA0001/
+* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Tactic: Initial Access
+* Data Source: Fortinet
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating FortiGate SSL VPN Login Followed by SIEM Alert by User*
+
+
+This rule correlates a FortiGate SSL VPN login with a subsequent security alert for the same user name, highlighting possible abuse of VPN access or activity shortly after remote access.
+
+
+*Possible investigation steps*
+
+
+- Review the FortiGate login event (source IP, user, time) and the SIEM alert(s) that followed for the same user.
+- Determine whether the user is expected to use VPN and whether the subsequent alert is related to legitimate work (e.g. admin tools, updates).
+- Check for other alerts or logins for the same user in the same time window to assess scope.
+- Correlate with authentication logs to identify impossible travel or credential reuse from the VPN session.
+
+
+*False positive analysis*
+
+
+- Legitimate VPN users triggering detections (e.g. scripted tasks, admin tooling) after login.
+- Security scans or automated jobs that run in the context of a VPN-authenticated user.
+
+
+*Response and remediation*
+
+
+- If abuse or compromise is suspected, disable or reset the user’s VPN access and credentials.
+- Investigate the host and process associated with the SIEM alert.
+- Escalate to the security or incident response team if the alert indicates malicious activity.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by user.name with maxspan=10m
+ [authentication where event.dataset == "fortinet_fortigate.log" and event.action == "login" and event.code in ("0101039426", "0101039427")]
+ [any where event.kind == "signal" and kibana.alert.rule.name != null and event.dataset != "fortinet_fortigate.log" and
+  kibana.alert.risk_score > 21 and kibana.alert.rule.rule_id != "a7f2c1b4-5d8e-4f3a-9b0c-2e1d4a6b8f3e" and user.name != null]
+
+----------------------------------
+
+*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-16/prebuilt-rule-8-19-16-high-mean-of-process-arguments-in-an-rdp-session.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-high-mean-of-process-arguments-in-an-rdp-session.asciidoc
new file mode 100644
index 0000000000..7594e151dc
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-high-mean-of-process-arguments-in-an-rdp-session.asciidoc
@@ -0,0 +1,138 @@
+[[prebuilt-rule-8-19-16-high-mean-of-process-arguments-in-an-rdp-session]]
+=== High Mean of Process Arguments in an RDP Session
+
+A machine learning job has detected unusually high number of process arguments in an RDP session. Executing sophisticated attacks such as lateral movement can involve the use of complex commands, obfuscation mechanisms, redirection and piping, which in turn increases the number of arguments in a command.
+
+*Rule type*: machine_learning
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 15m
+
+*Searches indices from*: now-12h ({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/security/current/prebuilt-ml-jobs.html
+* https://docs.elastic.co/en/integrations/lmd
+* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration
+* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security
+
+*Tags*: 
+
+* Use Case: Lateral Movement Detection
+* Rule Type: ML
+* Rule Type: Machine Learning
+* Tactic: Lateral Movement
+* Resources: Investigation Guide
+
+*Version*: 8
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating High Mean of Process Arguments in an RDP Session*
+
+
+Remote Desktop Protocol (RDP) facilitates remote access to systems, often targeted by adversaries for lateral movement. Attackers may exploit RDP by executing complex commands with numerous arguments to obfuscate their actions. The detection rule leverages machine learning to identify anomalies in process arguments, flagging potential misuse indicative of sophisticated attacks.
+
+
+*Possible investigation steps*
+
+
+- Review the specific RDP session details, including the source and destination IP addresses, to identify any unusual or unauthorized access patterns.
+- Analyze the process arguments flagged by the machine learning model to determine if they include known malicious commands or patterns indicative of obfuscation or redirection.
+- Check the user account associated with the RDP session for any signs of compromise, such as recent password changes or login attempts from unusual locations.
+- Correlate the alert with other security events or logs, such as firewall logs or intrusion detection system alerts, to identify any related suspicious activities or lateral movement attempts.
+- Investigate the historical behavior of the involved systems and users to determine if the high number of process arguments is an anomaly or part of a regular pattern.
+
+
+*False positive analysis*
+
+
+- Routine administrative tasks may generate a high number of process arguments, such as batch scripts or automated maintenance operations. Users can create exceptions for known scripts or processes that are regularly executed by trusted administrators.
+- Software updates or installations often involve complex commands with multiple arguments. To mitigate false positives, users should whitelist update processes from trusted vendors.
+- Monitoring and management tools that perform extensive logging or diagnostics can trigger this rule. Users should identify and exclude these tools if they are verified as non-threatening.
+- Custom applications or scripts developed in-house may use numerous arguments for configuration purposes. Users should document and exclude these applications if they are part of normal business operations.
+- Scheduled tasks that run during off-hours might appear suspicious due to their complexity. Users can adjust the rule to ignore these tasks if they are part of a regular, approved schedule.
+
+
+*Response and remediation*
+
+
+- Isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
+- Terminate any suspicious RDP sessions and associated processes that exhibit high numbers of arguments to halt ongoing malicious activities.
+- Conduct a thorough review of the affected system's event logs and process execution history to identify any unauthorized access or changes made during the RDP session.
+- Reset credentials for any accounts that were accessed during the suspicious RDP session to prevent unauthorized access using compromised credentials.
+- Apply security patches and updates to the affected system and any other systems within the network to mitigate vulnerabilities that could be exploited for similar attacks.
+- Enhance monitoring and logging for RDP sessions across the network to detect and respond to similar anomalies more quickly 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 have been compromised.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
+
+
+*Lateral Movement Detection Setup*
+
+The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Lateral Movement Detection.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+- Windows RDP process events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] integration.
+- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation].
+
+
+*The following steps should be executed to install assets associated with the Lateral Movement Detection integration:*
+
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-high-mean-of-rdp-session-duration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-high-mean-of-rdp-session-duration.asciidoc
new file mode 100644
index 0000000000..748c19e24a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-high-mean-of-rdp-session-duration.asciidoc
@@ -0,0 +1,139 @@
+[[prebuilt-rule-8-19-16-high-mean-of-rdp-session-duration]]
+=== High Mean of RDP Session Duration
+
+A machine learning job has detected unusually high mean of RDP session duration. Long RDP sessions can be used to evade detection mechanisms via session persistence, and might be used to perform tasks such as lateral movement, that might require uninterrupted access to a compromised machine.
+
+*Rule type*: machine_learning
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 15m
+
+*Searches indices from*: now-12h ({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/security/current/prebuilt-ml-jobs.html
+* https://docs.elastic.co/en/integrations/lmd
+* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration
+* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security
+
+*Tags*: 
+
+* Use Case: Lateral Movement Detection
+* Rule Type: ML
+* Rule Type: Machine Learning
+* Tactic: Lateral Movement
+* Resources: Investigation Guide
+
+*Version*: 8
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating High Mean of RDP Session Duration*
+
+
+Remote Desktop Protocol (RDP) enables remote access to systems, facilitating administrative tasks. However, adversaries exploit prolonged RDP sessions to maintain persistent access, potentially conducting lateral movements undetected. The 'High Mean of RDP Session Duration' detection rule leverages machine learning to identify anomalies in session lengths, flagging potential misuse indicative of malicious activity.
+
+
+*Possible investigation steps*
+
+
+- Review the specific RDP session details, including the start and end times, to understand the duration and identify any patterns or anomalies in session lengths.
+- Correlate the flagged RDP session with user activity logs to determine if the session aligns with expected user behavior or if it deviates from normal patterns.
+- Check for any concurrent or subsequent suspicious activities, such as file transfers or command executions, that might indicate lateral movement or data exfiltration.
+- Investigate the source and destination IP addresses involved in the RDP session to identify if they are known, trusted, or associated with any previous security incidents.
+- Analyze the user account involved in the RDP session for any signs of compromise, such as recent password changes, failed login attempts, or unusual access patterns.
+- Review any recent changes in the network or system configurations that might have affected RDP session durations or security settings.
+
+
+*False positive analysis*
+
+
+- Extended RDP sessions for legitimate administrative tasks can trigger false positives. To manage this, identify and whitelist IP addresses or user accounts associated with routine administrative activities.
+- Scheduled maintenance or software updates often require prolonged RDP sessions. Exclude these activities by setting time-based exceptions during known maintenance windows.
+- Remote support sessions from trusted third-party vendors may appear as anomalies. Create exceptions for these vendors by verifying their IP addresses and adding them to an allowlist.
+- Training sessions or demonstrations using RDP can result in longer session durations. Document and exclude these events by correlating them with scheduled training times and user accounts involved.
+- Automated scripts or processes that maintain RDP sessions for monitoring purposes can be mistaken for threats. Identify these scripts and exclude their associated user accounts or machine names from the detection rule.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious or unauthorized RDP sessions to cut off potential adversary access.
+- Conduct a thorough review of user accounts and permissions on the affected system to identify and disable any compromised accounts.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Restore the system from a known good backup if any unauthorized changes or malware are detected.
+- Monitor network traffic and logs for any signs of further exploitation attempts or related suspicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
+
+
+*Lateral Movement Detection Setup*
+
+The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Lateral Movement Detection.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+- Windows RDP process events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] integration.
+- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation].
+
+
+*The following steps should be executed to install assets associated with the Lateral Movement Detection integration:*
+
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-high-variance-in-rdp-session-duration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-high-variance-in-rdp-session-duration.asciidoc
new file mode 100644
index 0000000000..a3e5f551bb
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-high-variance-in-rdp-session-duration.asciidoc
@@ -0,0 +1,139 @@
+[[prebuilt-rule-8-19-16-high-variance-in-rdp-session-duration]]
+=== High Variance in RDP Session Duration
+
+A machine learning job has detected unusually high variance of RDP session duration. Long RDP sessions can be used to evade detection mechanisms via session persistence, and might be used to perform tasks such as lateral movement, that might require uninterrupted access to a compromised machine.
+
+*Rule type*: machine_learning
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 15m
+
+*Searches indices from*: now-12h ({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/security/current/prebuilt-ml-jobs.html
+* https://docs.elastic.co/en/integrations/lmd
+* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration
+* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security
+
+*Tags*: 
+
+* Use Case: Lateral Movement Detection
+* Rule Type: ML
+* Rule Type: Machine Learning
+* Tactic: Lateral Movement
+* Resources: Investigation Guide
+
+*Version*: 8
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating High Variance in RDP Session Duration*
+
+
+Remote Desktop Protocol (RDP) enables remote access to systems, facilitating legitimate administrative tasks. However, adversaries exploit prolonged RDP sessions to maintain persistent access, often for lateral movement within networks. The detection rule leverages machine learning to identify anomalies in session duration, flagging potential misuse by highlighting sessions with unusually high variance, which may indicate malicious activity.
+
+
+*Possible investigation steps*
+
+
+- Review the specific RDP session details, including the start and end times, to understand the duration and identify any patterns or anomalies in session length.
+- Correlate the flagged RDP session with user activity logs to determine if the session aligns with known user behavior or scheduled administrative tasks.
+- Investigate the source and destination IP addresses involved in the RDP session to identify any unusual or unauthorized access points.
+- Check for any concurrent alerts or logs indicating lateral movement or other suspicious activities originating from the same source or targeting the same destination.
+- Analyze the user account associated with the RDP session for any signs of compromise, such as recent password changes, failed login attempts, or unusual access times.
+- Review the network traffic during the RDP session for any signs of data exfiltration or communication with known malicious IP addresses.
+
+
+*False positive analysis*
+
+
+- Long RDP sessions for legitimate administrative tasks can trigger false positives. To manage this, identify and whitelist IP addresses or user accounts associated with routine administrative activities.
+- Scheduled maintenance or updates often require extended RDP sessions. Exclude these sessions by setting time-based exceptions during known maintenance windows.
+- Automated scripts or tools that require prolonged RDP access for monitoring or data collection can be mistaken for anomalies. Document and exclude these processes by recognizing their unique session patterns.
+- Remote support sessions from trusted third-party vendors may appear as high variance. Establish a list of trusted vendor IPs or accounts to prevent these from being flagged.
+- Training or demonstration sessions that involve extended RDP use should be accounted for by creating exceptions for specific user groups or departments involved in such activities.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
+- Terminate the suspicious RDP session to disrupt any ongoing unauthorized activities.
+- Conduct a thorough review of the affected system for signs of compromise, including checking for unauthorized user accounts, installed software, and changes to system configurations.
+- Reset credentials for any accounts that were accessed during the suspicious RDP session to prevent further unauthorized access.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Monitor network traffic and system logs for any signs of continued or related suspicious activity, focusing on RDP connections and lateral movement patterns.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
+
+
+*Lateral Movement Detection Setup*
+
+The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Lateral Movement Detection.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+- Windows RDP process events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] integration.
+- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation].
+
+
+*The following steps should be executed to install assets associated with the Lateral Movement Detection integration:*
+
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc
new file mode 100644
index 0000000000..0e1d43933d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc
@@ -0,0 +1,130 @@
+[[prebuilt-rule-8-19-16-kernel-instrumentation-discovery-via-kprobes-and-tracefs]]
+=== Kernel Instrumentation Discovery via kprobes and tracefs
+
+Detects common utilities accessing kprobes and tracing-related paths in debugfs/tracefs, which may indicate discovery of kernel instrumentation hooks. Adversaries can enumerate these locations to understand or prepare for eBPF, kprobe, or tracepoint-based activity. This behavior can also be benign during troubleshooting, performance analysis, or observability tooling validation.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* auditbeat-*
+* endgame-*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+* logs-sentinel_one_cloud_funnel.*
+* logs-crowdstrike.fdr*
+
+*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: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Discovery
+* Tactic: Defense Evasion
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Auditd Manager
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Kernel Instrumentation Discovery via kprobes and tracefs*
+
+
+This rule detects common Linux utilities and shells reading kprobes and tracing locations under debugfs/tracefs, signaling discovery of kernel instrumentation hooks. Attackers use this to understand which kprobe/tracepoint interfaces are available or already in use before deploying eBPF-based collection or stealthy monitoring. A typical pattern is a script that iterates tracing directories and reads kprobe and tracepoint listings to map callable probes and active tracing state.
+
+
+*Possible investigation steps*
+
+
+- Review the full command line and the specific tracefs/debugfs paths accessed to determine whether this was benign directory enumeration or targeted inspection of sensitive files like `available_filter_functions`, `kprobe_events`, `set_ftrace_filter`, or `trace_pipe`.  
+- Identify the initiating user and process tree, then search nearby activity for follow-on steps such as writing to `kprobe_events`/`uprobe_events`, enabling tracing events, or sustained reads from `trace_pipe`.  
+- Validate whether `debugfs`/`tracefs` are mounted and assess the host’s role and installed observability/performance tooling to quickly separate routine diagnostics from unexpected tracing access.  
+- Hunt for adjacent signals of kernel instrumentation setup or abuse, including use of eBPF tooling (`bpftool`, `bpftrace`, BCC), `perf`, suspicious `bpf()` syscall activity, or module loading around the same time window.  
+- Compare current tracing configuration and recent file modification activity under `/sys/kernel/debug/tracing` and `/sys/kernel/tracing` against baseline expectations to detect tampering or persistence.
+
+
+*False positive analysis*
+
+
+- A system administrator or automated diagnostic script may use basic utilities like `cat`, `grep`, or `find` to enumerate `/sys/kernel/debug/tracing` or `/sys/kernel/tracing` during kernel troubleshooting or performance triage to confirm tracefs/debugfs is mounted and to review available functions/events.
+- Routine validation of tracing configuration after kernel upgrades or configuration changes can involve shells running `ls`, `stat`, or `readlink` over kprobe and tracing paths to verify current settings and permissions, even when no malicious instrumentation is intended.
+
+
+*Response and remediation*
+
+
+- Contain suspected abuse by isolating the host and immediately stopping the offending script/process tree that is enumerating `/sys/kernel/debug/kprobes/*` or `/sys/kernel/*tracing/*`, then preserve the shell history and the script/binary on disk for analysis.  
+- Eradicate kernel instrumentation changes by checking for and removing any attacker-added entries in `kprobe_events`/`uprobe_events`, disabling any enabled tracing knobs, and remounting or unmounting `debugfs`/`tracefs` if they are not required for operations.  
+- Recover to a known-good state by rebooting to clear transient tracing state, validating that `trace_pipe` is not being read continuously, and confirming that expected observability tooling (if any) still functions after tracing is reset.  
+- Escalate to incident response immediately if you observe writes to `kprobe_events`/`uprobe_events`, sustained reads from `trace_pipe`, or nearby execution of eBPF/performance tooling (e.g., `bpftool`, `bpftrace`, `perf`) by an unexpected user or from an unusual parent process.  
+- Harden to prevent recurrence by restricting access to `debugfs`/`tracefs` to administrators only, disabling unprivileged BPF where feasible, and enforcing MAC policies (SELinux/AppArmor) to deny non-approved processes from reading or writing tracing interfaces.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and
+event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+process.name in (
+  "cat", "grep", "head", "tail", "ls",
+  "less", "more",
+  "awk", "sed", "cut", "tr", "xargs", "tee",
+  "find", "stat", "readlink",
+  "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox"
+) and
+process.args like ("/sys/kernel/debug/kprobes/*", "/sys/kernel/debug/tracing/*", "/sys/kernel/tracing/*")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Discovery
+** ID: TA0007
+** Reference URL: https://attack.mitre.org/tactics/TA0007/
+* Technique:
+** Name: System Information Discovery
+** ID: T1082
+** Reference URL: https://attack.mitre.org/techniques/T1082/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Rootkit
+** ID: T1014
+** Reference URL: https://attack.mitre.org/techniques/T1014/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-kernel-module-load-from-unusual-location.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-kernel-module-load-from-unusual-location.asciidoc
new file mode 100644
index 0000000000..7005fdefaf
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-kernel-module-load-from-unusual-location.asciidoc
@@ -0,0 +1,179 @@
+[[prebuilt-rule-8-19-16-kernel-module-load-from-unusual-location]]
+=== Kernel Module Load from Unusual Location
+
+This rule detects the loading of a kernel module from an unusual location. Threat actors may use this technique to maintain persistence on a system by loading a kernel module into the kernel namespace. This behavior is strongly related to the presence of a rootkit on the system.
+
+*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://decoded.avast.io/davidalvarez/linux-threat-hunting-syslogk-a-kernel-rootkit-found-under-development-in-the-wild/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Defense Evasion
+* Threat: Rootkit
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Kernel Module Load from Unusual Location*
+
+
+This rule detects attempts to load Linux kernel modules from atypical directories, which can indicate an attacker trying to run code in kernel space for stealth and long-term persistence. Adversaries often drop a malicious `.ko` into writable paths like `/tmp` or `/dev/shm` after initial access, then use `insmod` or `modprobe` to insert it and hide processes, files, or network activity as a rootkit.
+
+
+*Possible investigation steps*
+
+
+- Capture the full command line and resolve any referenced `.ko` path, then collect the module file for hashing and static analysis to determine provenance and known-malware matches.  
+- Confirm whether the module is currently loaded by querying `lsmod`/`/proc/modules`, then map it to its on-disk location with `modinfo -n <module>` (or `/sys/module/<module>/sections/*`) to validate it was loaded from the suspicious directory.  
+- Review recent kernel and audit telemetry (`dmesg`, `/var/log/kern.log`, `journalctl -k`, and any audit records) around the event time for insertion messages, signature/taint indicators, and any follow-on errors suggesting tampering.  
+- Identify the initiating user/session and execution chain (parent process tree, TTY/SSH source, container context), then determine whether the action aligns with legitimate admin activity or coincides with other compromise signals on the host.  
+- Hunt for persistence and repeatability by checking for recurring module-load attempts and inspecting boot-time and scheduled execution paths (systemd units, init scripts, cron, rc.local) that could reload the module after reboot.
+
+
+*False positive analysis*
+
+
+- A system administrator or automated maintenance workflow may build or test an out-of-tree kernel module and load it with `insmod`/`modprobe` from a staging directory such as `/tmp`, `/root`, or `/mnt` before installing it into standard module paths.  
+- A legitimate bootstrapping or recovery operation may load a required driver module from nonstandard media or temporary runtime locations (e.g., `/boot`, `/run`, `/var/run`, or `/mnt`) during troubleshooting, initramfs/early-boot tasks, or mounting encrypted/storage devices.
+
+
+*Response and remediation*
+
+
+- Isolate the affected Linux host from the network and disable external access (e.g., revoke SSH keys or block inbound SSH) to prevent additional module loads or lateral movement while preserving evidence.  
+- If the suspicious module is currently loaded, record `lsmod` and `modinfo` output, then unload it where safe (`modprobe -r <name>`/`rmmod <name>`) and quarantine the corresponding `.ko` from the unusual path (e.g., `/tmp`, `/dev/shm`, `/home`, `/mnt`) for hashing and malware analysis.  
+- Remove persistence mechanisms that would reload the module by deleting or disabling any related systemd units, init scripts, cron entries, and boot-time hooks, and validate `/etc/modules-load.d/`, `/lib/modules/$(uname -r)/`, and `depmod` outputs for unauthorized additions.  
+- Recover the host by restoring known-good kernel/module packages and rebuilding the initramfs, then reboot and verify no unexpected modules remain in `/proc/modules` and no new load attempts occur from writable directories.  
+- Escalate immediately to IR/forensics and consider full host rebuild if the module is unsigned/unknown, the kernel is tainted, module removal fails, or post-reboot evidence indicates stealth behavior consistent with a rootkit.  
+- Harden by restricting module loading (enable Secure Boot/module signature enforcement where supported, set `kernel.modules_disabled=1` after boot on fixed-function systems, and limit `CAP_SYS_MODULE` to trusted admins), and enforce file integrity monitoring/permissions to prevent `.ko` creation in world-writable locations.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from Elastic Defend.
+
+
+*Elastic Defend Integration Setup*
+
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+
+
+*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide].
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide].
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
+  (process.name == "kmod" and process.args == "insmod" and process.args like~ "*.ko*") or
+  (process.name == "kmod" and process.args == "modprobe" and not process.args in ("-r", "--remove")) or
+  (process.name == "insmod" and process.args like~ "*.ko*") or
+  (process.name == "modprobe" and not process.args in ("-r", "--remove"))
+) and (
+  process.working_directory like (
+    "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "/home/*/*", "/root/*",
+    "/var/www/*", "/boot/*", "/srv/*", "/mnt/*"
+  ) or
+  process.parent.working_directory like (
+    "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "/home/*/*", "/root/*",
+    "/var/www/*", "/boot/*", "/srv/*", "/mnt/*"
+  ) or
+  process.args like (
+    "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "/home/*/*", "/root/*",
+    "/var/www/*", "/boot/*", "/srv/*", "/mnt/*", "./*"
+  )
+) and
+not (
+  process.parent.executable == "/usr/bin/podman" or
+  process.working_directory like "/tmp/newroot"
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Boot or Logon Autostart Execution
+** ID: T1547
+** Reference URL: https://attack.mitre.org/techniques/T1547/
+* Sub-technique:
+** Name: Kernel Modules and Extensions
+** ID: T1547.006
+** Reference URL: https://attack.mitre.org/techniques/T1547/006/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Rootkit
+** ID: T1014
+** Reference URL: https://attack.mitre.org/techniques/T1014/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-kernel-module-load-via-built-in-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-kernel-module-load-via-built-in-utility.asciidoc
new file mode 100644
index 0000000000..fcda2ffcd8
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-kernel-module-load-via-built-in-utility.asciidoc
@@ -0,0 +1,226 @@
+[[prebuilt-rule-8-19-16-kernel-module-load-via-built-in-utility]]
+=== Kernel Module Load via Built-in Utility
+
+Detects the use of the insmod binary to load a Linux kernel object file. Threat actors can use this binary, given they have root privileges, to load a rootkit on a system providing them with complete control and the ability to hide from security products. Manually loading a kernel module in this manner should not be at all common and can indicate suspicious or malicious behavior.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* auditbeat-*
+* endgame-*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+* logs-sentinel_one_cloud_funnel.*
+* logs-crowdstrike.fdr*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://decoded.avast.io/davidalvarez/linux-threat-hunting-syslogk-a-kernel-rootkit-found-under-development-in-the-wild/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Defense Evasion
+* Threat: Rootkit
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Auditd Manager
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 216
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kernel Module Load via Built-in Utility*
+
+
+Threat actors with root privileges may abuse pre-installed binaries to load loadable kernel modules (LKMs), which are object files that extend the functionality of the kernel. 
+
+Threat actors can abuse this utility to load rootkits, granting them full control over the system and the ability to evade security products.
+
+The detection rule 'Kernel Module Load via Built-in Utility' is designed to identify instances where these binaries are used to load a kernel object file (with a .ko extension) on a Linux system. This activity is uncommon and may indicate suspicious or malicious behavior.
+
+> **Note**:
+> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
+> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run.
+
+
+*Possible investigation steps*
+
+
+- Investigate the kernel object file that was loaded.
+  - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}}
+- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations.
+  - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}}
+- Investigate the kernel ring buffer for any warnings or messages, such as tainted or out-of-tree kernel module loads through `dmesg`.
+- Investigate syslog for any unusual segfaults or other messages. Rootkits may be installed on targets with different architecture as expected, and could potentially cause segmentation faults. 
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.
+- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. 
+  - If scripts or executables were dropped, retrieve the files and determine if they are malicious:
+    - Use a private sandboxed malware analysis system to perform analysis.
+      - Observe and collect information about the following activities:
+        - Attempts to contact external domains and addresses.
+          - Check if the domain is newly registered or unexpected.
+          - Check the reputation of the domain or IP address.
+        - File access, modification, and creation activities.
+- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes.
+  - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration.
+    - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}}
+    - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}}
+  - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action.
+    - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}}
+- Investigate whether the user is currently logged in and active.
+    - $osquery_6
+
+
+*False positive analysis*
+
+
+- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions.
+- If this activity is related to a system administrator who uses cron jobs for administrative purposes, consider adding exceptions for this specific administrator user account. 
+- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.
+
+
+*Related Rules*
+
+
+- Kernel Driver Load - 3e12a439-d002-4944-bc42-171c0dcb9b96
+- Tainted Out-Of-Tree Kernel Module Load - 51a09737-80f7-4551-a3be-dac8ef5d181a
+- Tainted Kernel Module Load - 05cad2fb-200c-407f-b472-02ea8c9e5e4a
+- Attempt to Clear Kernel Ring Buffer - 2724808c-ba5d-48b2-86d2-0002103df753
+- Enumeration of Kernel Modules via Proc - 80084fa9-8677-4453-8680-b891d3c0c778
+- Suspicious Modprobe File Event - 40ddbcc8-6561-44d9-afc8-eefdbfe0cccd
+- Kernel Module Removal - cd66a5af-e34b-4bb0-8931-57d0a043f2ef
+- Enumeration of Kernel Modules - 2d8043ed-5bda-4caf-801c-c1feb7410504
+
+
+*Response and Remediation*
+
+
+- Initiate the incident response process based on the outcome of the triage.
+- Isolate the involved host to prevent further post-compromise behavior.
+- If the triage identified malware, search the environment for additional compromised hosts.
+  - Implement temporary network rules, procedures, and segmentation to contain the malware.
+  - Stop suspicious processes.
+  - Immediately block the identified indicators of compromise (IoCs).
+  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from Elastic Defend.
+
+
+*Elastic Defend Integration Setup*
+
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+
+
+*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide].
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide].
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and
+event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and (
+  (process.name == "kmod" and process.args == "insmod" and process.args like~ "*.ko*") or
+  (process.name == "kmod" and process.args == "modprobe" and not process.args in ("-r", "--remove")) or
+  (process.name == "insmod" and process.args like~ "*.ko*") or
+  (process.name == "modprobe" and not process.args in ("-r", "--remove"))
+) and
+not (
+  ?process.parent.executable like ("/opt/ds_agent/*", "/opt/TrendMicro/vls_agent/*", "/opt/intel/oneapi/*") or
+  ?process.working_directory in ("/opt/vinchin/agent", "/var/opt/ds_agent/am", "/opt/ds_agent", "/var/opt/TrendMicro/vls_agent/am") or
+  ?process.parent.executable in (
+    "/usr/lib/uptrack/ksplice-apply", "/opt/commvault/commvault/Base/linux_drv", "/opt/cisco/amp/bin/cisco-amp-helper",
+    "/usr/bin/kcarectl", "/usr/share/ksplice/ksplice-apply", "/opt/commvault/Base/linux_drv", "/usr/sbin/veeamsnap-loader",
+    "/bin/falcoctl"
+  ) or
+  (?process.parent.name like ("python*", "platform-python*") and ?process.parent.args in ("--smart-update", "--auto-update"))
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Boot or Logon Autostart Execution
+** ID: T1547
+** Reference URL: https://attack.mitre.org/techniques/T1547/
+* Sub-technique:
+** Name: Kernel Modules and Extensions
+** ID: T1547.006
+** Reference URL: https://attack.mitre.org/techniques/T1547/006/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Rootkit
+** ID: T1014
+** Reference URL: https://attack.mitre.org/techniques/T1014/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-lateral-movement-alerts-from-a-newly-observed-source-address.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-lateral-movement-alerts-from-a-newly-observed-source-address.asciidoc
new file mode 100644
index 0000000000..7b50d44fd4
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-lateral-movement-alerts-from-a-newly-observed-source-address.asciidoc
@@ -0,0 +1,142 @@
+[[prebuilt-rule-8-19-16-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.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 10m
+
+*Searches indices from*: now-7200m ({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/solutions/security/detect-and-alert/about-detection-rules
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Tactic: Lateral Movement
+* Resources: Investigation Guide
+
+*Version*: 3
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Lateral Movement Alerts from a Newly Observed Source Address*
+
+
+This rule surfaces newly observed, low-frequency source address triggering multiple lateral movement alerts.
+
+Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine
+whether it represents a true compromise or rare benign activity.
+
+
+*Investigation Steps*
+
+
+- Identify the source address, affected host, user and review the associated rule name to understand the behavior that triggered the alert.
+- Validate the source address and user context under which the activity occurred and assess whether it aligns with normal behavior for that address.
+- Refer to the specific rule investigation guide for further actions.
+
+
+*False Positive Considerations*
+
+
+- Administrative scripts or automation tools can trigger behavior-based detections when first introduced.
+- Security tooling, IT management agents, or EDR integrations may generate new behavior alerts during updates or configuration changes.
+- Development or testing environments may produce one-off behaviors that resemble malicious techniques.
+
+
+*Response and Remediation*
+
+
+- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement.
+- Terminate malicious processes and remove any dropped files or persistence mechanisms.
+- Collect forensic artifacts to understand initial access and execution flow.
+- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior.
+- If benign, document the finding and consider tuning or exception handling to reduce future noise.
+- Continue monitoring the host and environment for recurrence of the behavior or related alerts.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM .alerts-security.* METADATA _index
+
+// Lateral Movement related rules with fields of interest
+| where kibana.alert.rule.threat.tactic.name is not null and
+        source.ip IS NOT NULL and destination.ip is not null and
+        host.id is not null and KQL("""kibana.alert.rule.threat.tactic.name : "Lateral Movement" and not kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
+
+// aggregate stats by source.ip
+| stats  Esql.first_time_seen = MIN(@timestamp),
+         Esql.alerts_count = count(*),
+         Esql.unique_rules_count = COUNT_DISTINCT(kibana.alert.rule.name),
+         Esql.unique_count_host_id = COUNT_DISTINCT(host.id),
+         Esql.rule_name_values = VALUES(kibana.alert.rule.name),
+         Esql.user_name_values = VALUES(user.name),
+         Esql.host_id_values = VALUES(host.id),
+         Esql.host_ip_values = VALUES(host.ip),
+         Esql.tactic_name_values = VALUES(kibana.alert.rule.threat.tactic.name) by source.ip
+
+// values we will need for next filter
+| eval isLocal = locate(MV_CONCAT(to_string(Esql.host_ip_values), ","), to_string(source.ip)),
+       Esql.date_diff = DATE_DIFF("minute", Esql.first_time_seen, now())
+
+// at least 2 unique rules from same source.ip and that was first seen in last 5 days
+| where Esql.unique_rules_count >= 2 and
+        // matches are within 10m of the rule execution time to avoid alert duplicates
+        Esql.date_diff <= 10 and
+        // make sure source.ip is not equal to host.ip
+        not isLocal > 0 and
+        // reduce noise from SCCM, Nessus and alike
+        Esql.unique_count_host_id <= 3 and Esql.alerts_count <= 20
+| eval host.id = MV_FIRST(Esql.host_id_values), user.name = MV_FIRST(Esql.user_name_values)
+| KEEP Esql.*, source.ip, host.id, user.name
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Lateral Movement
+** ID: TA0008
+** Reference URL: https://attack.mitre.org/tactics/TA0008/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-lateral-movement-alerts-from-a-newly-observed-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-lateral-movement-alerts-from-a-newly-observed-user.asciidoc
new file mode 100644
index 0000000000..5f023b371f
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-lateral-movement-alerts-from-a-newly-observed-user.asciidoc
@@ -0,0 +1,124 @@
+[[prebuilt-rule-8-19-16-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.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 9m
+
+*Searches indices from*: now-7200m ({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/solutions/security/detect-and-alert/about-detection-rules
+
+*Tags*: 
+
+* OS: Windows
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Tactic: Lateral Movement
+* Resources: Investigation Guide
+
+*Version*: 3
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Lateral Movement Alerts from a Newly Observed User*
+
+
+This rule surfaces newly observed, low-frequency source user triggering multiple lateral movement alerts.
+
+Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine
+whether it represents a true compromise or rare benign activity.
+
+
+*Investigation Steps*
+
+
+- Identify the source user, affected hosts and review the associated rule name to understand the behavior that triggered the alert.
+- Validate the source address and user context under which the activity occurred and assess whether it aligns with normal behavior for that address.
+- Refer to the specific rule investigation guide for further actions.
+
+
+*False Positive Considerations*
+
+
+- Administrative scripts or automation tools can trigger behavior-based detections when first introduced.
+- Security tooling, IT management agents, or EDR integrations may generate new behavior alerts during updates or configuration changes.
+- Development or testing environments may produce one-off behaviors that resemble malicious techniques.
+
+
+*Response and Remediation*
+
+
+- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement.
+- Terminate malicious processes and remove any dropped files or persistence mechanisms.
+- Collect forensic artifacts to understand initial access and execution flow.
+- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior.
+- If benign, document the finding and consider tuning or exception handling to reduce future noise.
+- Continue monitoring the host and environment for recurrence of the behavior or related alerts.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM .alerts-security.* METADATA _index
+
+// Lateral Movement related rules
+| where kibana.alert.rule.threat.tactic.name is not null and user.id is not null and 
+        (to_string(user.id) like "S-1-5-21*" or to_string(user.id) like "S-1-12-*") and
+        host.id is not null and KQL("""kibana.alert.rule.threat.tactic.name : "Lateral Movement" """) and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
+
+// aggregate stats by user.id
+| stats  Esql.first_time_seen = MIN(@timestamp),
+         Esql.alerts_count = count(*),
+         Esql.unique_rules_count = COUNT_DISTINCT(kibana.alert.rule.name),
+         Esql.unique_count_host_id = COUNT_DISTINCT(host.id),
+         Esql.rule_name_values = VALUES(kibana.alert.rule.name),
+         Esql.host_id_values = VALUES(host.id),
+         Esql.host_ip_values = VALUES(host.ip),
+         Esql.source_ip_values = VALUES(source.ip),
+         Esql.process_cmd_line = VALUES(process.command_line),
+         Esql.tactic_name_values = VALUES(kibana.alert.rule.threat.tactic.name) by user.id, user.name
+
+// at least 2 unique lateral movement detection rules from same user.id and that was first seen in last 5 days
+| eval Esql.date_diff = DATE_DIFF("minute", Esql.first_time_seen, now())
+| where Esql.unique_rules_count >= 2 and
+        // matches are within 10m of the rule execution time to avoid alert duplicates
+        Esql.date_diff <= 10
+| eval source.ip = MV_FIRST(Esql.source_ip_values),  host.id = MV_FIRST(Esql.host_id_values) 
+| KEEP Esql.*, user.id, user.name, host.id, source.ip
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Lateral Movement
+** ID: TA0008
+** Reference URL: https://attack.mitre.org/tactics/TA0008/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-m365-identity-unusual-sso-authentication-errors-for-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-m365-identity-unusual-sso-authentication-errors-for-user.asciidoc
new file mode 100644
index 0000000000..7677ba91a7
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-m365-identity-unusual-sso-authentication-errors-for-user.asciidoc
@@ -0,0 +1,142 @@
+[[prebuilt-rule-8-19-16-m365-identity-unusual-sso-authentication-errors-for-user]]
+=== M365 Identity Unusual SSO Authentication Errors for User
+
+Identifies the first occurrence of SSO, SAML, or federated authentication errors for a user. These errors may indicate token manipulation, SAML assertion tampering, or OAuth phishing attempts. Modern adversaries often target SSO mechanisms through token theft, SAML response manipulation, or exploiting federated authentication weaknesses rather than traditional brute force attacks.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+* filebeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://techcommunity.microsoft.com/blog/microsoft-entra-blog/understanding-and-mitigating-golden-saml-attacks/4418864
+* https://www.semperis.com/blog/meet-silver-saml/
+
+*Tags*: 
+
+* Domain: Identity
+* Data Source: Microsoft 365
+* Data Source: Microsoft 365 Audit Logs
+* Use Case: Identity and Access Audit
+* Use Case: Threat Detection
+* Tactic: Initial Access
+* Resources: Investigation Guide
+
+*Version*: 213
+
+*Rule authors*: 
+
+* Elastic
+* Austin Songer
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating M365 Identity Unusual SSO Authentication Errors for User*
+
+
+SSO, SAML, and federated authentication mechanisms are critical infrastructure for modern identity access. Adversaries increasingly
+target these systems through token manipulation, SAML response tampering, OAuth phishing, and exploitation of federated trust
+relationships rather than traditional credential brute forcing. This detection identifies when a user experiences SSO-related
+authentication errors that are unusual for their typical behavior, which may indicate an attacker attempting to abuse stolen tokens or manipulate
+authentication flows.
+
+
+*Possible investigation steps*
+
+
+- Review the specific error code(s) in the `o365.audit.ErrorNumber` field to understand the nature of the authentication failure
+  (e.g., token signature failure, SAML assertion tampering, cross-tenant token misuse). Reference Microsoft's AADSTS error codes
+  at https://login.microsoftonline.com/error?code=<ErrorNumber> for detailed descriptions.
+- Examine the source IP address and geolocation of the authentication attempt - compare against the user's typical login patterns.
+- Check for concurrent authentication activity from the same user - multiple SSO errors alongside successful logins may indicate
+  token replay or session hijacking attempts.
+- Investigate recent OAuth application consent activity for this user - OAuth phishing campaigns often precede SSO manipulation attempts.
+- Review the target application or service principal being accessed during the failed authentication to identify potential attacker objectives.
+- Analyze the user's recent mailbox activity, particularly for phishing emails with OAuth consent links or suspicious authentication requests.
+- Check for any recent changes to the user's federation settings, registered devices, or authentication methods.
+- Correlate with Entra ID risky sign-in detections and risky user alerts for the same account.
+
+
+*False positive analysis*
+
+
+- First-time SSO setup: Users configuring SSO access to a new federated application may encounter initial authentication errors.
+  Validate whether the errors occurred during expected onboarding windows.
+- Federation service outages: Widespread SSO errors affecting multiple users simultaneously often indicate infrastructure issues
+  rather than targeted attacks. Check for service health incidents in the same timeframe.
+- Certificate rotation: Federated authentication certificate renewals can temporarily cause signature validation errors. Verify
+  if the errors align with planned certificate maintenance.
+- Legitimate cross-tenant access: Users with business relationships across multiple tenants may encounter cross-tenant policy
+  errors during authorized access attempts.
+
+
+*Response and remediation*
+
+
+- If token manipulation or SAML tampering is suspected, immediately revoke all active sessions and refresh tokens for the affected user.
+- Review and audit all OAuth application consents granted by the user - remove any suspicious or unrecognized applications.
+- Enable Conditional Access policies requiring compliant devices and MFA for SSO authentication if not already enforced.
+- If cross-tenant token misuse is detected, review and restrict external collaboration settings and cross-tenant access policies.
+- For SAML assertion or signature errors, validate the integrity of federation trust certificates and metadata.
+- Investigate whether the user's credentials have been compromised - enforce password reset if credential theft is suspected.
+- Review Entra ID audit logs for unusual application registrations, service principal modifications, or federation setting changes.
+- Escalate to the security operations team if evidence suggests active token theft, SAML Golden Ticket techniques, or OAuth phishing campaigns.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:o365.audit
+    and event.provider:AzureActiveDirectory
+    and event.category:authentication
+    and o365.audit.ErrorNumber:(
+        20001 or 20012 or 20033 or 40008 or 40009 or 40015 or
+        50006 or 50008 or 50012 or 50013 or 50027 or 50048 or
+        50099 or 50132 or 75005 or 75008 or 75011 or 75016 or
+        81004 or 81009 or 81010 or 399284 or 500212 or 500213 or
+        700005 or 5000819
+    )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* Sub-technique:
+** Name: Cloud Accounts
+** ID: T1078.004
+** Reference URL: https://attack.mitre.org/techniques/T1078/004/
+* Technique:
+** Name: Phishing
+** ID: T1566
+** Reference URL: https://attack.mitre.org/techniques/T1566/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc
new file mode 100644
index 0000000000..f6f9b16f42
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc
@@ -0,0 +1,126 @@
+[[prebuilt-rule-8-19-16-multiple-alerts-in-same-att-ck-tactic-by-host]]
+=== Multiple Alerts in Same ATT&CK Tactic by Host
+
+This rule correlates multiple security alerts associated with the same ATT&CK tactic on a single host within a defined time window. By requiring alerts from multiple distinct detection rules, this detection helps identify hosts exhibiting concentrated malicious behavior, which may indicate an active intrusion or post-compromise activity. The rule is intended to assist analysts in prioritizing triage toward hosts with higher likelihood of compromise rather than signaling a single discrete event.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 30m
+
+*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* 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 Multiple Alerts in Same ATT&CK Tactic by Host*
+
+
+The detection rule identifies hosts with alerts from the same ATT&CK tactic, indicating potential compromise. Adversaries exploit system vulnerabilities, moving through different tactics like execution, defense evasion, and credential access. This rule prioritizes hosts with high-risk.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific host involved and the different techniques that triggered the alerts.
+- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
+- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
+- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
+- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
+- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
+
+
+*False positive analysis*
+
+
+- Alerts from routine administrative tasks may trigger multiple rules. Review and exclude known benign activities such as scheduled software updates or system maintenance.
+- Security tools running on the host might generate multiple alerts. Identify and exclude alerts from trusted security applications to reduce noise.
+- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
+- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
+- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.
+
+
+*Response and remediation*
+
+
+- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
+- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
+- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from .alerts-security.*  metadata _id
+
+| where kibana.alert.risk_score > 21 and
+        kibana.alert.rule.name IS NOT NULL and
+        host.id is not null and event.dataset is not null and
+
+        // excluding ML and Threat Match rules as they tend to be noisy
+        not kibana.alert.rule.type in ("threat_match", "machine_learning") and
+
+        // excluding noisy tactics like Discovery, Persistence and Lateral Movement
+        kibana.alert.rule.threat.tactic.name in ("Credential Access", "Defense Evasion", "Execution", "Command and Control") and
+
+        // excluding some noisy rules
+        not kibana.alert.rule.name in ("Agent Spoofing - Mismatched Agent ID", "Process Termination followed by Deletion") and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
+
+// extract unique counts and values by host.id and tactic name
+| stats Esql.alerts_count = COUNT(*),
+        Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
+        Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
+        Esql.event_module_values = VALUES(event.module),
+        Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name),
+        Esql.threat_technique_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.threat.technique.id),
+        Esql.threat_technique_name_values = VALUES(kibana.alert.rule.threat.technique.name),
+        Esql.process_executable_values = VALUES(process.executable),
+        Esql.process_parent_executable_values = VALUES(process.parent.executable),
+        Esql.process_command_line_values = VALUES(process.command_line),
+        Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id, kibana.alert.rule.threat.tactic.name
+
+// filter for at least 3 unique rules and exclude noisy patterns like high count of alerts or processes often associated with noisy FPs
+| where Esql.kibana_alert_rule_name_distinct_count >= 3 and Esql.process_entity_id_distinct_count <= 10 and Esql.alerts_count <= 20
+
+// fields populated in the resulting alerts
+| Keep host.id, kibana.alert.rule.threat.tactic.name, Esql.*
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-alerts-involving-a-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-alerts-involving-a-user.asciidoc
new file mode 100644
index 0000000000..c5edbfbbd0
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-alerts-involving-a-user.asciidoc
@@ -0,0 +1,121 @@
+[[prebuilt-rule-8-19-16-multiple-alerts-involving-a-user]]
+=== Multiple Alerts Involving a User
+
+This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 1h
+
+*Searches indices from*: now-4h ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+
+*Version*: 7
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Multiple Alerts Involving a User*
+
+
+In security environments, monitoring user activity is crucial as adversaries often exploit user accounts to gain unauthorized access. Attackers may trigger multiple alerts by performing suspicious actions under a compromised user account. The detection rule identifies such patterns by correlating diverse alerts linked to the same user, excluding known system accounts, thus prioritizing potential threats for analysts.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific user account involved, focusing on the user.name field to gather initial context about the user.
+- Examine the timeline and sequence of the triggered alerts to understand the pattern of activity associated with the user, noting any unusual or unexpected actions.
+- Cross-reference the user activity with known legitimate activities or scheduled tasks to rule out false positives, ensuring that the actions are not part of normal operations.
+- Investigate the source and destination IP addresses associated with the alerts to identify any suspicious or unauthorized access points.
+- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts.
+- Look into any recent login attempts or authentication failures for the user account to detect potential brute force or credential stuffing attacks.
+- Collaborate with the user or their manager to verify if the activities were authorized or if the account might be compromised.
+
+
+*False positive analysis*
+
+
+- Alerts triggered by automated system processes or scripts that mimic user behavior can be false positives. To manage these, identify and exclude known benign scripts or processes from the rule.
+- Frequent alerts from users in roles that inherently require access to multiple systems or sensitive data, such as IT administrators, may not indicate compromise. Implement role-based exceptions to reduce noise.
+- Alerts generated by legitimate software updates or maintenance activities can be mistaken for suspicious behavior. Schedule these activities during known maintenance windows and exclude them from the rule during these times.
+- Users involved in testing or development environments may trigger multiple alerts due to their work nature. Create exceptions for these environments to prevent unnecessary alerts.
+- High-volume users, such as those in customer support or sales, may naturally generate more alerts. Monitor these users separately and adjust the rule to focus on unusual patterns rather than volume alone.
+
+
+*Response and remediation*
+
+
+- Isolate the affected user account immediately to prevent further unauthorized access. Disable the account or change the password to stop any ongoing malicious activity.
+- Conduct a thorough review of the affected user's recent activities and access logs to identify any unauthorized actions or data access. This will help in understanding the scope of the compromise.
+- Remove any malicious software or unauthorized tools that may have been installed on the user's system. Use endpoint detection and response (EDR) tools to scan and clean the system.
+- Restore any altered or deleted data from backups, ensuring that the restored data is free from any malicious modifications.
+- Notify relevant stakeholders, including IT security teams and management, about the incident and the steps being taken to address it. This ensures that everyone is aware and can provide support if needed.
+- Implement additional monitoring on the affected user account and related systems to detect any further suspicious activities. This includes setting up alerts for unusual login attempts or data access patterns.
+- Review and update access controls and permissions for the affected user and similar accounts to prevent future incidents. Ensure that least privilege principles are applied.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from .alerts-security.*
+| where kibana.alert.rule.name is not null and user.id is not null and
+  // Exclude low severity alerts
+  kibana.alert.risk_score > 21 and
+  not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
+| stats
+    Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), 
+    Esql.rule_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.rule_id),
+    Esql.host_id_distinct_count = COUNT_DISTINCT(host.id),
+    Esql.risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),
+    Esql.event_dataset_distinct_count = COUNT_DISTINCT(event.dataset),
+    Esql.rule_name_values = VALUES(kibana.alert.rule.name), 
+    Esql.risk_score_values = VALUES(kibana.alert.risk_score), 
+    Esql.event_dataset_values = VALUES(event.dataset), 
+    Esql.event_module_values = VALUES(event.module), 
+    Esql.process_command_line = VALUES(process.command_line), 
+    Esql.host_id_values = VALUES(host.id), 
+    Esql.source_ip_values = VALUES(source.ip), 
+    Esql.destination_ip_values = VALUES(destination.ip) by user.id
+
+| where Esql.rule_name_distinct_count >= 4 AND Esql.rule_id_distinct_count >= 2 and
+  // Exclude known system accounts with matches in more than one host
+  not (
+    (length(TO_STRING(user.id)) <= 4 or user.id IN ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0")) and
+    (Esql.host_id_distinct_count >= 2 or Esql.host_id_distinct_count == 0)
+  )
+
+| keep user.id, Esql.*
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-alerts-on-a-host-exhibiting-cpu-spike.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-alerts-on-a-host-exhibiting-cpu-spike.asciidoc
new file mode 100644
index 0000000000..524a1ac396
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-alerts-on-a-host-exhibiting-cpu-spike.asciidoc
@@ -0,0 +1,171 @@
+[[prebuilt-rule-8-19-16-multiple-alerts-on-a-host-exhibiting-cpu-spike]]
+=== Multiple Alerts on a Host Exhibiting CPU Spike
+
+This rule correlates multiple security alerts from a host exhibiting unusually high CPU utilization within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: critical
+
+*Risk score*: 99
+
+*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*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+* Domain: Endpoint
+* Tactic: Impact
+
+*Version*: 3
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Multiple Alerts on a Host Exhibiting CPU Spike*
+
+
+This rule identifies hosts that both triggered multiple security alerts and exhibited unusually high CPU utilization on the
+within a short time window. This combination may indicate malicious execution, resource abuse, or post-compromise activity.
+
+
+*Possible investigation steps*
+
+- Review the correlated alert(s) to understand why the host was flagged by the detection alerts.
+- Examine the involved process name, command line, and SHA-256 hash to determine whether those processes are expected or known to be malicious.
+- Validate the observed CPU usage and duration to determine whether the spike is abnormal for this process and host.
+- Check for related process activity such as parent/child processes, suspicious process spawning, or privilege escalation attempts.
+- Review additional host telemetry including:
+  - Network connections initiated by the process
+  - File creation or modification events
+  - Persistence mechanisms (services, scheduled tasks, registry keys)
+- Determine whether similar activity is observed on other hosts, which may indicate a broader compromise.
+
+
+*False positive analysis*
+
+- Legitimate high-CPU processes such as software updates, backup agents, security scans, or system maintenance tasks.
+- Resource-intensive but benign applications (e.g., compilers, video encoding, data processing jobs).
+- Security tools or monitoring agents temporarily consuming high CPU.
+
+
+*Response and remediation*
+
+- If malicious activity is confirmed, isolate the affected host to prevent further impact.
+- Terminate the offending process if safe to do so.
+- Remove any identified malicious binaries or artifacts and eliminate persistence mechanisms.
+- Apply relevant patches or configuration changes to remediate the root cause.
+- Monitor the environment for recurrence of similar high-CPU processes combined with security alerts.
+- Escalate the incident if multiple hosts or indicators suggest coordinated or widespread activity.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires host CPU metrics collected via the Elastic Agent **System** integration.
+
+
+*System Metrics Integration Setup*
+
+The System integration collects host-level metrics such as CPU usage, load, memory, and process statistics and sends them to Elasticsearch using Elastic Agent.
+
+
+*Prerequisite Requirements:*
+
+- Elastic Agent managed by Fleet
+- A Fleet Server configured and reachable
+  Refer to the Fleet Server setup guide:
+  https://www.elastic.co/guide/en/fleet/current/fleet-server.html
+
+
+*The following steps should be executed in order to enable CPU metrics collection:*
+
+- Go to the Kibana home page and click **Add integrations**.
+- In the search bar, enter **System** and select the **System** integration.
+- Click **Add System**.
+- Configure an integration name and optionally add a description.
+- Under **Metrics**, ensure the following datasets are enabled:
+  - `system.cpu`
+  - `system.load` (optional but recommended)
+  - `system.process` (optional, if process-level CPU is required)
+- Review optional and advanced settings as needed.
+- Add the integration to an existing agent policy or create a new agent policy.
+- Deploy the Elastic Agent to the hosts from which CPU metrics should be collected.
+- Click **Save and Continue** to finalize the setup.
+
+
+*Validation*
+
+After deployment, verify CPU metrics ingestion by confirming the presence of documents in:
+- `metrics-system.cpu-*`
+- `metrics-system.load-*` (if enabled)
+
+For more details on the System integration and available metrics, refer to the documentation:
+https://docs.elastic.co/integrations/system
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM metrics-*, .alerts-security.*  METADATA _index
+| where not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
+| eval
+       // hosts with more than 90% total CPU use
+       cpu_metrics_host_ids = CASE(_index like ".ds-metrics-system.cpu-*" and system.cpu.total.norm.pct >= 0.9, host.id, null),
+       // hosts with high severity security alerts
+       alerts_host_ids = CASE(_index like ".internal.alerts-security.*" and kibana.alert.rule.name is not null and host.id is not null and kibana.alert.risk_score >= 73, host.id, null)
+| stats host_with_cpu_spike = COUNT_DISTINCT(cpu_metrics_host_ids),
+        host_with_alerts = COUNT_DISTINCT(alerts_host_ids),
+        Esql.max_cpu_pct = MAX(system.cpu.total.norm.pct),
+        Esql.unique_alerts_count = COUNT_DISTINCT(kibana.alert.rule.name),
+        Esql.unique_process_count = COUNT_DISTINCT(process.entity_id),
+        Esql.alerts = VALUES(kibana.alert.rule.name),
+        Esql.process_hash_sha256 = VALUES(process.hash.sha256),
+        process_path = VALUES(process.executable),
+        parent_process_path = VALUES(process.parent.executable),
+        user_name = VALUES(user.name),
+        cmdline = VALUES(process.command_line) by host.id
+// at least 3 unique high severity alerts and from a host with 90% CPU use
+| where host_with_cpu_spike > 0 and host_with_alerts > 0 and Esql.unique_alerts_count >= 3
+| eval process.hash.sha256 = MV_FIRST(Esql.process_hash_sha256),
+       process.executable = MV_FIRST(process_path),
+       process.parent.executable = MV_FIRST(parent_process_path),
+       process.command_line = MV_FIRST(cmdline),
+       user.name = MV_FIRST(user_name)
+| KEEP user.name, host.id, process.*, Esql.*
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-external-edr-alerts-by-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-external-edr-alerts-by-host.asciidoc
new file mode 100644
index 0000000000..1db0c5a046
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-external-edr-alerts-by-host.asciidoc
@@ -0,0 +1,131 @@
+[[prebuilt-rule-8-19-16-multiple-external-edr-alerts-by-host]]
+=== Multiple External EDR Alerts by Host
+
+This rule uses alert data to determine when multiple external EDR alerts involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 30m
+
+*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/elastic/detection-rules/blob/main/rules/promotions/external_alerts.toml
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+* Domain: Endpoint
+
+*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 Multiple External EDR Alerts by Host*
+
+
+Endpoint security technologies monitor and analyze activities on devices to detect malicious behavior. Adversaries exploit these systems by deploying malware that triggers specific signatures across multiple hosts, indicating a coordinated attack. The detection rule identifies such threats by analyzing alert data for specific malware signatures across several hosts, flagging potential widespread infections for prioritized investigation.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts.
+- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
+- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
+- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
+- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
+- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
+
+
+*False positive analysis*
+
+
+- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.
+- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
+- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
+- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
+- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.
+
+
+*Response and remediation*
+
+
+- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
+- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
+- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from .alerts-security.*
+| WHERE event.dataset in ("crowdstrike.alert", "crowdstrike.falcon", "sentinel_one.alert", "sentinel_one.threat", "m365_defender.alert") and
+        host.id is not null and kibana.alert.risk_score > 21 and
+        not (event.module == "crowdstrike" and (kibana.alert.rule.name like "* at *" or kibana.alert.rule.name like "* on *" or kibana.alert.rule.name == "EICARTestFileWrittenWin")) and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
+| stats Esql.alerts_count = COUNT(*),
+        Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),
+        Esql.unique_rules_count = COUNT_DISTINCT(kibana.alert.rule.name),
+        Esql.processes_count = COUNT_DISTINCT(process.executable),
+        Esql.files_count = COUNT_DISTINCT(file.path),
+        Esql.process_cmdline_count = COUNT_DISTINCT(process.command_line),
+        Esql.rule_risk_score_values = VALUES(kibana.alert.risk_score),
+        Esql.process_path_values = VALUES(process.executable),
+        Esql.file_path_values = VALUES(file.path),
+        Esql.user_name_values = VALUES(user.name),
+        Esql.process_command_line_values = VALUES(process.command_line),
+        Esql.process_parent_command_line_values = VALUES(process.parent.command_line),
+        Esql.rule_name_values = VALUES(kibana.alert.rule.name) by host.id, host.name, event.module
+| where (
+	// 3+ unique rules or processes
+  (
+    Esql.unique_rules_count >= 3 or
+    (Esql.processes_count >= 3 and Esql.rule_name_values == "External Alerts")
+  ) and
+  	// and 2+ rules of different severity, or 1 high/critical severity rule
+  (
+    Esql.rule_risk_score_distinct_count >= 2 or
+    Esql.rule_risk_score_values == 73 or
+    Esql.rule_risk_score_values == 99
+  )
+) or
+  // or 5+ unique rules from the same host for 1+ path/command_line/process
+  (Esql.unique_rules_count >= 5 and Esql.alerts_count <= 50 and
+  (Esql.files_count >= 1 or Esql.process_cmdline_count >= 1 or Esql.processes_count >= 1)
+)
+| KEEP event.module, host.id, host.name, Esql.*
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-machine-learning-alerts-by-influencer-field.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-machine-learning-alerts-by-influencer-field.asciidoc
new file mode 100644
index 0000000000..947f5fe382
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-multiple-machine-learning-alerts-by-influencer-field.asciidoc
@@ -0,0 +1,103 @@
+[[prebuilt-rule-8-19-16-multiple-machine-learning-alerts-by-influencer-field]]
+=== Multiple Machine Learning Alerts by Influencer Field
+
+This rule uses alerts data to determine when multiple unique machine learning jobs involving the same influencer field are triggered. Analysts can use this to prioritize triage and response machine learning alerts.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 30m
+
+*Searches indices from*: now-45m ({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/security/current/prebuilt-ml-jobs.html
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+* Rule Type: Machine Learning
+
+*Version*: 3
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Multiple Machine Learning Alerts by Influencer Field*
+
+
+Attackers may trigger multiple alerts by performing suspicious actions under a compromised user entity. The detection rule identifies such patterns by correlating diverse machine learning alerts linked to the same entity, excluding known system accounts, thus prioritizing potential threats for analysts.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific influencer field involved to gather initial context.
+- Examine the timeline and sequence of the triggered alerts to understand the pattern of activity associated with the influencer field, noting any unusual or unexpected actions.
+- Cross-reference the user activity with known legitimate activities or scheduled tasks to rule out false positives, ensuring that the actions are not part of normal operations.
+- Investigate the source and destination IP addresses associated with the alerts to identify any suspicious or unauthorized access points.
+- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts.
+- Look into any recent login attempts or authentication failures for the user account to detect potential brute force or credential stuffing attacks.
+- Collaborate with the user or their manager to verify if the activities were authorized or if the account might be compromised.
+
+
+*False positive analysis*
+
+
+- Alerts triggered by automated system processes or scripts that mimic user behavior can be false positives. To manage these, identify and exclude known benign scripts or processes from the rule.
+- Frequent alerts from users in roles that inherently require access to multiple systems or sensitive data, such as IT administrators, may not indicate compromise. Implement role-based exceptions to reduce noise.
+- Alerts generated by legitimate software updates or maintenance activities can be mistaken for suspicious behavior. Schedule these activities during known maintenance windows and exclude them from the rule during these times.
+- Users involved in testing or development environments may trigger multiple alerts due to their work nature. Create exceptions for these environments to prevent unnecessary alerts.
+- High-volume users, such as those in customer support or sales, may naturally generate more alerts. Monitor these users separately and adjust the rule to focus on unusual patterns rather than volume alone.
+
+
+*Response and remediation*
+
+
+- Isolate the affected user account immediately to prevent further unauthorized access. Disable the account or change the password to stop any ongoing malicious activity.
+- Conduct a thorough review of the affected user's recent activities and access logs to identify any unauthorized actions or data access. This will help in understanding the scope of the compromise.
+- Remove any malicious software or unauthorized tools that may have been installed on the user's system. Use endpoint detection and response (EDR) tools to scan and clean the system.
+- Restore any altered or deleted data from backups, ensuring that the restored data is free from any malicious modifications.
+- Notify relevant stakeholders, including IT security teams and management, about the incident and the steps being taken to address it. This ensures that everyone is aware and can provide support if needed.
+- Implement additional monitoring on the affected user account and related systems to detect any further suspicious activities. This includes setting up alerts for unusual login attempts or data access patterns.
+- Review and update access controls and permissions for the affected user and similar accounts to prevent future incidents. Ensure that least privilege principles are applied.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from .alerts-security.*
+| where kibana.alert.rule.type == "machine_learning" and
+  not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
+| stats Esql.count_distinct_job_id = COUNT_DISTINCT(job_id),
+        Esql.job_id_values = VALUES(job_id),
+        Esql.rule_name_values = VALUES(kibana.alert.rule.name),
+        Esql.influencer_field_values = VALUES(influencers.influencer_field_values),
+        Esql.influencer_field_name = VALUES(influencers.influencer_field_name) by influencers.influencer_field_values, process.name, host.name
+| where Esql.count_distinct_job_id >= 3 and not influencers.influencer_field_values in ("root", "SYSTEM")
+| KEEP influencers.influencer_field_values, process.name, host.name, Esql.*
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-newly-observed-fortigate-alert.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-newly-observed-fortigate-alert.asciidoc
new file mode 100644
index 0000000000..5502af629d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-newly-observed-fortigate-alert.asciidoc
@@ -0,0 +1,119 @@
+[[prebuilt-rule-8-19-16-newly-observed-fortigate-alert]]
+=== Newly Observed FortiGate Alert
+
+This rule detects FortiGate alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: critical
+
+*Risk score*: 99
+
+*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
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+* Domain: Network
+* Data Source: Fortinet
+
+*Version*: 3
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Newly Observed Fortigate Alert*
+
+
+This rule surfaces newly observed, low-frequency high severity FortiGate alerts within the last 5 days.
+
+Because the alert has not been seen previously, it should be prioritized for validation to determine whether it represents a true compromise or rare benign activity.
+
+
+*Investigation Steps*
+
+
+- Identify the source address, affected host and review the associated message to understand the alert.
+- Validate the source address under which the activity occurred and assess whether it aligns with normal behavior.
+- Refer to the specific alert details like event.original to get more context.
+
+
+*False Positive Considerations*
+
+
+- Vulnerability scanners and pentesting.
+- Administrative scripts or automation tools can trigger detections when first introduced.
+- Development or testing environments may produce one-off behaviors that resemble malicious techniques.
+
+
+*Response and Remediation*
+
+
+- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement.
+- Terminate malicious processes and remove any dropped files or persistence mechanisms.
+- Collect forensic artifacts to understand initial access and execution flow.
+- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior.
+- If benign, document the finding and consider tuning or exception handling to reduce future noise.
+- Continue monitoring the host and environment for recurrence of the behavior or related alerts.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM logs-fortinet_fortigate.*, filebeat-* metadata _id
+
+| WHERE event.module == "fortinet_fortigate" and event.action in ("signature", "ssl-anomaly") and
+  message is not null and event.category != "authentication" and
+  message != "Connection Failed" and not message like "Web.Client: *" and
+  not message like "Network.Service: *" and not message like "General.Interest*" and not message like "Update: *" and
+  not message like "tcp_reassembler*" and not message like "a-ipdf*" and not message like "Video*" and not message like "nbss_decode*" and
+  not message like "name_server*" and not message like "misc*" and not message like "Collaboration*" and not message like "Business*" and
+  not message like "Cloud.IT*" and not message like "Mobile*"
+
+| STATS Esql.alerts_count = count(*),
+        Esql.first_time_seen = MIN(@timestamp),
+        Esql.distinct_count_src_ip = COUNT_DISTINCT(source.ip),
+        Esql.distinct_count_dst_ip = COUNT_DISTINCT(destination.ip),
+        src_ip = VALUES(source.ip),
+        dst_ip = VALUES(destination.ip),
+        url_domain = VALUES(url.domain),
+        url_path = VALUES(url.path) by message, event.category, event.outcome
+
+// first time seen is within 10m of the rule execution time
+| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now())
+| where Esql.recent <= 10 and Esql.alerts_count <= 5 and Esql.distinct_count_src_ip <= 2 and Esql.distinct_count_dst_ip <= 2
+
+// move dynamic fields to ECS equivalent for rule exceptions
+| eval source.ip = MV_FIRST(src_ip),
+       destination.ip = MV_FIRST(dst_ip),
+       url.domain = MV_FIRST(url_domain),
+       url.path = MV_FIRST(url_path)
+
+| keep message, event.category, event.outcome, Esql.*, source.ip, destination.ip, url.domain, url.path
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-newly-observed-high-severity-detection-alert.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-newly-observed-high-severity-detection-alert.asciidoc
new file mode 100644
index 0000000000..8a99583ea2
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-newly-observed-high-severity-detection-alert.asciidoc
@@ -0,0 +1,122 @@
+[[prebuilt-rule-8-19-16-newly-observed-high-severity-detection-alert]]
+=== Newly Observed High Severity Detection Alert
+
+This rule detects Elastic SIEM high severity detection alerts that are observed for the first time in the previous 5 days of alert history. It highlights low-volume, newly observed alerts tied to a specific detection rule, analysts can use this to prioritize triage and response.
+
+*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/solutions/security/detect-and-alert/about-detection-rules
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+
+*Version*: 4
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Newly Observed High Severity Detection Alert*
+
+
+This rule surfaces newly observed, low-frequency behavior high severity alerts affecting a single agent within the current day.
+
+Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine
+whether it represents a true compromise or rare benign activity.
+
+
+*Investigation Steps*
+
+
+- Identify the affected host, user and review the associated rule name to understand the behavior that triggered the alert.
+- Validate the user context under which the activity occurred and assess whether it aligns with normal behavior for that account.
+- Refer to the specific rule investiguation guide for further actions.
+
+
+*False Positive Considerations*
+
+
+- Newly deployed or updated software may introduce behavior not previously observed on the host.
+- Administrative scripts or automation tools can trigger behavior-based detections when first introduced.
+- Security tooling, IT management agents, or EDR integrations may generate new behavior alerts during updates or configuration changes.
+- Development or testing environments may produce one-off behaviors that resemble malicious techniques.
+
+
+*Response and Remediation*
+
+
+- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement.
+- Terminate malicious processes and remove any dropped files or persistence mechanisms.
+- Collect forensic artifacts to understand initial access and execution flow.
+- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior.
+- If benign, document the finding and consider tuning or exception handling to reduce future noise.
+- Continue monitoring the host and environment for recurrence of the behavior or related alerts.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM .alerts-security.*
+| where kibana.alert.rule.name is not null and kibana.alert.risk_score >= 73  and
+  not kibana.alert.rule.type in ("threat_match", "machine_learning", "new_terms") and
+  not kibana.alert.rule.name like "Deprecated - *" and kibana.alert.rule.name != "My First Rule" and
+  // covered by 7306ce7d-5c90-4f42-aa6c-12b0dc2fe3b8
+  event.dataset != "endpoint.alerts" and
+  not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
+| STATS Esql.alerts_count = count(*),
+        Esql.first_time_seen = MIN(@timestamp),
+        Esql.last_time_seen = MAX(@timestamp),
+        Esql.process_executable = VALUES(process.executable),
+        Esql.cmd_line = VALUES(process.command_line),
+        Esql.parent_executable = VALUES(process.parent.executable),
+        Esql.file_path_values = VALUES(file.path),
+        Esql.file_path_values = VALUES(file.path),
+        Esql.dll_path_values = VALUES(dll.path),
+        Esql.user_id_values = VALUES(user.id),
+        Esql.user_name_values = VALUES(user.name),
+        Esql.agent_id_values = VALUES(agent.id),
+        Esql.host_id_values = VALUES(host.id),
+        Esql.event_module_values = VALUES(event.module),
+        Esql.source_ip_values = VALUES(source.ip), 
+        Esql.rule_name_values = VALUES(kibana.alert.rule.name),
+        Esql.agents_distinct_count = COUNT_DISTINCT(agent.id) by kibana.alert.rule.name
+// fist time seen in the last 5 days - defined in the rule schedule Additional look-back time
+| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now())
+// first time seen is within 10m of the rule execution time
+| where Esql.recent <= 10 and Esql.agents_distinct_count == 1 and Esql.alerts_count <= 10 and (Esql.last_time_seen == Esql.first_time_seen)
+
+// Move single values to their corresponding ECS fields for alerts exclusion
+| eval host.id = mv_min(Esql.host_id_values)
+
+| keep host.id, kibana.alert.rule.name, Esql.*
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-newly-observed-high-severity-suricata-alert.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-newly-observed-high-severity-suricata-alert.asciidoc
new file mode 100644
index 0000000000..0f75f03175
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-newly-observed-high-severity-suricata-alert.asciidoc
@@ -0,0 +1,118 @@
+[[prebuilt-rule-8-19-16-newly-observed-high-severity-suricata-alert]]
+=== Newly Observed High Severity Suricata Alert
+
+This rule detects Suricata high severity alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: critical
+
+*Risk score*: 99
+
+*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/suricata
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+* Domain: Network
+* Data Source: Suricata
+
+*Version*: 3
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Newly Observed High Severity Suricata Alert*
+
+
+This rule surfaces newly observed, low-frequency high severity suricata alerts within the last 5 days.
+
+Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine
+whether it represents a true compromise or rare benign activity.
+
+
+*Investigation Steps*
+
+
+- Identify the source address, affected host and review the associated rule name to understand the behavior that triggered the alert.
+- Validate the source address under which the activity occurred and assess whether it aligns with normal behavior.
+- Refer to the specific alert details like event.original to get more context.
+
+
+*False Positive Considerations*
+
+
+- Vulnerability scanners and pentesting.
+- Administrative scripts or automation tools can trigger detections when first introduced.
+- Development or testing environments may produce one-off behaviors that resemble malicious techniques.
+
+
+*Response and Remediation*
+
+
+- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement.
+- Terminate malicious processes and remove any dropped files or persistence mechanisms.
+- Collect forensic artifacts to understand initial access and execution flow.
+- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior.
+- If benign, document the finding and consider tuning or exception handling to reduce future noise.
+- Continue monitoring the host and environment for recurrence of the behavior or related alerts.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM logs-suricata.*
+
+  // high severity alerts
+| where event.module == "suricata" and event.kind == "signal" and event.severity == 1 and
+        rule.name is not null and
+        not rule.name like "SURICATA STREAM*"
+
+| STATS Esql.alerts_count = count(*),
+        Esql.first_time_seen = MIN(@timestamp),
+        Esql.distinct_count_src_ip = COUNT_DISTINCT(source.ip),
+        Esql.distinct_count_dst_ip = COUNT_DISTINCT(destination.ip),
+        src_ip_values = VALUES(source.ip),
+        dst_ip_values = VALUES(destination.ip),
+        url_dom = VALUES(url.domain),
+        url_path = VALUES(url.path) by rule.name, event.type
+
+| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now())
+  // first time seen is within 10m of the rule execution time
+| where Esql.recent <= 10 and
+// exclude high volume alerts such as vuln-scanners
+  Esql.alerts_count <= 5 and Esql.distinct_count_src_ip <= 2 and Esql.distinct_count_dst_ip <= 2
+
+// move dynamic fields to ECS quivalent for rule exceptions
+| eval source.ip = MV_FIRST(src_ip_values),
+       destination.ip = MV_FIRST(dst_ip_values),
+       url.domain = MV_FIRST(url_dom),
+       url.path = MV_FIRST(url_path)
+| keep rule.name, event.type, Esql.*, source.ip, destination.ip, url.domain, url.path
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-okta-successful-login-after-credential-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-okta-successful-login-after-credential-attack.asciidoc
new file mode 100644
index 0000000000..f417968ad4
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-okta-successful-login-after-credential-attack.asciidoc
@@ -0,0 +1,250 @@
+[[prebuilt-rule-8-19-16-okta-successful-login-after-credential-attack]]
+=== Okta Successful Login After Credential Attack
+
+Correlates Okta credential attack alerts with subsequent successful authentication for the same user account, identifying potential compromise following brute force, password spray, or credential stuffing attempts.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 30m
+
+*Searches indices from*: now-6h ({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.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta
+* https://www.okta.com/identity-101/brute-force/
+* https://developer.okta.com/docs/reference/api/system-log/
+* https://developer.okta.com/docs/reference/api/event-types/
+* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy
+* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security
+* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta
+
+*Tags*: 
+
+* Domain: Identity
+* Use Case: Identity and Access Audit
+* Use Case: Threat Detection
+* Data Source: Okta
+* Data Source: Okta System Logs
+* Tactic: Credential Access
+* Tactic: Initial Access
+* Resources: Investigation Guide
+* Rule Type: Higher-Order Rule
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Okta Successful Login After Credential Attack*
+
+
+This rule correlates credential attack alerts with subsequent successful authentication for the same user account. The correlation is user-centric, capturing IP rotation scenarios where attackers may login from a different IP after obtaining credentials.
+
+
+*Possible investigation steps*
+
+- Identify the user account and review the timeline between the attack and successful login.
+- Compare the attack source IPs versus the login source IP to identify potential IP rotation.
+- Review the original credential attack alert to understand the scope and nature of the attack.
+- Check the authentication method used and whether MFA was required and satisfied.
+- Review the session activity following the successful login for signs of account takeover.
+- Verify with the user if the login was legitimate.
+
+
+*False positive analysis*
+
+- Users experiencing legitimate login issues may trigger attack alerts before successfully authenticating.
+- Automated password reset flows where a user fails multiple times then succeeds after resetting may trigger this rule.
+- The rule correlates on user identity only, so it fires when a user is targeted and later logs in, even if from different IPs.
+
+
+*Response and remediation*
+
+- If compromise is suspected, reset the user's password and revoke all active sessions.
+- Reset MFA if the attacker may have enrolled their own device.
+- Block the source IP at the network perimeter.
+- Review the user's recent activity for signs of lateral movement or data access.
+- Check for persistence mechanisms such as new OAuth apps, API tokens, or enrolled devices.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the following:
+1. The Okta Fleet integration, Filebeat module, or similarly structured data for Okta System Logs.
+2. The correlated credential attack detection rules must be enabled (at least one):
+   - Potential Okta Credential Stuffing (Single Source) (94e734c0-2cda-11ef-84e1-f661ea17fbce)
+   - Potential Okta Password Spray (Single Source) (42bf698b-4738-445b-8231-c834ddefd8a0)
+   - Potential Okta Brute Force (Device Token Rotation) (23f18264-2d6d-11ef-9413-f661ea17fbce)
+   - Potential Okta Brute Force (Multi-Source) (5889760c-9858-4b4b-879c-e299df493295)
+   - Potential Okta Password Spray (Multi-Source) (2d3c27d5-d133-4152-8102-8d051619ec4a)
+3. Alerts from these rules must be written to the `.alerts-security.*` indices.
+
+The rule queries both alert indices and Okta log indices to correlate attack alerts with successful logins.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM .alerts-security.*, logs-okta.system-* METADATA _id, _version, _index
+// Filter for credential attack alerts OR successful Okta authentications
+| WHERE
+    (
+        // Credential attack alerts from the five correlated rules
+        kibana.alert.rule.rule_id IN (
+            "94e734c0-2cda-11ef-84e1-f661ea17fbce",  // Credential Stuffing
+            "42bf698b-4738-445b-8231-c834ddefd8a0",  // Password Spraying
+            "23f18264-2d6d-11ef-9413-f661ea17fbce",  // DT Brute Force
+            "5889760c-9858-4b4b-879c-e299df493295",  // Distributed Brute Force
+            "2d3c27d5-d133-4152-8102-8d051619ec4a"   // Distributed Spray
+        )
+    )
+    OR (
+        // Successful Okta authentication events
+        event.dataset == "okta.system"
+        AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start")
+        AND okta.outcome.result == "SUCCESS"
+        AND okta.actor.alternate_id IS NOT NULL
+    )
+// correlation - alerts may store user/IP in different fields than raw logs
+| EVAL
+    Esql.user = COALESCE(okta.actor.alternate_id, user.name, user.email),
+    Esql.source_ip = COALESCE(okta.client.ip, client.ip, source.ip)
+// Must have user identity to correlate
+| WHERE Esql.user IS NOT NULL
+// Classify events and capture timestamps/IPs by event type
+| EVAL
+    Esql.is_attack_alert = CASE(
+        kibana.alert.rule.rule_id IN (
+            "94e734c0-2cda-11ef-84e1-f661ea17fbce",
+            "42bf698b-4738-445b-8231-c834ddefd8a0",
+            "23f18264-2d6d-11ef-9413-f661ea17fbce",
+            "5889760c-9858-4b4b-879c-e299df493295",
+            "2d3c27d5-d133-4152-8102-8d051619ec4a"
+        ), 1, 0
+    ),
+    Esql.is_success_login = CASE(
+        event.dataset == "okta.system"
+        AND okta.outcome.result == "SUCCESS", 1, 0
+    ),
+    Esql.attack_ip = CASE(
+        kibana.alert.rule.rule_id IN (
+            "94e734c0-2cda-11ef-84e1-f661ea17fbce",
+            "42bf698b-4738-445b-8231-c834ddefd8a0",
+            "23f18264-2d6d-11ef-9413-f661ea17fbce",
+            "5889760c-9858-4b4b-879c-e299df493295",
+            "2d3c27d5-d133-4152-8102-8d051619ec4a"
+        ), Esql.source_ip, null
+    ),
+    Esql.login_ip = CASE(
+        event.dataset == "okta.system"
+        AND okta.outcome.result == "SUCCESS", Esql.source_ip, null
+    ),
+    Esql.attack_ts = CASE(
+        kibana.alert.rule.rule_id IN (
+            "94e734c0-2cda-11ef-84e1-f661ea17fbce",
+            "42bf698b-4738-445b-8231-c834ddefd8a0",
+            "23f18264-2d6d-11ef-9413-f661ea17fbce",
+            "5889760c-9858-4b4b-879c-e299df493295",
+            "2d3c27d5-d133-4152-8102-8d051619ec4a"
+        ), @timestamp, null
+    ),
+    Esql.login_ts = CASE(
+        event.dataset == "okta.system"
+        AND okta.outcome.result == "SUCCESS", @timestamp, null
+    )
+// Aggregate by user (catches IP rotation: spray from IP A, login from IP B)
+| STATS
+    Esql.attack_count = SUM(Esql.is_attack_alert),
+    Esql.login_count = SUM(Esql.is_success_login),
+    Esql.earliest_attack = MIN(Esql.attack_ts),
+    Esql.latest_attack = MAX(Esql.attack_ts),
+    Esql.earliest_login = MIN(Esql.login_ts),
+    Esql.latest_login = MAX(Esql.login_ts),
+    Esql.attack_source_ips = VALUES(Esql.attack_ip),
+    Esql.login_source_ips = VALUES(Esql.login_ip),
+    Esql.all_source_ips = VALUES(Esql.source_ip),
+    Esql.alert_rule_ids = VALUES(kibana.alert.rule.rule_id),
+    Esql.alert_rule_names = VALUES(kibana.alert.rule.name),
+    Esql.event_action_values = VALUES(event.action),
+    Esql.geo_country_values = VALUES(client.geo.country_name),
+    Esql.geo_city_values = VALUES(client.geo.city_name),
+    Esql.source_asn_values = VALUES(source.as.number),
+    Esql.source_asn_org_values = VALUES(source.as.organization.name),
+    Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent),
+    Esql.device_values = VALUES(okta.client.device),
+    Esql.is_proxy_values = VALUES(okta.security_context.is_proxy)
+  BY Esql.user
+// Calculate time gap between latest attack and earliest subsequent login
+| EVAL Esql.attack_to_login_minutes = DATE_DIFF("minute", Esql.latest_attack, Esql.earliest_login)
+// Correlation: attack BEFORE login + success within reasonable window (3 hours)
+| WHERE
+    Esql.attack_count > 0
+    AND Esql.login_count > 0
+    AND Esql.latest_attack < Esql.earliest_login
+    AND Esql.attack_to_login_minutes <= 180
+| SORT Esql.login_count DESC
+| KEEP Esql.*
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Brute Force
+** ID: T1110
+** Reference URL: https://attack.mitre.org/techniques/T1110/
+* Sub-technique:
+** Name: Password Guessing
+** ID: T1110.001
+** Reference URL: https://attack.mitre.org/techniques/T1110/001/
+* Sub-technique:
+** Name: Password Spraying
+** ID: T1110.003
+** Reference URL: https://attack.mitre.org/techniques/T1110/003/
+* Sub-technique:
+** Name: Credential Stuffing
+** ID: T1110.004
+** Reference URL: https://attack.mitre.org/techniques/T1110/004/
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* 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-16/prebuilt-rule-8-19-16-okta-user-assigned-administrator-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-okta-user-assigned-administrator-role.asciidoc
new file mode 100644
index 0000000000..763a296a25
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-okta-user-assigned-administrator-role.asciidoc
@@ -0,0 +1,120 @@
+[[prebuilt-rule-8-19-16-okta-user-assigned-administrator-role]]
+=== Okta User Assigned Administrator Role
+
+Identifies when an administrator role is assigned to an Okta user or group. Adversaries may assign administrator privileges to compromised accounts to establish persistence, escalate privileges, and maintain long-term access to the environment. This detection monitors for both user-level and group-level administrator privilege grants, which can be used to bypass security controls and perform unauthorized administrative actions.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-okta*
+
+*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://help.okta.com/en/prod/Content/Topics/Security/administrators-admin-comparison.htm
+* https://developer.okta.com/docs/reference/api/system-log/
+* https://developer.okta.com/docs/reference/api/event-types/
+* https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft
+* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy
+* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security
+* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta
+* https://www.elastic.co/security-labs/okta-and-lapsus-what-you-need-to-know
+
+*Tags*: 
+
+* Domain: Identity
+* Data Source: Okta
+* Data Source: Okta System Logs
+* Use Case: Identity and Access Audit
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 413
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Okta User Assigned Administrator Role*
+
+
+Okta administrator roles provide elevated permissions to manage users, applications, policies, and security settings within the Okta environment. Adversaries who compromise Okta accounts may assign administrator privileges to establish persistence and maintain control over the identity infrastructure. This rule detects when administrator roles are granted to users or groups, which can indicate privilege escalation or persistence techniques.
+
+
+*Possible investigation steps:*
+
+- Identify the actor who performed the privilege grant by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.
+- Determine the target user or group that received administrator privileges by reviewing the `okta.target` fields.
+- Review the specific administrator role granted by examining the `okta.debug_context.debug_data.flattened.privilegeGranted` field.
+- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.
+- Check if the source IP is associated with known malicious activity, VPN/proxy services, or unusual geolocations.
+- Examine the `okta.request.ip_chain` field to determine if the actor used a proxy or VPN.
+- Review the actor's recent authentication history and session activity for suspicious patterns.
+- Verify whether the privilege grant was part of a legitimate change request or administrative workflow.
+- Check for any other suspicious activities performed by the actor or target account around the same time.
+- Review audit logs for any administrative actions performed after the privilege grant.
+
+
+*False positive analysis:*
+
+- Legitimate administrators may assign roles during normal IT operations such as onboarding, role changes, or incident response.
+- Automated provisioning systems or service accounts may assign administrator roles as part of authorized workflows.
+- During organizational changes or access certification processes, multiple role assignments may occur.
+- Create exceptions for known administrators, service accounts, or specific groups that regularly perform legitimate role assignments.
+
+
+*Response and remediation:*
+
+- If the privilege grant is unauthorized, immediately revoke the administrator role from the affected user or group.
+- Reset credentials and revoke active sessions for both the actor and target accounts if compromise is suspected.
+- Enforce multi-factor authentication (MFA) re-enrollment for affected accounts.
+- Review all administrative actions performed by the target account after the privilege grant.
+- Check for other indicators of compromise such as unauthorized MFA device registrations, policy modifications, or suspicious authentication patterns.
+- Alert security leadership and identity management teams about the unauthorized privilege escalation.
+- Review and strengthen privileged access management controls, including requiring approval workflows for administrator role assignments.
+- Consider implementing anomaly detection for administrator role assignments from unusual sources or at unusual times.
+- If broader compromise is suspected, conduct a comprehensive security investigation including forensic analysis of Okta audit logs.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:okta.system
+    and event.action: (user.account.privilege.grant or group.privilege.grant)
+    and okta.debug_context.debug_data.flattened.privilegeGranted: *administrator*
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc
new file mode 100644
index 0000000000..0f62b9431b
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc
@@ -0,0 +1,169 @@
+[[prebuilt-rule-8-19-16-potential-aws-s3-bucket-ransomware-note-uploaded]]
+=== Potential AWS S3 Bucket Ransomware Note Uploaded
+
+Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the PutObject S3 API call with an object name commonly associated with ransomware notes. The keywords detected here rarely overlap with common file names and have been attributed to ransomware notes with high-confidence. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims.
+
+*Rule type*: eql
+
+*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://stratus-red-team.cloud/attack-techniques/AWS/aws.impact.s3-ransomware-batch-deletion/
+* https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/
+* https://www.mdpi.com/2073-431X/10/11/145#computers-10-00145-f002
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS S3
+* Use Case: Threat Detection
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 10
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential AWS S3 Bucket Ransomware Note Uploaded*
+
+
+This rule detects a successful `PutObject` to S3 where the object key matches common ransomware-note patterns (for example, `readme`, `decrypt`, `ransom`, and combinations with `file`). Attackers who obtain credentials or abuse overly-permissive bucket policies can upload ransom notes (often after deleting or encrypting data).
+
+
+*Possible investigation steps*
+
+
+**Confirm the actor and session details** 
+- Review `aws.cloudtrail.user_identity.*` (ARN, type, access key, session context), `source.ip`, `user.agent`, and `tls.client.server_name` to identify who performed the upload and from where. Validate whether this principal typically writes to this bucket. 
+
+**Inspect the object key and bucket context** 
+- From `aws.cloudtrail.request_parameters`, capture the exact `key` and `bucketName`. Check whether the key is publicly readable (ACL), whether the bucket is internet-exposed, and whether replication or lifecycle rules could propagate or remove related objects. 
+
+**Pivot to related S3 activity around the same time** 
+- Look for `DeleteObject`/`DeleteObjects`, mass `PutObject` spikes, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning`, and `PutBucketLifecycleConfiguration` events on the same bucket or by the same actor to determine if data destruction, policy tampering, or guard-rail changes occurred. 
+
+**Assess blast radius across the account** 
+- Search recent CloudTrail for the same actor/IP touching other buckets, KMS keys used by those buckets, and IAM changes (new access keys, policy attachments, role assumptions) that could indicate broader compromise paths consistent with ransomware playbooks. 
+
+**Check protections and recovery posture on the bucket** 
+- Verify whether S3 Versioning and (if in use) Object Lock legal hold are enabled; note prior versions available for the affected key, and whether lifecycle rules might expire them. 
+
+**Correlate with threat signals** 
+- Review other related alerts, GuardDuty S3-related findings, AWS Config drift on the bucket and its policy, and any SOAR/IR runbook executions tied to ransomware triage. 
+
+
+*False positive analysis*
+
+- Planned tests or red-team exercises
+- Benign automation naming. Some data-migration or backup tools may use “readme”/“recovery”-style filenames; validate by `user.agent`, principal, and target environment (dev vs prod). 
+
+
+
+*Response and remediation*
+
+
+**Immediate, low-risk actions (safe for most environments)**
+- **Preserve context** : Export the triggering `PutObject` CloudTrail record(s), plus 15–30 min before/after, to an evidence bucket (restricted access). 
+- **Snapshot configuration** : Record current bucket settings (Block Public Access, Versioning, Object Lock, Bucket Policy, Lifecycle rules) and any KMS keys used.
+- **Quiet the spread** : Pause destructive automation: disable/bypass lifecycle rules that would expire/delete object versions; temporarily pause data pipelines targeting the bucket.
+- **Notify owners** : Inform the bucket/application owner(s) and security leadership.
+
+**Containment options (choose the least disruptive first)**
+- **Harden exposure** : If not already enforced, enable `Block Public Access` for the bucket.
+- **Targeted deny policy (temporary)** : Add a restrictive bucket policy allowing only IR/admin roles while you scope impact. Reconfirm critical workload dependencies before applying.
+- **Credential risk reduction** : If a specific IAM user/key or role is implicated, rotate access keys; for roles, remove risky policy attachments or temporarily restrict with an SCP/deny statement.
+
+**Evidence preservation**
+- Export relevant CloudTrail events, S3 server/access logs (if enabled), AWS Config history for the bucket/policy, and the suspicious object plus its previous versions (if Versioning is enabled).
+- Document actor ARN, source IPs, user agent(s), exact `bucketName`/`key`, and timestamps. Maintain a simple chain-of-custody note for collected artifacts.
+
+**Scope and hunting (same actor/time window)**
+- Look for `DeleteObject(s)`, unusual `PutObject` volume, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning` changes, `PutBucketLifecycleConfiguration`, and cross-account access.
+- Cross reference other buckets touched by the same actor/IP; recent IAM changes (new keys, policy/role edits); GuardDuty findings tied to S3/credentials.
+
+**Recovery (prioritize data integrity)**
+- If Versioning is enabled, restore last known-good versions for impacted objects. Consider applying Object Lock legal hold to clean versions during recovery if configured.
+- If Versioning is not enabled, recover from backups (AWS Backup, replication targets). Enable Versioning going forward on critical buckets; evaluate Object Lock for high-value data.
+- Carefully remove any temporary deny policy only after credentials are rotated, policies re-validated, and no ongoing destructive activity is observed.
+
+**Post-incident hardening**
+- Enforce `Block Public Access`, enable Versioning (and MFA-Delete where appropriate), and review bucket policies for least privilege.
+- Ensure continuous CloudTrail data events for S3 are enabled in covered regions; enable/verify GuardDuty S3 protections and alerts routing.
+- Add detections for related behaviors (policy tampering, bulk deletes, versioning/lifecycle toggles) and create allowlists for known maintenance windows.
+
+
+
+*Additional information*
+
+
+- For further guidance on managing S3 bucket security and protecting against ransomware, refer to the https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html[AWS S3 documentation] and AWS best practices for security.
+- https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-Ransomware.md[AWS IRP—Ransomware] (NIST-aligned template for evidence, containment, eradication, recovery, post-incident). 
+- https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Ransom_Response_S3.md[AWS Customer Playbook—Ransom Response (S3)] (bucket-level response steps: public access blocks, temporary deny, versioning/object lock, lifecycle considerations, recovery). 
+
+
+==== Setup
+
+
+AWS S3 data types need to be enabled in the CloudTrail trail configuration to capture PutObject API calls.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+file where
+  event.dataset == "aws.cloudtrail" and
+  event.provider == "s3.amazonaws.com" and
+  event.action == "PutObject" and
+  event.outcome == "success" and
+  /* Apply regex to match patterns only after the bucket name */
+  /* common ransom note file name keywords */
+  aws.cloudtrail.resources.arn regex~ "arn:aws:s3:::[^/]+/.*?(how|decrypt|restor|help|instruct|read|get|recov|save|encrypt|info|ransom).*"
+  and not aws.cloudtrail.resources.arn regex~ ".*(AWSLogs|CloudTrail|access-logs).*"
+  and not aws.cloudtrail.user_identity.type == "AWSService"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Data Destruction
+** ID: T1485
+** Reference URL: https://attack.mitre.org/techniques/T1485/
+* Technique:
+** Name: Data Encrypted for Impact
+** ID: T1486
+** Reference URL: https://attack.mitre.org/techniques/T1486/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc
new file mode 100644
index 0000000000..2c43b51837
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc
@@ -0,0 +1,210 @@
+[[prebuilt-rule-8-19-16-potential-dynamic-iex-reconstruction-via-environment-variables]]
+=== Potential Dynamic IEX Reconstruction via Environment Variables
+
+Detects PowerShell scripts that reconstructs IEX (Invoke-Expression) by indexing environment variable strings (for example, $env:VAR[1,2,3]) or related `.name[...]` slices and joining characters at runtime. Attackers use environment-variable slicing to hide dynamic execution and evade keyword-based detections and AMSI.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: PowerShell Logs
+* Resources: Investigation Guide
+
+*Version*: 10
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Dynamic IEX Reconstruction via Environment Variables*
+
+
+This alert indicates PowerShell Script Block Logging captured a script that builds "IEX" (Invoke-Expression) at runtime by indexing characters from environment variable strings or related name properties and combining them. This technique is commonly used to obscure dynamic execution and can indicate an attempt to execute attacker-controlled content.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
+
+
+*Possible investigation steps*
+
+
+- Confirm scope and execution context:
+  - Review `host.name` and `host.id` to identify the impacted endpoint and determine whether it is a typical user workstation, server, or a special-purpose system in your environment.
+  - Review `user.name`, `user.domain`, and `user.id` to understand who executed the script and whether the account is expected to run PowerShell on this host (interactive user, service account, or administrative context).
+  - Use `agent.id` (if available) to identify the reporting agent and to support correlation with other telemetry collected from the same endpoint.
+  - Use the alert timestamp as the anchor to correlate activity immediately before and after the script block ran.
+
+- Analyze the obfuscation and intended execution:
+  - Examine `powershell.file.script_block_text` to locate environment-variable slicing patterns (for example, `$env:<var>[<idx>]`, `$env:<var>[<idx1>,<idx2>,<idx3>]`, or `.name[<idx1>,<idx2>,<idx3>]`) and identify the variable names and indices being used.
+  - Use `Esql.script_block_tmp` to quickly find the match locations, then review the surrounding context in `powershell.file.script_block_text` to determine how the reconstructed string is used (assignment, concatenation/join, or immediate invocation).
+  - Determine whether the reconstructed output is used as a dynamic execution primitive (for example, passed to `Invoke-Expression` / `IEX`, used with the call operator, or invoked via a method). Focus on what content is ultimately evaluated or executed.
+
+- Reconstruct full script content:
+  - If the script appears incomplete or staged across multiple events, use `powershell.file.script_block_id` with `powershell.sequence` and `powershell.total` to collect all fragments and rebuild the full script in order.
+  - After reconstruction, identify where string construction occurs versus where execution occurs to understand the end-to-end flow.
+
+- Assess obfuscation level and intent using available enrichments:
+  - Review `Esql.script_block_pattern_count` to understand how frequently the reconstruction pattern appears within the script block; repeated occurrences can indicate systematic obfuscation rather than an isolated string operation.
+  - Review `powershell.file.script_block_length` for size context and compare it with typical script sizes seen for the same host or user.
+  - Review `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_unique_symbols` to gauge whether the script contains encoded or highly obfuscated content (for example, large high-entropy blocks that may indicate packed or encoded data).
+
+- Identify script origin and potential spread:
+  - If `file.path` is populated, review `file.name` and `file.directory` to determine where the script was sourced from and whether the location aligns with approved administrative tooling or software distribution paths.
+  - If `file.path` is not populated, treat the activity as potentially inline or dynamically generated and prioritize identifying the initiating process or source using adjacent telemetry.
+  - Scope for other alerts or script blocks on the same `host.id` or associated with the same `user.id` that show similar reconstruction patterns, especially within the same time window.
+
+- Correlate with adjacent telemetry (as available in your environment):
+  - Using `host.id` / `host.name`, `user.id`, and the alert time, correlate with process execution data to identify the PowerShell host process and the initiating parent process or source (for example, interactive session, script runner, scheduled task, service, or another application).
+  - Correlate with network, file, registry, and authentication telemetry on the same host around the alert time to identify follow-on activity that supports malicious intent (download or retrieval of content, creation or modification of files, persistence-related changes, or suspicious logons).
+
+
+*False positive analysis*
+
+
+- Legitimate automation or administration scripts may construct command strings dynamically, including deriving short tokens from environment variables for compatibility or to reduce hard-coded strings.
+- Security testing and purple-team or red-team activity may intentionally use environment-variable slicing to emulate evasive tradecraft.
+- Developer tooling, obfuscation research, or PowerShell training content may include this technique. Benign usage is typically tied to known owners, consistent hosts, predictable execution windows, and the absence of suspicious downstream activity.
+
+
+*Response and remediation*
+
+
+- If the activity is suspected or confirmed malicious:
+  - Contain the affected host to prevent additional execution and reduce lateral movement risk.
+  - Preserve evidence by collecting the complete script content using `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`, and retain the original `powershell.file.script_block_text` for analysis.
+  - Extract and track indicators from the script content (for example, URLs, domains, IP addresses, file names, or unique strings) and scope for additional occurrences across the environment using `host.id`, `host.name`, `user.id`, and `file.path` when present.
+  - Identify and remediate the initial execution source (parent process or launching mechanism) and remove or quarantine any associated script files referenced by `file.path`.
+  - If account compromise is suspected, reset affected credentials and review for additional suspicious PowerShell activity associated with the same `user.id`.
+
+- If the activity is determined to be benign:
+  - Document the business justification, owning team, expected hosts, and expected script location (`file.path` when present).
+  - Monitor for deviations in execution context (new hosts, new users, or materially different script content) and consider targeted tuning based on stable attributes such as `file.path` and known `user.id` values.
+
+
+==== 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]
+----------------------------------
+from logs-windows.powershell_operational* metadata _id, _version, _index
+| where event.code == "4104"
+
+// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for
+| eval Esql.script_block_length = length(powershell.file.script_block_text)
+| where Esql.script_block_length > 500
+
+// replace the patterns we are looking for with the 🔥 emoji to enable counting them
+// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1
+| eval Esql.script_block_tmp = replace(
+    powershell.file.script_block_text,
+    """(?i)(\$(?:\w+|\w+\:\w+)\[\d++\]\+\$(?:\w+|\w+\:\w+)\[\d++\]\+['"]x['"]|\$(?:\w+\:\w+)\[\d++,\d++,\d++\]|\.name\[\d++,\d++,\d++\])""",
+    "🔥"
+)
+
+// count how many patterns were detected by calculating the number of 🔥 characters inserted
+| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", ""))
+
+// keep the fields relevant to the query, although this is not needed as the alert is populated using _id
+| keep
+    Esql.script_block_pattern_count,
+    Esql.script_block_length,
+    Esql.script_block_tmp,
+    powershell.file.*,
+    file.path,
+    powershell.sequence,
+    powershell.total,
+    _id,
+    _version,
+    _index,
+    host.name,
+    host.id,
+    agent.id,
+    user.id
+
+// Filter for scripts that match the pattern at least once
+| where Esql.script_block_pattern_count >= 1
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc
new file mode 100644
index 0000000000..8fadb22b9a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc
@@ -0,0 +1,164 @@
+[[prebuilt-rule-8-19-16-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option]]
+=== Potential Linux Tunneling and/or Port Forwarding via SSH Option
+
+This rule detects the use of SSH options that may indicate tunneling or port forwarding on Linux systems. This behavior is commonly associated with malicious activity, such as establishing a port forward, proxy or an encrypted tunnel to exfiltrate data.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* endgame-*
+* logs-crowdstrike.fdr*
+* logs-endpoint.events.process*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform
+* https://book.hacktricks.xyz/generic-methodologies-and-resources/tunneling-and-port-forwarding
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Command and Control
+* Data Source: Elastic Defend
+* Data Source: Elastic Endgame
+* Data Source: Crowdstrike
+* Data Source: SentinelOne
+* Resources: Investigation Guide
+
+*Version*: 4
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+ ## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Potential Linux Tunneling and/or Port Forwarding via SSH Option*
+
+
+SSH is a secure protocol used for encrypted communication over networks, often employed for remote administration. Adversaries exploit SSH options like port forwarding to create tunnels, facilitating covert data exfiltration or unauthorized access. The detection rule identifies suspicious SSH commands indicative of tunneling by monitoring specific SSH options, helping to flag potential misuse for further investigation.
+
+
+*Possible investigation steps*
+
+
+- Review the process command line details to identify the specific SSH options used, such as ProxyCommand, LocalForward, RemoteForward, DynamicForward, Tunnel, GatewayPorts, ExitOnForwardFailure, or ProxyJump, to understand the nature of the potential tunneling or port forwarding.
+- Examine the user account associated with the SSH process to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Check the source and destination IP addresses involved in the SSH connection to identify any unusual or unauthorized endpoints that may indicate malicious activity.
+- Investigate the timing and frequency of the SSH connections to assess whether they coincide with known business operations or if they suggest unauthorized access patterns.
+- Correlate the event with other security logs or alerts from the same host or network segment to identify any additional indicators of compromise or related suspicious activities.
+
+
+*False positive analysis*
+
+
+- Legitimate administrative tasks using SSH options like ProxyCommand or LocalForward can trigger the rule. To manage this, create exceptions for known administrative scripts or users frequently using these options for valid purposes.
+- Automated backup or synchronization processes that use SSH tunneling for secure data transfer may be flagged. Identify these processes and exclude them by specifying the associated process names or user accounts.
+- Development or testing environments where developers use SSH tunneling for accessing remote services might cause alerts. Implement exceptions for specific IP addresses or user groups associated with these environments.
+- Monitoring or logging tools that utilize SSH for secure data collection can be mistaken for malicious activity. Whitelist these tools by their process names or command-line patterns to prevent false positives.
+- Internal network services that rely on SSH port forwarding for legitimate communication should be reviewed and excluded based on their known behavior and usage patterns.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious SSH sessions identified by the detection rule to halt potential tunneling or port forwarding activities.
+- Conduct a thorough review of SSH configuration files and logs on the affected system to identify unauthorized changes or access patterns.
+- Reset credentials for any accounts that were used in the suspicious SSH activity to prevent further unauthorized access.
+- Implement network segmentation to limit SSH access to only necessary systems and services, reducing the risk of lateral movement.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.
+- Enhance monitoring and logging of SSH activities across the network to detect similar threats in the future, ensuring alerts are promptly reviewed and acted upon.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from Elastic Defend.
+
+
+*Elastic Defend Integration Setup*
+
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+
+
+*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide].
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide].
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
+process.name in ("ssh", "sshd") and process.args like "-o*" and
+process.command_line like~ (
+  "*ProxyCommand*", "*LocalForward*", "*RemoteForward*", "*DynamicForward*", "*Tunnel*", "*GatewayPorts*",
+  "*ExitOnForwardFailure*", "*ProxyCommand*", "*ProxyJump*"
+) and 
+not (
+  ?process.parent.args == "/usr/bin/pvedaemon" or
+  ?process.parent.command_line in ("pvedaemon", "pve-ha-lrm") or
+  ?process.working_directory like "*ansible*" or
+  process.command_line like "*ansible*"
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Command and Control
+** ID: TA0011
+** Reference URL: https://attack.mitre.org/tactics/TA0011/
+* Technique:
+** Name: Protocol Tunneling
+** ID: T1572
+** Reference URL: https://attack.mitre.org/techniques/T1572/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-linux-tunneling-and-or-port-forwarding.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-linux-tunneling-and-or-port-forwarding.asciidoc
new file mode 100644
index 0000000000..6092315d47
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-linux-tunneling-and-or-port-forwarding.asciidoc
@@ -0,0 +1,216 @@
+[[prebuilt-rule-8-19-16-potential-linux-tunneling-and-or-port-forwarding]]
+=== Potential Linux Tunneling and/or Port Forwarding
+
+This rule monitors for a set of Linux utilities that can be used for tunneling and port forwarding. Attackers can leverage tunneling and port forwarding techniques to bypass network defenses, establish hidden communication channels, and gain unauthorized access to internal resources, facilitating data exfiltration, lateral movement, and remote control.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* endgame-*
+* logs-crowdstrike.fdr*
+* logs-endpoint.events.process*
+* logs-sentinel_one_cloud_funnel.*
+* 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://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform
+* https://book.hacktricks.xyz/generic-methodologies-and-resources/tunneling-and-port-forwarding
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Command and Control
+* Data Source: Elastic Defend
+* Data Source: Elastic Endgame
+* Data Source: Crowdstrike
+* Data Source: SentinelOne
+* Data Source: Auditd Manager
+* Resources: Investigation Guide
+
+*Version*: 114
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Linux Tunneling and/or Port Forwarding*
+
+
+Attackers can leverage many utilities to clandestinely tunnel network communications and evade security measures, potentially gaining unauthorized access to sensitive systems.
+
+This rule looks for several utilities that are capable of setting up tunnel network communications by analyzing process names or command line arguments. 
+
+> **Note**:
+> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
+> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run.
+
+
+*Possible investigation steps*
+
+
+- Identify any signs of suspicious network activity or anomalies that may indicate protocol tunneling. This could include unexpected traffic patterns or unusual network behavior.
+  - Investigate listening ports and open sockets to look for potential protocol tunneling, reverse shells, or data exfiltration.
+    - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}}
+    - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}}
+- Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action.
+  - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}}
+- Investigate whether the user is currently logged in and active.
+  - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}}
+- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations.
+  - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}}
+  - !{osquery{"label":"Osquery - Retrieve Process Info","query":"SELECT name, cmdline, parent, path, uid FROM processes"}}
+- Investigate other alerts associated with the user/host during the past 48 hours.
+  - If scripts or executables were dropped, retrieve the files and determine if they are malicious:
+    - Use a private sandboxed malware analysis system to perform analysis.
+      - Observe and collect information about the following activities:
+        - Attempts to contact external domains and addresses.
+          - Check if the domain is newly registered or unexpected.
+          - Check the reputation of the domain or IP address.
+        - File access, modification, and creation activities.
+
+
+*Related rules*
+
+
+- Potential Linux Tunneling and/or Port Forwarding via Command Line - 8c8df61f-ed2a-4832-87b8-ee30812606e0
+- Potential Protocol Tunneling via Chisel Client - 3f12325a-4cc6-410b-8d4c-9fbbeb744cfd
+- Potential Protocol Tunneling via Chisel Server - ac8805f6-1e08-406c-962e-3937057fa86f
+- Potential Protocol Tunneling via EarthWorm - 9f1c4ca3-44b5-481d-ba42-32dc215a2769
+- Suspicious Utility Launched via ProxyChains - 6ace94ba-f02c-4d55-9f53-87d99b6f9af4
+- ProxyChains Activity - 4b868f1f-15ff-4ba3-8c11-d5a7a6356d37
+
+
+*False positive analysis*
+
+
+- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions.
+- If this activity is related to a system administrator or developer who uses port tunneling/forwarding for benign purposes, consider adding exceptions for specific user accounts or hosts. 
+- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.
+
+
+*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, such as reverse shells, reverse proxies, or droppers, that attackers could use to reinfect the system.
+- Remove and block malicious artifacts identified during triage.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from Elastic Defend.
+
+
+*Elastic Defend Integration Setup*
+
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+
+
+*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide].
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide].
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and (
+  (
+    // gost & pivotnacci - spawned without process.parent.name
+    (process.name == "gost" and process.args : ("-L*", "-C*", "-R*")) or (process.name == "pivotnacci")) or (
+    // ssh
+    (process.name == "ssh" and (
+      (
+        /* exact tunnel argument matching */
+        process.args in ("-R", "-L", "-D", "-w") or
+        /* single-dash token, first letter is NOT o/O, contains one of R/L/D/w/W somewhere later */
+        process.args regex "-[A-NP-Za-np-z][A-Za-z]*[RLDwW][A-Za-z]*"
+      ) and
+      process.args_count >= 4 and 
+      not (
+        process.args == "chmod" or process.command_line like "*rungencmd*"
+      )
+    )) or
+    (process.name == "ssh" and process.args == "-J") or
+    // sshuttle
+    (process.name == "sshuttle" and process.args in ("-r", "--remote", "-l", "--listen") and process.args_count >= 4) or
+    // socat
+    (process.name == "socat" and process.args : ("TCP4-LISTEN:*", "SOCKS*") and process.args_count >= 3) or
+    // chisel
+    (process.name : "chisel*" and process.args in ("client", "server")) or
+    // iodine(d), dnscat, hans, ptunnel-ng, ssf, 3proxy & ngrok 
+    (process.name in ("iodine", "iodined", "dnscat", "hans", "hans-ubuntu", "ptunnel-ng", "ssf", "3proxy", "ngrok", "wstunnel"))
+  ) and process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Command and Control
+** ID: TA0011
+** Reference URL: https://attack.mitre.org/tactics/TA0011/
+* Technique:
+** Name: Protocol Tunneling
+** ID: T1572
+** Reference URL: https://attack.mitre.org/techniques/T1572/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-malicious-powershell-based-on-alert-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-malicious-powershell-based-on-alert-correlation.asciidoc
new file mode 100644
index 0000000000..cf0a8f7797
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-malicious-powershell-based-on-alert-correlation.asciidoc
@@ -0,0 +1,170 @@
+[[prebuilt-rule-8-19-16-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*: 5
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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*
+
+
+- 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.
+
+- 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.
+
+- 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.
+
+- 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).
+
+- 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.
+
+- 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.
+
+
+*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.
+
+
+*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.
+
+
+==== 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
+
+// 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)
+  by Esql.script_block_id
+
+// Apply detection threshold
+| where Esql.kibana_alert_rule_name_count_distinct >= 5
+
+----------------------------------
+
+*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-16/prebuilt-rule-8-19-16-potential-notepad-markdown-rce-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-notepad-markdown-rce-exploitation.asciidoc
new file mode 100644
index 0000000000..4d92740185
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-notepad-markdown-rce-exploitation.asciidoc
@@ -0,0 +1,117 @@
+[[prebuilt-rule-8-19-16-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 for Endpoint
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*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.
+
+
+*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.
+
+
+*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.
+
+
+==== 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"
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-brute-force-device-token-rotation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-brute-force-device-token-rotation.asciidoc
new file mode 100644
index 0000000000..61f3a5737f
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-brute-force-device-token-rotation.asciidoc
@@ -0,0 +1,158 @@
+[[prebuilt-rule-8-19-16-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.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*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://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta
+* https://www.okta.com/identity-101/brute-force/
+* https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US
+* https://developer.okta.com/docs/reference/api/event-types/
+* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy
+* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection
+* https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/
+* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security
+* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta
+
+*Tags*: 
+
+* Domain: Identity
+* Use Case: Identity and Access Audit
+* Data Source: Okta
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Okta Brute Force (Device Token Rotation)*
+
+
+This rule identifies excessive unique device token hashes generated for a single user account, indicating automated brute force tooling that fails to persist browser cookies between authentication attempts.
+
+
+*Possible investigation steps*
+
+- Identify the targeted user account and determine if it has elevated privileges or sensitive access.
+- Review the source IP and check if it belongs to known proxy, VPN, or cloud infrastructure.
+- Examine user agent strings for signs of automation, scripting tools, or inconsistent browser fingerprints.
+- Check if Okta flagged the source as a known threat or proxy.
+- Determine if any authentication attempts succeeded following the failed attempts.
+- Review the user's recent activity for signs of account compromise.
+
+
+*False positive analysis*
+
+- Users experiencing login issues may generate multiple device tokens through repeated legitimate attempts.
+- Automated testing or monitoring tools that do not persist cookies may trigger this rule.
+- Browser extensions or privacy tools that clear cookies between requests may cause device token rotation.
+
+
+*Response and remediation*
+
+- If attack is confirmed, reset the user's password immediately.
+- Block the source IP at the network perimeter.
+- Review and potentially reset MFA for the targeted account.
+- Monitor for any successful authentication that may indicate compromise.
+- Contact the user to verify if they experienced legitimate login issues.
+
+
+==== Setup
+
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM logs-okta.system-* METADATA _id, _version, _index
+| WHERE
+    event.dataset == "okta.system"
+    AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start")
+    AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT")
+    AND okta.actor.alternate_id IS NOT NULL
+    // Primary authn endpoint; sessions API provides additional coverage
+    AND (
+        okta.debug_context.debug_data.request_uri == "/api/v1/authn"
+        OR okta.debug_context.debug_data.request_uri LIKE "/api/v1/sessions*"
+    )
+// Track whether each event has a device token
+| EVAL has_dt_hash = CASE(okta.debug_context.debug_data.dt_hash IS NOT NULL, 1, 0)
+// Aggregate by IP + user to detect single-user brute force
+| STATS
+    Esql.unique_dt_hashes = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash),
+    Esql.total_attempts = COUNT(*),
+    Esql.attempts_with_dt = SUM(has_dt_hash),
+    Esql.unique_user_agents = COUNT_DISTINCT(okta.client.user_agent.raw_user_agent),
+    Esql.first_seen = MIN(@timestamp),
+    Esql.last_seen = MAX(@timestamp),
+    Esql.dt_hash_values = VALUES(okta.debug_context.debug_data.dt_hash),
+    Esql.event_action_values = VALUES(event.action),
+    Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent),
+    Esql.device_values = VALUES(okta.client.device),
+    Esql.is_proxy_values = VALUES(okta.security_context.is_proxy),
+    Esql.geo_country_values = VALUES(client.geo.country_name),
+    Esql.geo_city_values = VALUES(client.geo.city_name),
+    Esql.source_asn_values = VALUES(source.as.number),
+    Esql.source_asn_org_values = VALUES(source.as.organization.name),
+    Esql.threat_suspected_values = VALUES(okta.debug_context.debug_data.threat_suspected),
+    Esql.risk_level_values = VALUES(okta.debug_context.debug_data.risk_level),
+    Esql.risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons)
+  BY okta.client.ip, okta.actor.alternate_id
+// Calculate automation detection metrics (float-safe division)
+| EVAL Esql.dt_coverage = Esql.attempts_with_dt * 1.0 / Esql.total_attempts,
+       Esql.dt_per_attempt = Esql.unique_dt_hashes * 1.0 / Esql.total_attempts
+// Detection branches:
+//   A) Many unique DT hashes relative to attempts = tooling generating new tokens per attempt
+//   B) High attempts + very low DT coverage = cookie-less automation (no DT sent at all)
+//   C) Multiple user agents for same user = evasion or automation
+| WHERE
+    (Esql.unique_dt_hashes >= 7 AND Esql.total_attempts >= 10 AND Esql.dt_per_attempt >= 0.5)
+    OR (Esql.total_attempts >= 12 AND Esql.dt_coverage < 0.15)
+    OR (Esql.total_attempts >= 10 AND Esql.unique_user_agents >= 5)
+| SORT Esql.total_attempts DESC
+| KEEP Esql.*, okta.client.ip, okta.actor.alternate_id
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-brute-force-multi-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-brute-force-multi-source.asciidoc
new file mode 100644
index 0000000000..96e4f2a17b
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-brute-force-multi-source.asciidoc
@@ -0,0 +1,168 @@
+[[prebuilt-rule-8-19-16-potential-okta-brute-force-multi-source]]
+=== Potential Okta Brute Force (Multi-Source)
+
+Detects potential brute force attacks against a single Okta user account from multiple source IPs, indicating attackers rotating through proxy infrastructure to evade IP-based detection.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*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://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta
+* https://www.okta.com/identity-101/brute-force/
+* https://developer.okta.com/docs/reference/api/event-types/
+* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy
+* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security
+* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta
+
+*Tags*: 
+
+* Domain: Identity
+* Use Case: Identity and Access Audit
+* Use Case: Threat Detection
+* Data Source: Okta
+* Data Source: Okta System Logs
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Okta Brute Force (Multi-Source)*
+
+
+This rule identifies a single user account receiving failed authentication attempts from multiple unique source IPs. This pattern indicates attackers rotating through proxy infrastructure to evade IP-based detection while targeting a specific account.
+
+
+*Possible investigation steps*
+
+- Identify the targeted user account and determine if it has elevated privileges or sensitive access.
+- Review the geographic distribution of source IPs for anomalies such as multiple countries or unusual locations.
+- Examine the ASN ownership of source IPs for signs of proxy, VPN, or cloud infrastructure.
+- Check if Okta flagged any of the sources as known threats or proxies.
+- Determine if any authentication attempts succeeded following the failed attempts.
+- Review the user's recent activity for signs of account compromise.
+
+
+*False positive analysis*
+
+- Users traveling internationally with mobile devices may generate failed attempts from multiple locations.
+- Service accounts accessed from distributed legitimate infrastructure may trigger this rule.
+- Corporate VPN exit nodes spread across regions could appear as multiple IPs for a single user.
+
+
+*Response and remediation*
+
+- If attack is confirmed, reset the user's password immediately.
+- Review and potentially reset MFA for the targeted account.
+- Block attacking IP addresses at the network perimeter.
+- Consider implementing geo-restrictions for the targeted account if dispersed access is not expected.
+- Monitor for any successful authentication that may indicate compromise.
+
+
+==== Setup
+
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM logs-okta.system-* METADATA _id, _version, _index
+| WHERE event.dataset == "okta.system"
+    AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start")
+    AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT")
+    AND okta.actor.alternate_id IS NOT NULL
+
+// Create source mapping for analyst context
+| EVAL Esql.source_info = CONCAT(
+    "{\"ip\":\"", COALESCE(okta.client.ip::STRING, "unknown"),
+    "\",\"country\":\"", COALESCE(client.geo.country_name, "unknown"),
+    "\",\"asn\":\"", COALESCE(source.as.organization.name, "unknown"),
+    "\",\"user_agent\":\"", COALESCE(okta.client.user_agent.raw_user_agent, "unknown"), "\"}"
+  )
+
+| STATS
+    Esql.unique_source_ips = COUNT_DISTINCT(okta.client.ip),
+    Esql.total_attempts = COUNT(*),
+    Esql.unique_user_agents = COUNT_DISTINCT(okta.client.user_agent.raw_user_agent),
+    Esql.unique_dt_hashes = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash),
+    Esql.unique_asns = COUNT_DISTINCT(source.as.number),
+    Esql.unique_countries = COUNT_DISTINCT(client.geo.country_name),
+    Esql.first_seen = MIN(@timestamp),
+    Esql.last_seen = MAX(@timestamp),
+    Esql.source_ip_values = VALUES(okta.client.ip),
+    Esql.source_mapping = VALUES(Esql.source_info),
+    Esql.event_action_values = VALUES(event.action),
+    Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent),
+    Esql.device_values = VALUES(okta.client.device),
+    Esql.is_proxy_values = VALUES(okta.security_context.is_proxy),
+    Esql.geo_country_values = VALUES(client.geo.country_name),
+    Esql.geo_city_values = VALUES(client.geo.city_name),
+    Esql.source_asn_values = VALUES(source.as.number),
+    Esql.source_asn_org_values = VALUES(source.as.organization.name),
+    Esql.threat_suspected_values = VALUES(okta.debug_context.debug_data.threat_suspected),
+    Esql.risk_level_values = VALUES(okta.debug_context.debug_data.risk_level),
+    Esql.risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons)
+  BY okta.actor.alternate_id
+
+| EVAL
+    Esql.attempts_per_ip = Esql.total_attempts * 1.0 / Esql.unique_source_ips,
+    Esql.duration_seconds = DATE_DIFF("seconds", Esql.first_seen, Esql.last_seen)
+
+| WHERE
+    Esql.unique_source_ips >= 5
+    AND Esql.total_attempts >= 10
+    AND (
+        Esql.unique_countries >= 2 OR
+        Esql.unique_asns >= 3 OR
+        Esql.unique_source_ips >= 8 OR
+        Esql.unique_user_agents >= 3
+    )
+
+| SORT Esql.unique_source_ips DESC
+| KEEP Esql.*, okta.actor.alternate_id
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Brute Force
+** ID: T1110
+** Reference URL: https://attack.mitre.org/techniques/T1110/
+* Sub-technique:
+** Name: Password Guessing
+** ID: T1110.001
+** Reference URL: https://attack.mitre.org/techniques/T1110/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-credential-stuffing-single-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-credential-stuffing-single-source.asciidoc
new file mode 100644
index 0000000000..a8a6e7413a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-credential-stuffing-single-source.asciidoc
@@ -0,0 +1,185 @@
+[[prebuilt-rule-8-19-16-potential-okta-credential-stuffing-single-source]]
+=== Potential Okta Credential Stuffing (Single Source)
+
+Detects potential credential stuffing attacks where a single source IP attempts authentication against many Okta user accounts with minimal attempts per user, indicating the use of breached credential lists.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*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://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta
+* https://www.okta.com/identity-101/brute-force/
+* https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US
+* https://developer.okta.com/docs/reference/api/event-types/
+* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy
+* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection
+* https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/
+* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security
+* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta
+
+*Tags*: 
+
+* Domain: Identity
+* Use Case: Identity and Access Audit
+* Data Source: Okta
+* Data Source: Okta System Logs
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Okta Credential Stuffing (Single Source)*
+
+
+This rule identifies a single source IP attempting authentication against many user accounts with minimal attempts per user. This pattern indicates credential stuffing where attackers rapidly test breached username and password pairs.
+
+
+*Possible investigation steps*
+
+- Identify the source IP and determine if it belongs to known proxy, VPN, or cloud infrastructure.
+- Review the list of targeted user accounts and check if any authentications succeeded.
+- Examine the user agent strings for signs of automation or scripting tools.
+- Check if Okta flagged the source as a known threat or proxy.
+- Determine if any targeted accounts have elevated privileges or access to sensitive systems.
+- Review the geographic location and ASN of the source IP for anomalies.
+
+
+*False positive analysis*
+
+- Corporate proxies or VPN exit nodes may aggregate traffic from multiple legitimate users.
+- Shared systems such as kiosks or conference room computers may have multiple users authenticating.
+- Legitimate SSO integrations may generate multiple authentication attempts from a single source.
+
+
+*Response and remediation*
+
+- If attack is confirmed, block the source IP at the network perimeter.
+- Reset passwords for any accounts that may have been compromised.
+- Enable or strengthen MFA for targeted accounts.
+- Review Okta sign-on policies to add additional friction for suspicious authentication patterns.
+- If this is a known legitimate source, consider adding an exception for the IP or ASN.
+
+
+==== Setup
+
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM logs-okta.system-* METADATA _id, _version, _index
+| WHERE
+    event.dataset == "okta.system"
+    AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start")
+    AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT")
+    AND okta.actor.alternate_id IS NOT NULL
+// Build user-source context as JSON for enrichment
+| EVAL Esql.user_source_info = CONCAT(
+    "{\"user\":\"", okta.actor.alternate_id,
+    "\",\"ip\":\"", COALESCE(okta.client.ip::STRING, "unknown"),
+    "\",\"user_agent\":\"", COALESCE(okta.client.user_agent.raw_user_agent, "unknown"), "\"}"
+  )
+// FIRST STATS: Aggregate by (IP, user) to get per-user attempt counts
+// This prevents skew from outlier users with many attempts
+| STATS
+    Esql.user_attempts = COUNT(*),
+    Esql.user_dt_hashes = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash),
+    Esql.user_source_info = VALUES(Esql.user_source_info),
+    Esql.user_agents_per_user = VALUES(okta.client.user_agent.raw_user_agent),
+    Esql.devices_per_user = VALUES(okta.client.device),
+    Esql.is_proxy = VALUES(okta.security_context.is_proxy),
+    Esql.geo_country = VALUES(client.geo.country_name),
+    Esql.geo_city = VALUES(client.geo.city_name),
+    Esql.asn_number = VALUES(source.as.number),
+    Esql.asn_org = VALUES(source.as.organization.name),
+    Esql.threat_suspected = VALUES(okta.debug_context.debug_data.threat_suspected),
+    Esql.risk_level = VALUES(okta.debug_context.debug_data.risk_level),
+    Esql.risk_reasons = VALUES(okta.debug_context.debug_data.risk_reasons),
+    Esql.event_actions = VALUES(event.action),
+    Esql.first_seen_user = MIN(@timestamp),
+    Esql.last_seen_user = MAX(@timestamp)
+  BY okta.client.ip, okta.actor.alternate_id
+// SECOND STATS: Aggregate by IP to detect credential stuffing pattern
+// Now we can accurately measure the distribution of attempts across users
+| STATS
+    Esql.unique_users = COUNT(*),
+    Esql.total_attempts = SUM(Esql.user_attempts),
+    Esql.max_attempts_per_user = MAX(Esql.user_attempts),
+    Esql.min_attempts_per_user = MIN(Esql.user_attempts),
+    Esql.avg_attempts_per_user = AVG(Esql.user_attempts),
+    Esql.users_with_single_attempt = SUM(CASE(Esql.user_attempts == 1, 1, 0)),
+    Esql.users_with_few_attempts = SUM(CASE(Esql.user_attempts <= 2, 1, 0)),
+    Esql.first_seen = MIN(Esql.first_seen_user),
+    Esql.last_seen = MAX(Esql.last_seen_user),
+    Esql.target_users = VALUES(okta.actor.alternate_id),
+    Esql.user_source_mapping = VALUES(Esql.user_source_info),
+    Esql.event_action_values = VALUES(Esql.event_actions),
+    Esql.user_agent_values = VALUES(Esql.user_agents_per_user),
+    Esql.device_values = VALUES(Esql.devices_per_user),
+    Esql.is_proxy_values = VALUES(Esql.is_proxy),
+    Esql.geo_country_values = VALUES(Esql.geo_country),
+    Esql.geo_city_values = VALUES(Esql.geo_city),
+    Esql.source_asn_values = VALUES(Esql.asn_number),
+    Esql.source_asn_org_values = VALUES(Esql.asn_org),
+    Esql.threat_suspected_values = VALUES(Esql.threat_suspected),
+    Esql.risk_level_values = VALUES(Esql.risk_level),
+    Esql.risk_reasons_values = VALUES(Esql.risk_reasons)
+  BY okta.client.ip
+// Calculate stuffing signature: most users should have very few attempts
+| EVAL Esql.pct_users_few_attempts = Esql.users_with_few_attempts * 100.0 / Esql.unique_users
+// Credential stuffing: many users, most with 1-2 attempts each, low max per user
+// Stacked stats gives us accurate per-user distribution instead of skewed averages
+| WHERE
+    Esql.total_attempts >= 25
+    AND Esql.unique_users >= 15
+    AND Esql.max_attempts_per_user <= 2
+    AND Esql.pct_users_few_attempts >= 80.0
+| SORT Esql.unique_users DESC
+| KEEP Esql.*, okta.client.ip
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Brute Force
+** ID: T1110
+** Reference URL: https://attack.mitre.org/techniques/T1110/
+* Sub-technique:
+** Name: Credential Stuffing
+** ID: T1110.004
+** Reference URL: https://attack.mitre.org/techniques/T1110/004/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-password-spray-multi-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-password-spray-multi-source.asciidoc
new file mode 100644
index 0000000000..f307473143
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-password-spray-multi-source.asciidoc
@@ -0,0 +1,173 @@
+[[prebuilt-rule-8-19-16-potential-okta-password-spray-multi-source]]
+=== Potential Okta Password Spray (Multi-Source)
+
+Detects potential password spray attacks where multiple source IPs target multiple Okta user accounts within a time window, indicating coordinated attacks using IP rotation to evade single-source detection.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 15m
+
+*Searches indices from*: now-1h ({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.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta
+* https://www.okta.com/identity-101/brute-force/
+* https://developer.okta.com/docs/reference/api/event-types/
+* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy
+* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security
+* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta
+
+*Tags*: 
+
+* Domain: Identity
+* Use Case: Identity and Access Audit
+* Use Case: Threat Detection
+* Data Source: Okta
+* Data Source: Okta System Logs
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Okta Password Spray (Multi-Source)*
+
+
+This rule identifies coordinated password spray attacks where multiple source IPs target multiple user accounts within a time window. This pattern indicates attackers using IP rotation to evade single-source detection while spraying passwords across the organization.
+
+
+*Possible investigation steps*
+
+- Review the list of targeted user accounts and check if any authentications succeeded.
+- Examine the source IPs and their ASN ownership for signs of proxy, VPN, or cloud infrastructure.
+- Check if Okta flagged any of the sources as known threats or proxies.
+- Analyze the attempts-per-user ratio to confirm spray behavior versus brute force.
+- Review the geographic distribution of source IPs for coordination patterns.
+- Cross-reference with successful authentication events to identify potential compromises.
+
+
+*False positive analysis*
+
+- Organization-wide password rotation or expiration events may cause widespread authentication failures.
+- Misconfigured SSO or SAML integrations can cause batch failures from legitimate infrastructure.
+- Penetration testing should be coordinated and whitelisted in advance.
+
+
+*Response and remediation*
+
+- If attack is confirmed, notify affected users and enforce password resets for potentially compromised accounts.
+- Block attacking IP ranges at the network perimeter.
+- Enable or strengthen MFA for targeted accounts.
+- Review Okta sign-on policies to add additional friction for suspicious authentication patterns.
+- Consider temporary lockdowns for highly targeted accounts.
+
+
+==== Setup
+
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM logs-okta.system-* METADATA _id, _version, _index
+| WHERE
+    event.dataset == "okta.system"
+    AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start")
+    AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT")
+    AND okta.actor.alternate_id IS NOT NULL
+
+// Bucket into 15-minute windows and create user-source mapping for context
+| EVAL
+    Esql.time_bucket = DATE_TRUNC(15 minutes, @timestamp),
+    Esql.user_source_info = CONCAT(
+      "{\"user\":\"", okta.actor.alternate_id,
+      "\",\"ip\":\"", COALESCE(okta.client.ip::STRING, "unknown"),
+      "\",\"user_agent\":\"", COALESCE(okta.client.user_agent.raw_user_agent, "unknown"), "\"}"
+    )
+
+// Aggregate across entire tenant per time bucket to detect distributed spray
+| STATS
+    Esql.unique_users = COUNT_DISTINCT(okta.actor.alternate_id),
+    Esql.unique_source_ips = COUNT_DISTINCT(okta.client.ip),
+    Esql.total_attempts = COUNT(*),
+    Esql.unique_user_agents = COUNT_DISTINCT(okta.client.user_agent.raw_user_agent),
+    Esql.unique_asns = COUNT_DISTINCT(source.as.number),
+    Esql.unique_countries = COUNT_DISTINCT(client.geo.country_name),
+    Esql.first_seen = MIN(@timestamp),
+    Esql.last_seen = MAX(@timestamp),
+    Esql.target_users = VALUES(okta.actor.alternate_id),
+    Esql.source_ip_values = VALUES(okta.client.ip),
+    Esql.user_source_mapping = VALUES(Esql.user_source_info),
+    Esql.event_action_values = VALUES(event.action),
+    Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent),
+    Esql.device_values = VALUES(okta.client.device),
+    Esql.is_proxy_values = VALUES(okta.security_context.is_proxy),
+    Esql.geo_country_values = VALUES(client.geo.country_name),
+    Esql.geo_city_values = VALUES(client.geo.city_name),
+    Esql.source_asn_values = VALUES(source.as.number),
+    Esql.source_asn_org_values = VALUES(source.as.organization.name),
+    Esql.threat_suspected_values = VALUES(okta.debug_context.debug_data.threat_suspected),
+    Esql.risk_level_values = VALUES(okta.debug_context.debug_data.risk_level),
+    Esql.risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons)
+  BY Esql.time_bucket
+
+// Calculate spray metrics
+| EVAL
+    Esql.attempts_per_user = Esql.total_attempts * 1.0 / Esql.unique_users,
+    Esql.attempts_per_ip = Esql.total_attempts * 1.0 / Esql.unique_source_ips,
+    Esql.users_per_ip = Esql.unique_users * 1.0 / Esql.unique_source_ips
+
+// Distributed spray: many IPs, many users, moderate spread across both
+// Key differentiator: attacks come from multiple IPs (evading per-IP rules)
+| WHERE
+    Esql.unique_source_ips >= 5
+    AND Esql.unique_users >= 8
+    AND Esql.total_attempts >= 25
+    AND Esql.attempts_per_user <= 5.0
+    AND Esql.users_per_ip >= 1.0
+
+| SORT Esql.total_attempts DESC
+| KEEP Esql.*
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Brute Force
+** ID: T1110
+** Reference URL: https://attack.mitre.org/techniques/T1110/
+* Sub-technique:
+** Name: Password Spraying
+** ID: T1110.003
+** Reference URL: https://attack.mitre.org/techniques/T1110/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-password-spray-single-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-password-spray-single-source.asciidoc
new file mode 100644
index 0000000000..40b1d5b93a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-okta-password-spray-single-source.asciidoc
@@ -0,0 +1,188 @@
+[[prebuilt-rule-8-19-16-potential-okta-password-spray-single-source]]
+=== Potential Okta Password Spray (Single Source)
+
+Detects potential password spray attacks where a single source IP attempts authentication against multiple Okta user accounts with repeated attempts per user, indicating common password guessing paced to avoid lockouts.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 15m
+
+*Searches indices from*: now-1h ({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.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta
+* https://www.okta.com/identity-101/brute-force/
+* https://developer.okta.com/docs/reference/api/system-log/
+* https://developer.okta.com/docs/reference/api/event-types/
+* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy
+* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security
+* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta
+
+*Tags*: 
+
+* Domain: Identity
+* Use Case: Identity and Access Audit
+* Tactic: Credential Access
+* Data Source: Okta
+* Data Source: Okta System Logs
+* Resources: Investigation Guide
+
+*Version*: 417
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Okta Password Spray (Single Source)*
+
+
+This rule identifies a single source IP attempting authentication against multiple user accounts with repeated attempts per user over time. This pattern indicates password spraying where attackers try common passwords while pacing attempts to avoid lockouts.
+
+
+*Possible investigation steps*
+
+- Identify the source IP and determine if it belongs to known proxy, VPN, or cloud infrastructure.
+- Review the list of targeted user accounts and check if any authentications succeeded.
+- Analyze the timing of attempts to determine if they are paced to avoid lockout thresholds.
+- Check if Okta flagged the source as a known threat or proxy.
+- Examine user agent strings for signs of automation or consistent tooling across attempts.
+- Review the geographic location and ASN of the source IP for anomalies.
+
+
+*False positive analysis*
+
+- Corporate proxies or VPN exit nodes may aggregate traffic from multiple legitimate users with login issues.
+- Automated processes or misconfigured applications retrying authentication may trigger this rule.
+- Password rotation events may cause legitimate widespread authentication failures.
+
+
+*Response and remediation*
+
+- If attack is confirmed, block the source IP at the network perimeter.
+- Notify targeted users and enforce password resets for accounts that may have been compromised.
+- Enable or strengthen MFA for targeted accounts.
+- Consider implementing CAPTCHA or additional friction for suspicious authentication patterns.
+- Review Okta sign-on policies to ensure lockout thresholds are appropriately configured.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM logs-okta.system-* METADATA _id, _version, _index
+| WHERE
+    event.dataset == "okta.system"
+    AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start")
+    AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT")
+    AND okta.actor.alternate_id IS NOT NULL
+// Build user-source context as JSON for enrichment
+| EVAL Esql.user_source_info = CONCAT(
+    "{\"user\":\"", okta.actor.alternate_id,
+    "\",\"ip\":\"", COALESCE(okta.client.ip::STRING, "unknown"),
+    "\",\"user_agent\":\"", COALESCE(okta.client.user_agent.raw_user_agent, "unknown"), "\"}"
+  )
+// FIRST STATS: Aggregate by (IP, user) to get per-user attempt counts
+// This prevents skew from outlier users with many attempts
+| STATS
+    Esql.user_attempts = COUNT(*),
+    Esql.user_source_info = VALUES(Esql.user_source_info),
+    Esql.user_agents_per_user = VALUES(okta.client.user_agent.raw_user_agent),
+    Esql.devices_per_user = VALUES(okta.client.device),
+    Esql.is_proxy = VALUES(okta.security_context.is_proxy),
+    Esql.geo_country = VALUES(client.geo.country_name),
+    Esql.geo_city = VALUES(client.geo.city_name),
+    Esql.asn_number = VALUES(source.as.number),
+    Esql.asn_org = VALUES(source.as.organization.name),
+    Esql.threat_suspected = VALUES(okta.debug_context.debug_data.threat_suspected),
+    Esql.risk_level = VALUES(okta.debug_context.debug_data.risk_level),
+    Esql.event_actions = VALUES(event.action),
+    Esql.first_seen_user = MIN(@timestamp),
+    Esql.last_seen_user = MAX(@timestamp)
+  BY okta.client.ip, okta.actor.alternate_id
+// SECOND STATS: Aggregate by IP to detect password spray pattern
+// Now we can accurately measure the distribution of attempts across users
+| STATS
+    Esql.unique_users = COUNT(*),
+    Esql.total_attempts = SUM(Esql.user_attempts),
+    Esql.max_attempts_per_user = MAX(Esql.user_attempts),
+    Esql.min_attempts_per_user = MIN(Esql.user_attempts),
+    Esql.avg_attempts_per_user = AVG(Esql.user_attempts),
+    // Spray band: 2-6 attempts per user (deliberate slow spray below lockout)
+    Esql.users_in_spray_band = SUM(CASE(Esql.user_attempts >= 2 AND Esql.user_attempts <= 6, 1, 0)),
+    // Also track users with only 1 attempt (stuffing-like) for differentiation
+    Esql.users_with_single_attempt = SUM(CASE(Esql.user_attempts == 1, 1, 0)),
+    Esql.first_seen = MIN(Esql.first_seen_user),
+    Esql.last_seen = MAX(Esql.last_seen_user),
+    Esql.target_users = VALUES(okta.actor.alternate_id),
+    Esql.user_source_mapping = VALUES(Esql.user_source_info),
+    Esql.event_action_values = VALUES(Esql.event_actions),
+    Esql.user_agent_values = VALUES(Esql.user_agents_per_user),
+    Esql.device_values = VALUES(Esql.devices_per_user),
+    Esql.is_proxy_values = VALUES(Esql.is_proxy),
+    Esql.geo_country_values = VALUES(Esql.geo_country),
+    Esql.geo_city_values = VALUES(Esql.geo_city),
+    Esql.source_asn_values = VALUES(Esql.asn_number),
+    Esql.source_asn_org_values = VALUES(Esql.asn_org),
+    Esql.threat_suspected_values = VALUES(Esql.threat_suspected),
+    Esql.risk_level_values = VALUES(Esql.risk_level)
+  BY okta.client.ip
+// Calculate spray signature metrics
+| EVAL
+    // Percentage of users in the spray band (2-6 attempts)
+    Esql.pct_users_in_spray_band = Esql.users_in_spray_band * 100.0 / Esql.unique_users,
+    // Attack duration in minutes (spray is paced, not bursty)
+    Esql.attack_duration_minutes = DATE_DIFF("minute", Esql.first_seen, Esql.last_seen)
+// Password spraying detection logic:
+// - Many users targeted (>= 5)
+// - Hard cap below Okta lockout threshold (max <= 8 attempts per user)
+// - Majority of users in spray band (2-6 attempts) (at least 60%)
+// - Attack is paced over time (>= 5 minutes) (not a 10-second burst like stuffing)
+// - Minimum total attempts to reduce noise
+// Note: For IP rotation attacks, see "Distributed Password Spray Attack in Okta" rule
+| WHERE
+    Esql.unique_users >= 5
+    AND Esql.total_attempts >= 15
+    AND Esql.max_attempts_per_user <= 8
+    AND Esql.max_attempts_per_user >= 2
+    AND Esql.pct_users_in_spray_band >= 60.0
+    AND Esql.attack_duration_minutes >= 5
+| SORT Esql.total_attempts DESC
+| KEEP Esql.*, okta.client.ip
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Brute Force
+** ID: T1110
+** Reference URL: https://attack.mitre.org/techniques/T1110/
+* Sub-technique:
+** Name: Password Spraying
+** ID: T1110.003
+** Reference URL: https://attack.mitre.org/techniques/T1110/003/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-hacktool-script-by-author.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-hacktool-script-by-author.asciidoc
new file mode 100644
index 0000000000..95bdad038b
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-hacktool-script-by-author.asciidoc
@@ -0,0 +1,190 @@
+[[prebuilt-rule-8-19-16-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*: 
+
+* winlogbeat-*
+* logs-windows.powershell*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<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*: 109
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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*
+
+
+- `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*
+
+
+- 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.
+
+- 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.
+
+- 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.
+
+- 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.
+
+- 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).
+
+
+*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.
+
+
+*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.
+
+- 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.
+
+
+==== 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"
+  ) 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-16/prebuilt-rule-8-19-16-potential-powershell-hacktool-script-by-function-names.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-hacktool-script-by-function-names.asciidoc
new file mode 100644
index 0000000000..fc489ff4e3
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-hacktool-script-by-function-names.asciidoc
@@ -0,0 +1,352 @@
+[[prebuilt-rule-8-19-16-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.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.powershell*
+
+*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/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md
+* https://github.com/BC-SECURITY/Empire
+* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Execution
+* Data Source: PowerShell Logs
+* Resources: Investigation Guide
+
+*Version*: 220
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Function Names*
+
+
+This rule identifies PowerShell Script Block Logging events where the captured script content includes function names commonly reused by offensive PowerShell toolkits. Script blocks can contain function definitions (tool staging) and/or function invocation (active use). Prioritize determining what capability is present, how the script was introduced, and whether follow-on activity occurred.
+
+
+*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 `powershell.file.script_block_text` to determine intent and urgency:
+  - Identify the function name(s) present and map them to likely capability. Examples include:
+    - Credential access: `Invoke-Mimikatz`, `Invoke-Kerberoast`, `Invoke-DCSync`, `Get-GPPPassword`, `Get-LSASecret`.
+    - Injection or token manipulation: `Invoke-ReflectivePEInjection`, `Create-RemoteThread`, `Inject-RemoteShellcode`, `Invoke-TokenManipulation`.
+    - Remote execution or lateral movement: `Invoke-PsExec`, `Invoke-SMBExec`, `Invoke-WmiCommand`, `Invoke-PSRemoting`, `Invoke-DCOM`.
+    - Staging, persistence, or exfiltration: `Invoke-DownloadCradle`, `Add-Persistence`, `HTTP-Backdoor`, `Do-Exfiltration`.
+  - Determine whether the script block primarily defines functions (tool staging) or calls them (active use). If only definitions are present, look for follow-on script blocks from the same host and user that invoke the functions.
+  - Capture any embedded targets or indicators visible in the text (other usernames, hostnames, domains, remote paths, URLs, or IP addresses).
+
+- Reconstruct the complete script when it is split across multiple events:
+  - Pivot using `host.name` (or `host.id`) and `powershell.file.script_block_id` to collect related script blocks around `@timestamp`.
+  - Order fragments using `powershell.sequence` and confirm completeness using `powershell.total`.
+  - Use `powershell.file.script_block_length` as a size signal to distinguish a full toolkit/module from a small launcher or single command.
+
+- Establish script origin and execution context:
+  - If `file.path` / `file.name` (and `file.directory`) are present, treat the script as an on-disk artifact. Validate whether its location and naming align with approved scripts and expected administrative workflows for that host and user.
+  - If file fields are not present, treat the activity as potentially interactive or in-memory. Correlate other endpoint telemetry from the same `host.id` and time window to identify how PowerShell was started and what else executed immediately before and after.
+
+- Validate the account and host context:
+  - Review `user.name`, `user.domain`, and `user.id` for privilege level and whether the activity aligns with expected responsibilities and working hours.
+  - Review `host.name` and `host.id` to understand the system role and whether advanced PowerShell activity is expected on that host.
+
+- Scope for additional related activity on the same host:
+  - Search for other script blocks on the same `host.id` and `user.id` near the alert time to identify staging, follow-on commands, or cleanup actions.
+  - Pivot on `powershell.file.script_block_id` to ensure all fragments are reviewed and to detect repeated execution of the same script content.
+
+- Scope for related activity across the environment:
+  - Search for additional script blocks containing the same distinctive function name(s) or matching snippets of `powershell.file.script_block_text` to identify reuse and potential spread.
+  - If `file.path` or `file.name` is present, check for the same script artifact referenced on other hosts.
+
+- Correlate with adjacent telemetry (as available) to confirm impact and intent:
+  - Process telemetry to identify the initiating process (parent of PowerShell) and any suspicious child processes spawned after the script executed.
+  - Authentication telemetry to identify anomalous logons or access patterns involving the same user around the execution window.
+  - Network and DNS telemetry to identify outbound connections, internal scanning, or remote management activity aligned with `@timestamp`.
+  - Persistence telemetry to identify new or modified services, scheduled tasks, autoruns, or registry changes that align with the observed script capability.
+
+
+*False positive analysis*
+
+
+- Internal security or IT teams may run proof-of-concept or validation scripts for training, detection testing, or incident response. Confirm script ownership, change control, and expected distribution.
+
+
+*Response and remediation*
+
+
+- If the activity is unauthorized or suspicious:
+  - Contain the affected host to prevent additional execution and lateral movement.
+  - Preserve evidence by saving all related script block events (reconstruct full content using `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`) and collecting any referenced on-disk script identified by `file.path`.
+  - Prioritize impact assessment based on the functions observed (credential access, injection, remote execution, persistence, or exfiltration) and look for corroborating activity in adjacent telemetry.
+  - Scope for additional impacted systems and accounts by searching for the same function names or script snippets across other hosts and users.
+  - Remove identified artifacts and persistence mechanisms, and monitor for re-execution using the same function-name patterns.
+
+- If the activity is confirmed benign:
+  - Document the justification (owner, purpose, expected hosts/users, and time window) and retain the reconstructed script content for future baselining.
+  - Where feasible, limit high-risk PowerShell tooling to controlled administrative hosts and approved accounts to reduce recurrence.
+
+
+==== 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 : (
+    "Add-DomainGroupMember" or "Add-DomainObjectAcl" or
+    "Add-RemoteConnection" or "Add-ServiceDacl" or
+    "Add-Win32Type" or "Convert-ADName" or
+    "Convert-LDAPProperty" or "ConvertFrom-LDAPLogonHours" or
+    "ConvertFrom-UACValue" or "Copy-ArrayOfMemAddresses" or
+    "Create-NamedPipe" or "Create-ProcessWithToken" or
+    "Create-RemoteThread" or "Create-SuspendedWinLogon" or
+    "Create-WinLogonProcess" or "Emit-CallThreadStub" or
+    "Enable-SeAssignPrimaryTokenPrivilege" or "Enable-SeDebugPrivilege" or
+    "Enum-AllTokens" or "Export-PowerViewCSV" or
+    "Find-AVSignature" or "Find-AppLockerLog" or
+    "Find-DomainLocalGroupMember" or "Find-DomainObjectPropertyOutlier" or
+    "Find-DomainProcess" or "Find-DomainShare" or
+    "Find-DomainUserEvent" or "Find-DomainUserLocation" or
+    "Find-InterestingDomainAcl" or "Find-InterestingDomainShareFile" or
+    "Find-InterestingFile" or "Find-LocalAdminAccess" or
+    "Find-PSScriptsInPSAppLog" or "Find-PathDLLHijack" or
+    "Find-ProcessDLLHijack" or "Find-RDPClientConnection" or
+    "Get-AllAttributesForClass" or "Get-CachedGPPPassword" or
+    "Get-DecryptedCpassword" or "Get-DecryptedSitelistPassword" or
+    "Get-DelegateType" or "New-RelayEnumObject" or
+    "Get-DomainDFSShare" or "Get-DomainDFSShareV1" or
+    "Get-DomainDFSShareV2" or "Get-DomainDNSRecord" or
+    "Get-DomainDNSZone" or "Get-DomainFileServer" or
+    "Get-DomainForeignGroupMember" or "Get-DomainForeignUser" or
+    "Get-DomainGPO" or "Get-DomainGPOComputerLocalGroupMapping" or
+    "Get-DomainGPOLocalGroup" or "Get-DomainGPOUserLocalGroupMapping" or
+    "Get-DomainGUIDMap" or "Get-DomainGroup" or
+    "Get-DomainGroupMember" or "Get-DomainGroupMemberDeleted" or
+    "Get-DomainManagedSecurityGroup" or "Get-DomainOU" or
+    "Get-DomainObject" or "Get-DomainObjectAcl" or
+    "Get-DomainObjectAttributeHistory" or "Get-DomainObjectLinkedAttributeHistory" or
+    "Get-DomainPolicyData" or "Get-DomainSID" or
+    "Get-DomainSPNTicket" or "Get-DomainSearcher" or
+    "Get-DomainSite" or "Get-DomainSubnet" or
+    "Get-DomainTrust" or "Get-DomainTrustMapping" or
+    "Get-DomainUser" or "Get-DomainUserEvent" or
+    "Get-Forest" or "Get-ForestDomain" or
+    "Get-ForestGlobalCatalog" or "Get-ForestSchemaClass" or
+    "Get-ForestTrust" or "Get-GPODelegation" or
+    "Get-GPPAutologon" or "Get-GPPInnerField" or
+    "Get-GPPInnerFields" or "Get-GPPPassword" or
+    "Get-GptTmpl" or "Get-GroupsXML" or
+    "Get-HttpStatus" or "Get-ImageNtHeaders" or
+    "Get-Keystrokes" or "New-SOASerialNumberArray" or
+    "Get-MemoryProcAddress" or "Get-MicrophoneAudio" or
+    "Get-ModifiablePath" or "Get-ModifiableRegistryAutoRun" or
+    "Get-ModifiableScheduledTaskFile" or "Get-ModifiableService" or
+    "Get-ModifiableServiceFile" or "Get-Name" or
+    "Get-NetComputerSiteName" or "Get-NetLocalGroup" or
+    "Get-NetLocalGroupMember" or "Get-NetLoggedon" or
+    "Get-NetRDPSession" or "Get-NetSession" or
+    "Get-NetShare" or "Get-PEArchitecture" or
+    "Get-PEBasicInfo" or "Get-PEDetailedInfo" or
+    "Get-PathAcl" or "Get-PrimaryToken" or
+    "Get-ProcAddress" or "Get-ProcessTokenGroup" or
+    "Get-ProcessTokenPrivilege" or "Get-ProcessTokenType" or
+    "Get-RegLoggedOn" or "Get-RegistryAlwaysInstallElevated" or
+    "Get-RegistryAutoLogon" or "Get-RemoteProcAddress" or
+    "Get-Screenshot" or "Get-ServiceDetail" or
+    "Get-SiteListPassword" or "Get-SitelistField" or
+    "Get-System" or "Get-SystemNamedPipe" or
+    "Get-SystemToken" or "Get-ThreadToken" or
+    "Get-TimedScreenshot" or "Get-TokenInformation" or
+    "Get-TopPort" or "Get-UnattendedInstallFile" or
+    "Get-UniqueTokens" or "Get-UnquotedService" or
+    "Get-VaultCredential" or "Get-VaultElementValue" or
+    "Get-VirtualProtectValue" or "Get-VolumeShadowCopy" or
+    "Get-WMIProcess" or "Get-WMIRegCachedRDPConnection" or
+    "Get-WMIRegLastLoggedOn" or "Get-WMIRegMountedDrive" or
+    "Get-WMIRegProxy" or "Get-WebConfig" or
+    "Get-Win32Constants" or "Get-Win32Functions" or
+    "Get-Win32Types" or "Import-DllImports" or
+    "Import-DllInRemoteProcess" or "Inject-LocalShellcode" or
+    "Inject-RemoteShellcode" or "Install-ServiceBinary" or
+    "Invoke-CompareAttributesForClass" or "Invoke-CreateRemoteThread" or
+    "Invoke-CredentialInjection" or "Invoke-DllInjection" or
+    "Invoke-EventVwrBypass" or "Invoke-ImpersonateUser" or
+    "Invoke-Kerberoast" or "Invoke-MemoryFreeLibrary" or
+    "Invoke-MemoryLoadLibrary" or
+    "Invoke-Mimikatz" or "Invoke-NinjaCopy" or
+    "Invoke-PatchDll" or "Invoke-Portscan" or
+    "Invoke-PrivescAudit" or "Invoke-ReflectivePEInjection" or
+    "Invoke-ReverseDnsLookup" or "Invoke-RevertToSelf" or
+    "Invoke-ServiceAbuse" or "Invoke-Shellcode" or
+    "Invoke-TokenManipulation" or "Invoke-UserImpersonation" or
+    "Invoke-WmiCommand" or "Mount-VolumeShadowCopy" or
+    "New-ADObjectAccessControlEntry" or "New-DomainGroup" or
+    "New-DomainUser" or "New-DynamicParameter" or
+    "New-InMemoryModule" or
+    "New-ThreadedFunction" or "New-VolumeShadowCopy" or
+    "Out-CompressedDll" or "Out-EncodedCommand" or
+    "Out-EncryptedScript" or "Out-Minidump" or
+    "PortScan-Alive" or "Portscan-Port" or
+    "Remove-DomainGroupMember" or "Remove-DomainObjectAcl" or
+    "Remove-RemoteConnection" or "Remove-VolumeShadowCopy" or
+    "Restore-ServiceBinary" or "Set-DesktopACLToAllowEveryone" or
+    "Set-DesktopACLs" or "Set-DomainObject" or
+    "Set-DomainObjectOwner" or "Set-DomainUserPassword" or
+    "Set-ServiceBinaryPath" or "Sub-SignedIntAsUnsigned" or
+    "Test-AdminAccess" or "Test-MemoryRangeValid" or
+    "Test-ServiceDaclPermission" or "Update-ExeFunctions" or
+    "Update-MemoryAddresses" or "Update-MemoryProtectionFlags" or
+    "Write-BytesToMemory" or "Write-HijackDll" or
+    "Write-PortscanOut" or "Write-ServiceBinary" or
+    "Write-UserAddMSI" or "Invoke-Privesc" or
+    "func_get_proc_address" or "Invoke-BloodHound" or
+    "Invoke-HostEnum" or "Get-BrowserInformation" or
+    "Get-DomainAccountPolicy" or "Get-DomainAdmins" or
+    "Get-AVProcesses" or "Get-AVInfo" or
+    "Get-RecycleBin" or "Invoke-BruteForce" or
+    "Get-PassHints" or "Invoke-SessionGopher" or
+    "Get-LSASecret" or "Get-PassHashes" or
+    "Invoke-WdigestDowngrade" or "Get-ChromeDump" or
+    "Invoke-DomainPasswordSpray" or "Get-FoxDump" or
+    "New-HoneyHash" or "Invoke-DCSync" or
+    "Invoke-PowerDump" or "Invoke-SSIDExfil" or
+    "Invoke-PowerShellTCP" or "Add-Exfiltration" or
+    "Do-Exfiltration" or "Invoke-DropboxUpload" or
+    "Invoke-ExfilDataToGitHub" or "Invoke-EgressCheck" or
+    "Invoke-PostExfil" or "Create-MultipleSessions" or
+    "Invoke-NetworkRelay" or "New-GPOImmediateTask" or
+    "Invoke-WMIDebugger" or "Invoke-SQLOSCMD" or
+    "Invoke-SMBExec" or "Invoke-PSRemoting" or
+    "Invoke-ExecuteMSBuild" or "Invoke-DCOM" or
+    "Invoke-InveighRelay" or "Invoke-PsExec" or
+    "Find-ActiveUsersWMI" or
+    "Get-SystemDrivesWMI" or "Get-ActiveNICSWMI" or
+    "Remove-Persistence" or "DNS_TXT_Pwnage" or
+    "Execute-OnTime" or "HTTP-Backdoor" or
+    "Add-ConstrainedDelegationBackdoor" or "Add-RegBackdoor" or
+    "Add-ScrnSaveBackdoor" or "Gupt-Backdoor" or
+    "Invoke-ADSBackdoor" or "Add-Persistence" or
+    "Invoke-ResolverBackdoor" or "Invoke-EventLogBackdoor" or
+    "Invoke-DeadUserBackdoor" or "Invoke-DisableMachineAcctChange" or
+    "Invoke-AccessBinary" or "Add-NetUser" or
+    "Invoke-Schtasks" or "Invoke-JSRatRegsvr" or
+    "Invoke-JSRatRundll" or "Invoke-PoshRatHttps" or
+    "Invoke-PsGcatAgent" or "Remove-PoshRat" or
+    "Install-SSP" or "Invoke-BackdoorLNK" or
+    "PowerBreach" or "InstallEXE-Persistence" or
+    "RemoveEXE-Persistence" or "Install-ServiceLevel-Persistence" or
+    "Remove-ServiceLevel-Persistence" or "Invoke-Prompt" or
+    "Invoke-PacketCapture" or "Start-WebcamRecorder" or
+    "Get-USBKeyStrokes" or "Invoke-KeeThief" or
+    "Get-Keystrokes" or "Invoke-NetRipper" or
+    "Get-EmailItems" or "Invoke-MailSearch" or
+    "Invoke-SearchGAL" or "Get-WebCredentials" or
+    "Start-CaptureServer" or "Invoke-PowerShellIcmp" or
+    "Invoke-PowerShellTcpOneLine" or "Invoke-PowerShellTcpOneLineBind" or
+    "Invoke-PowerShellUdp" or "Invoke-PowerShellUdpOneLine" or
+    "Run-EXEonRemote" or "Download-Execute-PS" or
+    "Out-RundllCommand" or "Set-RemoteWMI" or
+    "Set-DCShadowPermissions" or "Invoke-PowerShellWMI" or
+    "Invoke-Vnc" or "Invoke-LockWorkStation" or
+    "Invoke-EternalBlue" or "Invoke-ShellcodeMSIL" or
+    "Invoke-MetasploitPayload" or "Invoke-DowngradeAccount" or
+    "Invoke-RunAs" or "ExetoText" or
+    "Disable-SecuritySettings" or "Set-MacAttribute" or
+    "Invoke-MS16032" or "Invoke-BypassUACTokenManipulation" or
+    "Invoke-SDCLTBypass" or "Invoke-FodHelperBypass" or
+    "Invoke-EventVwrBypass" or "Invoke-EnvBypass" or
+    "Get-ServiceUnquoted" or "Get-ServiceFilePermission" or
+    "Get-ServicePermission" or
+    "Enable-DuplicateToken" or "Invoke-PsUaCme" or
+    "Invoke-Tater" or "Invoke-WScriptBypassUAC" or
+    "Invoke-AllChecks" or "Find-TrustedDocuments" or
+    "Invoke-Interceptor" or "Invoke-PoshRatHttp" or
+    "Invoke-ExecCommandWMI" or "Invoke-KillProcessWMI" or
+    "Invoke-CreateShareandExecute" or "Invoke-RemoteScriptWithOutput" or
+    "Invoke-SchedJobManipulation" or "Invoke-ServiceManipulation" or
+    "Invoke-PowerOptionsWMI" or "Invoke-DirectoryListing" or
+    "Invoke-FileTransferOverWMI" or "Invoke-WMImplant" or
+    "Invoke-WMIObfuscatedPSCommand" or "Invoke-WMIDuplicateClass" or
+    "Invoke-WMIUpload" or "Invoke-WMIRemoteExtract" or "Invoke-winPEAS" or
+    "Invoke-AzureHound" or "Invoke-SharpHound" or "Invoke-DownloadCradle" or
+    "Invoke-AppPathBypass"
+  ) and
+  not powershell.file.script_block_text : (
+    "sentinelbreakpoints" and "Set-PSBreakpoint"
+  ) and
+  not user.id : ("S-1-5-18" or "S-1-5-19")
+
+----------------------------------
+
+*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-16/prebuilt-rule-8-19-16-potential-powershell-obfuscated-script-via-high-entropy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscated-script-via-high-entropy.asciidoc
new file mode 100644
index 0000000000..9257f143ca
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscated-script-via-high-entropy.asciidoc
@@ -0,0 +1,190 @@
+[[prebuilt-rule-8-19-16-potential-powershell-obfuscated-script-via-high-entropy]]
+=== Potential PowerShell Obfuscated Script via High Entropy
+
+Identifies PowerShell script blocks with high entropy and non-uniform character distributions. Attackers may obfuscate PowerShell scripts using encoding, encryption, or compression techniques to evade signature-based detections and hinder manual analysis by security analysts.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-windows.powershell*
+
+*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: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: PowerShell Logs
+* 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 PowerShell Obfuscated Script via High Entropy*
+
+
+This alert flags a large PowerShell script block with statistical characteristics consistent with obfuscated content (for example, encoded, compressed, or encrypted data embedded in a script). Triage should focus on establishing execution context (who/where), reconstructing the complete script content, identifying whether the high-entropy data is a benign embedded resource or a staged payload, and scoping for related activity.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
+
+
+*Possible investigation steps*
+
+
+- Triage the execution context and initial severity:
+  - Review `@timestamp` to identify when the script block executed and align pivots to the same timeframe.
+  - Review `host.name` and `host.id` to identify the endpoint and validate whether PowerShell use is expected for its role.
+  - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to run PowerShell on this host and whether it is privileged, shared, or an automation/service identity.
+  - Review `powershell.file.script_block_length`, `powershell.file.script_block_entropy_bits`, and `powershell.file.script_block_surprisal_stdev` to understand whether the alert is driven by a large embedded blob (often staging) or more mixed script content (often a wrapper/loader plus embedded data).
+
+- Determine script provenance (file-backed vs. dynamic/interactive):
+  - If `file.path` is present, review `file.directory` and `file.name` to understand where the script originated.
+  - Assess whether `file.directory` is consistent with approved administrative tooling locations for this host and user, or whether it appears user-writable, temporary, or otherwise unusual.
+  - If `file.path` is absent, treat the script block as potentially interactive or dynamically generated and prioritize reconstructing the full script content and identifying the launch source via process correlation.
+
+- Reconstruct the full script content when fragmented:
+  - Pivot on `powershell.file.script_block_id` to collect all fragments associated with the script block.
+  - Order fragments using `powershell.sequence` and validate completeness using `powershell.total`.
+  - Analyze the reconstructed content as a whole to avoid missing small loader logic that precedes a large encoded/encrypted payload.
+
+- Perform structured content review of `powershell.file.script_block_text`:
+  - Identify large contiguous strings, byte arrays, or character arrays that may represent encoded or packed data; use `powershell.file.script_block_unique_symbols` to help distinguish limited-alphabet encodings from broader character sets.
+  - Look for transformation and staging patterns (for example, decode/decrypt/decompress routines) and whether transformed content is immediately executed (for example, dynamic invocation, in-memory loading, or secondary script evaluation).
+  - Extract any embedded indicators (domains, URLs, IPs, file paths/names, registry paths, scheduled task/service names, or distinctive strings) and retain them for scoping and containment.
+
+- Establish the execution chain and initiating source:
+  - Use `process.pid` with `host.id` and `@timestamp` to pivot to process telemetry for the PowerShell host instance that generated the script block.
+  - Identify the parent process and initiating mechanism (interactive shell, scheduled execution, remote management, document/script host, or other launcher). Treat unexpected launch sources or unusual timing for the host role as higher risk.
+  - Check whether the same `process.pid` generated additional suspicious script blocks around the alert time, and whether `user.id` and `host.id` align with expected administrative behavior.
+
+- Correlate for follow-on activity on the same host and account:
+  - Correlate on `host.id` and `@timestamp` to identify adjacent events that indicate impact (outbound connections, file writes, module downloads, persistence changes, or unusual authentication activity).
+  - When `file.path` is present, correlate on that path and timeframe for file creation/modification patterns that may indicate initial staging or subsequent cleanup.
+
+- Scope the activity across the environment:
+  - Search for other high-entropy script blocks on the same `host.id` and `user.id` before and after the alert to identify repeated execution or iterative staging.
+  - Search across hosts for the same `file.name` and `file.path` (when present) and compare `powershell.file.script_block_text` structure to identify reuse.
+  - Use distinctive substrings from `powershell.file.script_block_text` as pivots to find related script blocks even when paths or accounts differ.
+
+
+*False positive analysis*
+
+
+- Benign scripts can trigger this alert when they legitimately embed packed data (for example, compressed resources, serialized configuration blobs, embedded certificates/keys, or packaged modules) that increase entropy and appear non-uniform.
+- Indicators supporting a benign determination:
+  - `file.path` and `file.name` consistently map to an approved internal tool or vendor-managed automation across multiple hosts.
+  - `user.id` represents an expected administrative or automation identity with predictable host targeting and execution timing.
+  - Reconstructed `powershell.file.script_block_text` shows a stable, repeatable structure over time, and any decoded content aligns with known operational functionality rather than staging and immediate secondary execution.
+- Indicators supporting suspicion:
+  - Unusual `file.directory` for the host role or account, or absence of `file.path` combined with evidence of dynamic staging behavior.
+  - Reconstructed content includes clear execution of transformed data, in-memory loading patterns, or embedded external destinations not associated with known tooling.
+- If determined benign, document the owning tool/team, expected `user.id` usage, and expected `file.path`/`file.name` (when present). Use those stable attributes for future baselining and noise reduction while preserving detection for new paths, new users, or materially different script structures.
+
+
+*Response and remediation*
+
+
+- If suspicious or malicious activity is confirmed:
+  - Contain the affected host to prevent further execution and lateral movement.
+  - Preserve relevant evidence from the alert, including full reconstructed script content (via `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`), and associated context (`@timestamp`, `host.*`, `user.*`, `file.*`, `process.pid`, and entropy metrics).
+  - Use extracted indicators from `powershell.file.script_block_text` to hunt across hosts and accounts, and to identify additional affected systems.
+  - Investigate and remediate follow-on activity identified during correlation (downloaded payloads, dropped files, persistence mechanisms, or unauthorized network access) and remove malicious artifacts from affected endpoints.
+  - If account compromise is suspected for `user.id` / `user.name`, initiate credential reset and review recent authentication activity and access paths associated with that identity.
+
+- If benign activity is confirmed:
+  - Record the justification and expected behavior (who runs it, where it runs, and expected `file.path` when present).
+  - Monitor for deviations from the established baseline, including new `user.id`, new `host.id`, new `file.path`, or significant changes in `powershell.file.script_block_text` structure or entropy characteristics.
+
+
+==== 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
+
+This rule uses the following fields that require the Windows Integration v3.3.0 and up: `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_length`.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.category:process and host.os.type:windows and powershell.file.script_block_length > 1000 and
+  powershell.file.script_block_entropy_bits >= 5.3 and powershell.file.script_block_surprisal_stdev > 0.7 and
+  not file.directory: "C:\Program Files (x86)\Microsoft Intune Management Extension\Content\DetectionScripts"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc
new file mode 100644
index 0000000000..0c1eff0b23
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc
@@ -0,0 +1,211 @@
+[[prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion]]
+=== Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion
+
+Detects PowerShell scripts that uses backtick-escaped characters inside `${}` variable expansion (multiple backticks between word characters) to reconstruct strings at runtime. Attackers use variable-expansion obfuscation to split keywords, hide commands, and evade static analysis and AMSI.
+
+*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: Defense Evasion
+* Data Source: PowerShell Logs
+* Resources: Investigation Guide
+
+*Version*: 9
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Obfuscation via Backtick-Escaped Variable Expansion*
+
+
+This rule identifies Windows PowerShell Script Block Logging events where backtick-escaped characters are embedded within `${}` variable expansion. This technique can be used to split tokens and reconstruct variable names or keywords at runtime, reducing the effectiveness of simple string-based detections and content scanning.
+
+Focus analysis on (1) who executed the script, (2) where it executed, (3) how much of the script is obfuscated, and (4) what the script ultimately does after deobfuscation. Higher `Esql.script_block_pattern_count`, elevated `powershell.file.script_block_entropy_bits`, and unexpected script origin (for example, unusual `file.path`) increase the likelihood of malicious intent.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
+
+
+*Possible investigation steps*
+
+
+- Validate execution scope and context:
+  - Review `host.name` / `host.id` to understand where the script ran and whether the endpoint role makes this activity unexpected.
+  - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to run PowerShell on this host and to identify any unusual account usage patterns in your environment.
+  - If `file.path` / `file.name` / `file.directory` are present, determine whether the script appears to originate from an expected location (for example, a managed scripts directory) versus an unusual or user-writable location.
+
+- Reconstruct the complete script before interpreting intent:
+  - Pivot on `powershell.file.script_block_id` and collect all related fragments.
+  - Use `powershell.sequence` and `powershell.total` to verify you have the full set of fragments and to order them correctly.
+  - Review the reconstructed `powershell.file.script_block_text` for staging behavior (for example, an initial deobfuscation routine followed by a second stage that performs the primary action).
+
+- Locate the obfuscated variable expansions and normalize the content:
+  - Use `Esql.script_block_tmp` to quickly identify the positions of suspicious `${}` expansions, then review the corresponding sections in `powershell.file.script_block_text`.
+  - Use `Esql.script_block_pattern_count` to estimate how pervasive the obfuscation is. A higher count is more consistent with deliberate evasion than isolated escaping.
+  - In the matched `${}` segments, assess what the obfuscated expansion is intended to represent by mentally removing backtick escapes and looking for recognizable tokens (cmdlet/function names, variable names, or string literals) that the script is trying to hide.
+
+- Assess behavior indicated by the script content:
+  - Identify whether the script uses dynamic invocation patterns, such as building an invocation target at runtime or executing reconstructed strings.
+  - Look for decoding and deobfuscation constructs (string concatenation, character-by-character reconstruction, data transformation, decompression) that may reveal embedded or second-stage content.
+  - Extract and document any clear indicators contained in the script text (remote endpoints, file paths, registry paths, service/task names, or additional scripts referenced). Use these indicators to scope impact across hosts.
+
+- Use alert-side obfuscation metrics to prioritize and focus review:
+  - Compare `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_surprisal_stdev` against what is typical in your environment for administrative scripts.
+  - Treat scripts with high entropy and many unique symbols as higher risk, especially when combined with multiple obfuscated `${}` expansions.
+
+- Scope prevalence and recurrence:
+  - Search for other Script Block Logging events on the same `host.id` and `user.id` that include similar backtick-escaped `${}` patterns.
+  - Look for repeated occurrences of the same `file.name` / `file.path` across multiple hosts, which may indicate a shared script or distributed execution.
+  - If the script contains unique strings or indicators, use them to identify additional affected endpoints.
+
+
+*False positive analysis*
+
+
+- Legitimate scripts that implement complex string building or variable-name handling and happen to use backticks within `${}` expansion (more common in developer tooling, templating, or edge-case input handling).
+- Auto-generated PowerShell produced by administrative automation that uses nonstandard escaping or runtime string construction.
+
+When evaluating potential false positives, weigh consistency (same `user.id`, `host.id`, and `file.path` over time) against indicators of compromise (unexpected user/host pairing, high obfuscation density, high entropy, or evidence of follow-on actions).
+
+
+*Response and remediation*
+
+
+- If the activity is suspicious or confirmed malicious:
+  - Contain the affected endpoint to prevent additional execution and limit potential lateral movement.
+  - Preserve evidence from the alert, including the full reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence` / `powershell.total`, and any `file.path` / `file.name` values.
+  - If an on-disk source is indicated by `file.path`, collect the referenced script and related files for review and remove or quarantine malicious artifacts according to your procedures.
+  - Investigate for follow-on effects suggested by the script content (persistence, payload delivery, configuration changes) and remediate any identified artifacts.
+  - Review the impacted `user.id` for compromise, revoke active sessions as appropriate, and reset credentials based on your incident response policy.
+  - Use extracted indicators and distinctive script fragments to hunt for additional affected hosts and users.
+
+- If the activity is verified benign:
+  - Document the legitimate script source, expected `file.path` / `file.name`, and the normal execution context (`user.id`, `host.id`) to speed up future triage.
+  - Monitor for deviations in execution context or significant changes in obfuscation metrics (for example, increased `Esql.script_block_pattern_count` or higher entropy) that could indicate abuse of an otherwise legitimate script.
+
+
+==== 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]
+----------------------------------
+from logs-windows.powershell_operational* metadata _id, _version, _index
+| where event.code == "4104"
+
+// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for
+| eval Esql.script_block_length = length(powershell.file.script_block_text)
+| where Esql.script_block_length > 500
+
+// replace the patterns we are looking for with the 🔥 emoji to enable counting them
+// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1
+| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, """\$\{(\w++`){2,}\w++\}""", "🔥")
+
+// count how many patterns were detected by calculating the number of 🔥 characters inserted
+| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", ""))
+
+// keep the fields relevant to the query, although this is not needed as the alert is populated using _id
+| keep
+    Esql.script_block_pattern_count,
+    Esql.script_block_length,
+    Esql.script_block_tmp,
+    powershell.file.*,
+    file.path,
+    file.name,
+    powershell.sequence,
+    powershell.total,
+    _id,
+    _version,
+    _index,
+    host.name,
+    host.id,
+    agent.id,
+    user.id
+
+// Filter for scripts that match the pattern at least once
+| where Esql.script_block_pattern_count >= 1
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc
new file mode 100644
index 0000000000..960d9750f8
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc
@@ -0,0 +1,194 @@
+[[prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-character-array-reconstruction]]
+=== Potential PowerShell Obfuscation via Character Array Reconstruction
+
+Detects PowerShell scripts that reconstructs strings from char[] arrays, index lookups, or repeated ([char]NN)+ concatenation/join logic. Attackers use character-array reconstruction to hide commands, URLs, or payloads and evade static analysis and AMSI.
+
+*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: Defense Evasion
+* Data Source: PowerShell Logs
+* Resources: Investigation Guide
+
+*Version*: 9
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Obfuscation via Character Array Reconstruction*
+
+
+This rule identifies PowerShell Script Block Logging content that reconstructs strings at runtime from character codes or character arrays. This technique is commonly used to conceal intent (for example, commands, URLs, or file paths) and can indicate attempts to evade static inspection.
+
+Focus triage on what strings are being rebuilt, who ran the script, where it ran, and whether the decoded content leads to follow-on activity.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
+
+
+*Possible investigation steps*
+
+
+- Review `powershell.file.script_block_text` and use `Esql.script_block_tmp` to quickly spot the segments that triggered the match. Identify the reconstruction method (for example, `[char[]](...)`, repeated `([char]NN)+` concatenation, joins, or index-based lookups).
+- If the script block is split, reconstruct the full content using `powershell.file.script_block_id` together with `powershell.sequence` and `powershell.total`. Verify that all expected sequences are present and in order before drawing conclusions.
+- If `powershell.total` indicates multiple fragments but one or more `powershell.sequence` values are missing, treat the script as incomplete context. Attempt to retrieve the missing fragments and consider the possibility of log gaps or ingestion delays.
+- Deobfuscate the reconstructed strings by translating numeric character codes and arrays into their resulting text. Capture any decoded values that look like commands, script content, URLs, file paths, registry paths, or encoded blobs.
+- After decoding, re-review the full script block content for additional obfuscation layers or execution logic that is not covered by the character reconstruction pattern (for example, secondary decoding steps or dynamically-invoked script).
+- Use `Esql.script_block_pattern_count` as a quick measure of how heavily the script relies on this obfuscation pattern. Higher counts typically indicate more deliberate concealment and can help prioritize review.
+- Use the script statistics to support prioritization and comparison against expected baselines: `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_length`. Look for unusually long, high-entropy, or highly variable content relative to known-good PowerShell activity in your environment.
+- Review the execution context: `user.name`, `user.domain`, and `user.id` to understand who executed the script and whether the account matches expected administrative or automation usage for the `host.name` and `host.id` involved.
+- Review file origin indicators when present: `file.path`, `file.directory`, and `file.name`. Assess whether the script appears to originate from an expected location for your environment versus a user-writable, temporary, or unusual directory.
+- Pivot to the source event using `_id` and `_index` to review the full event payload and confirm whether additional relevant `powershell.file.*` context is available for analysis.
+- Scope for related activity by searching for additional script blocks that share the same `powershell.file.script_block_id`, similar `powershell.file.script_block_text` content, the same `file.path`, the same `user.id`, or the same `host.id` around the alert time window.
+- Correlate the alert timestamp with adjacent telemetry from the same host and user (process activity, network connections, file writes, registry modifications, and authentication events) to identify how PowerShell was launched (including the initiating/parent process) and what occurred immediately before and after the obfuscated content executed.
+- If decoded content indicates external communication or secondary payload retrieval, identify potential indicators (domains, IPs, URLs, file names) and check for additional occurrences across other hosts and users.
+- If decoded content indicates credential access, lateral movement, or persistence, expand the investigation to related accounts and hosts within the same timeframe and document the full execution chain.
+
+
+*False positive analysis*
+
+
+- Some benign scripts reconstruct strings from character codes for formatting, localization, or to safely represent special characters. These cases are often limited in scope and decode to human-readable, expected values.
+- Software deployment, management, or monitoring tooling may generate PowerShell dynamically and use string reconstruction as an implementation detail. Validate whether the script source (`file.path`) and execution context (`user.id`, `host.id`) align with known tooling behavior.
+- Internal scripts may use light obfuscation to reduce casual tampering or to embed configuration values. Treat unknown sources, unexpected accounts, or unusually high `Esql.script_block_pattern_count` / `powershell.file.script_block_entropy_bits` as higher risk until validated.
+- If determined benign, document the script source and expected execution context (account and host) and retain the decoded strings for faster triage of future alerts.
+
+
+*Response and remediation*
+
+
+- If malicious or suspicious activity is confirmed, contain the affected host to prevent additional execution and lateral movement. Consider restricting the involved account based on investigation results.
+- Preserve evidence: retain the full `powershell.file.script_block_text` and any reconstructed/decoded strings, along with related events for the same `powershell.file.script_block_id` (all `powershell.sequence` values).
+- If the script originates from disk (`file.path` present), collect and quarantine the referenced file and review for additional related artifacts created or modified around the alert time window.
+- Identify and remediate follow-on actions indicated by the decoded content (for example, downloaded payloads, persistence mechanisms, or changes to system configuration).
+- Hunt for spread: search for the same decoded indicators, similar reconstruction patterns, and elevated `Esql.script_block_pattern_count` across other hosts and users.
+- If account misuse is suspected, perform appropriate credential hygiene and review recent authentication activity for the affected `user.id` and related accounts.
+- Review and strengthen PowerShell controls and monitoring based on findings (for example, ensure Script Block Logging is consistently enabled and that anti-malware scanning integration is functioning as expected).
+
+
+==== 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]
+----------------------------------
+from logs-windows.powershell_operational* metadata _id, _version, _index
+| where event.code == "4104"
+
+// Filter for scripts that contain the "char" keyword using MATCH, boosts the query performance
+| where powershell.file.script_block_text : "char"
+
+// replace the patterns we are looking for with the 🔥 emoji to enable counting them
+// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1
+| eval Esql.script_block_tmp = replace(
+    powershell.file.script_block_text,
+    """(char\[\]\]\(\d+,\d+[^)]+|(\s?\(\[char\]\d+\s?\)\+){2,})""",
+    "🔥"
+)
+
+// count how many patterns were detected by calculating the number of 🔥 characters inserted
+| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", ""))
+
+// keep the fields relevant to the query, although this is not needed as the alert is populated using _id
+| keep
+    Esql.script_block_pattern_count,
+    Esql.script_block_tmp,
+    powershell.file.*,
+    file.path,
+    powershell.sequence,
+    powershell.total,
+    _id,
+    _version,
+    _index,
+    host.name,
+    host.id,
+    agent.id,
+    user.id
+
+// Filter for scripts that match the pattern at least once
+| where Esql.script_block_pattern_count >= 1
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc
new file mode 100644
index 0000000000..3c3f753d11
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc
@@ -0,0 +1,221 @@
+[[prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation]]
+=== Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation
+
+Detects PowerShell scripts that builds commands from concatenated string literals inside dynamic invocation constructs like &() or .(). Attackers use concatenated dynamic invocation to obscure execution intent, bypass keyword-based detections, and evade AMSI.
+
+*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: Defense Evasion
+* Data Source: PowerShell Logs
+* Resources: Investigation Guide
+
+*Version*: 9
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Obfuscation via Concatenated Dynamic Command Invocation*
+
+
+This rule identifies PowerShell script block content where a command is built from concatenated string literals and executed through dynamic invocation using the call operator (&) or dot invocation (.). This technique can hide the true command name (for example, splitting cmdlet, function, alias, or script names into fragments) and is often paired with additional obfuscation to hinder quick review.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
+
+
+*Possible investigation steps*
+
+
+- Establish scope and execution context:
+  - Review `host.name` and `host.id` to understand where the script ran, and identify whether the host is an admin workstation, server, or user endpoint.
+  - Review `user.name`, `user.domain`, and `user.id` to understand who initiated the activity and whether PowerShell use is expected for that identity.
+  - Use the alert timestamp to bound the activity window for correlation and scoping.
+
+- Reconstruct the dynamically invoked command(s):
+  - Review `powershell.file.script_block_text` and use `Esql.script_block_tmp` to quickly locate the dynamic invocation expression(s) inside the script block.
+  - Identify each invocation using `&(...)` or `.(...)` where multiple quoted strings are joined with `+`.
+  - Concatenate the quoted string fragments in their observed order to derive the effective command/function/script name being invoked.
+  - Use `Esql.script_block_pattern_count` to prioritize review; multiple dynamic concatenation invocations in the same script block generally indicate stronger intent to obscure execution.
+
+- Determine whether the operator changes execution semantics:
+  - For `&(...)` (call operator), focus on the command being executed and any arguments passed immediately before/after the invocation.
+  - For `.(...)` (dot invocation), assess whether the script is intended to run in the current scope (for example, to define or modify functions/variables) and whether that scope change is expected for the host and user context.
+
+- Reassemble full script content when fragmented:
+  - Pivot on `powershell.file.script_block_id` to locate other fragments of the same script block.
+  - If `powershell.total` indicates the content is split across multiple events, use `powershell.sequence` and `powershell.total` to reconstruct the full script block in order before making a determination.
+
+- Identify script origin and persistence opportunities:
+  - If `file.path`, `file.directory`, or `file.name` are present, determine whether the script block is associated with an on-disk script and whether its location aligns with approved administrative tooling or known automation paths.
+  - Treat unusual user-writable or temporary locations as higher risk, especially when paired with high `Esql.script_block_pattern_count`.
+
+- Evaluate obfuscation characteristics and intent:
+  - Use `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_length` to assess how atypical the content is compared to known-good scripts in your environment.
+  - Review surrounding logic in `powershell.file.script_block_text` for additional obfuscation patterns (for example, layered string operations, indirect invocation, or hidden payload material) that may not be captured by this specific match.
+
+- Correlate with adjacent endpoint activity (if available):
+  - Pivot using `host.id` and the alert time window to identify the PowerShell host process, its parent process, and any child processes that indicate follow-on execution.
+  - Review network, file, and registry activity on `host.id` around the same time for signs of payload retrieval, on-disk staging, persistence, or system configuration changes.
+  - Review authentication activity associated with `user.id` around the same time window for anomalous logons, new session sources, or unusual access patterns.
+  - Pivot on `user.id` to identify similar activity across other hosts, which may indicate shared automation, credential reuse, or lateral movement.
+
+- Capture and operationalize investigation artifacts:
+  - Document the reconstructed command strings, notable script fragments, and any referenced file locations (`file.path`) for escalation and threat hunting.
+  - Use those artifacts to search for additional occurrences across the environment, focusing on the same `user.id`, `host.id`, and similar `powershell.file.script_block_text` patterns.
+
+
+*False positive analysis*
+
+
+- Administrative scripts, modules, or internal frameworks that dynamically assemble short command names (cmdlets, functions, aliases) via string concatenation before invoking them for indirection or compatibility.
+- Legitimate automation that uses dot invocation to load or execute helper logic in the current scope, including scripts that intentionally reduce readability for code protection.
+
+
+*Response and remediation*
+
+
+- If the activity is confirmed or strongly suspected to be malicious or unauthorized:
+  - Contain the affected host identified by `host.id` to prevent further execution and potential lateral movement.
+  - Preserve evidence, including the full reconstructed `powershell.file.script_block_text` (using `powershell.sequence`/`powershell.total` if needed) and any associated on-disk script referenced by `file.path`.
+
+- If an on-disk script is involved (`file.path` present):
+  - Acquire the referenced script file for analysis and validate its provenance.
+  - Remove or quarantine the script if it is unauthorized, and assess for additional copies using the same `file.name` or `file.path` patterns across hosts.
+
+- If account misuse is suspected:
+  - Scope recent activity for the implicated `user.id` across hosts, prioritize investigation for privileged accounts, and reset credentials per policy.
+  - Review and reduce unnecessary privileges associated with the account, especially if PowerShell access is not required.
+
+- Eradication and recovery:
+  - Identify and remediate follow-on artifacts discovered during scoping (for example, dropped scripts/binaries or persistence mechanisms) using established response procedures.
+  - Increase monitoring for recurrence by hunting for similar dynamic concatenation patterns (high `Esql.script_block_pattern_count`) on the same `host.id` and `user.id`.
+
+- Post-incident hardening:
+  - Ensure PowerShell Script Block Logging coverage is consistently enabled and centrally collected for systems where PowerShell use is permitted.
+  - Limit PowerShell use to approved users and hosts, and review controls that reduce the impact of dynamic invocation and obfuscation in your environment.
+
+
+==== 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]
+----------------------------------
+from logs-windows.powershell_operational* metadata _id, _version, _index
+| where event.code == "4104" and powershell.file.script_block_text like "*+*"
+
+// replace the patterns we are looking for with the 🔥 emoji to enable counting them
+// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1
+| eval Esql.script_block_tmp = replace(
+    powershell.file.script_block_text,
+    """[.&]\(\s*(['"][A-Za-z0-9.-]+['"]\s*\+\s*)+['"][A-Za-z0-9.-]+['"]\s*\)""",
+    "🔥"
+)
+
+// count how many patterns were detected by calculating the number of 🔥 characters inserted
+| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", ""))
+
+// keep the fields relevant to the query, although this is not needed as the alert is populated using _id
+| keep
+    Esql.script_block_pattern_count,
+    Esql.script_block_tmp,
+    powershell.file.*,
+    file.path,
+    powershell.sequence,
+    powershell.total,
+    _id,
+    _version,
+    _index,
+    host.name,
+    host.id,
+    agent.id,
+    user.id
+
+// Filter for scripts that match the pattern at least once
+| where Esql.script_block_pattern_count >= 1
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc
new file mode 100644
index 0000000000..0f93fd306a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc
@@ -0,0 +1,208 @@
+[[prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-high-numeric-character-proportion]]
+=== Potential PowerShell Obfuscation via High Numeric Character Proportion
+
+Detects long PowerShell script block content with unusually high numeric character density (high digit-to-length ratio), often produced by byte arrays, character-code reconstruction, or embedded encoded blobs. Attackers use numeric-heavy obfuscation to conceal payloads and rebuild them at runtime to avoid static inspection.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: PowerShell Logs
+* Resources: Investigation Guide
+
+*Version*: 11
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Obfuscation via High Numeric Character Proportion*
+
+
+This rule flags long PowerShell script blocks with unusually digit-dense content. Numeric-heavy script blocks are often used to conceal payloads as byte arrays or character codes that are decoded at runtime. Triage should focus on reconstructing the full script content, determining how it was initiated, and identifying any decoded or executed secondary content.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_ratio`: Proportion of the script block's characters that match the alert's target character set, divided by total script length (0-1).
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
+
+
+*Possible investigation steps*
+
+
+- Review `powershell.file.script_block_text` to characterize the numeric content:
+  - Look for long comma-separated numbers, repeated digit sequences, or `0x`-prefixed values that may represent reconstructed bytes.
+  - Identify string reconstruction patterns (for example, casting numeric values to characters) and any subsequent decoding or decompression logic.
+  - Note any execution primitives that would run derived content (for example, invoking dynamically built commands or loading content into memory).
+- If the script is fragmented, use `powershell.sequence` and `powershell.total` to collect the related script block events on the same `host.name` and `user.id` and reconstruct the complete content in the correct order before drawing conclusions.
+- Establish execution context and scope using `host.name`, `host.id`, `agent.id`, and `user.id`:
+  - Determine whether the user context is expected to run PowerShell and whether similar script blocks have occurred recently on the same host or by the same user.
+  - Look for other alerts on the same host or user that could indicate staging, persistence, or lateral movement.
+- Assess script origin using `file.path` and `file.directory` when present:
+  - Determine whether the script is sourced from a location consistent with approved administration or automation workflows.
+  - If the script is file-backed, check for other security telemetry referencing the same path to identify file creation, modification, or repeated execution patterns.
+- Correlate with adjacent telemetry (as available in your environment) using the host and user pivots above:
+  - Process execution telemetry near the alert time to identify the PowerShell host process and its parent, and to understand how PowerShell was launched.
+  - Network telemetry for outbound connections or downloads that could support payload retrieval or command and control.
+  - File activity for dropped payloads or staging artifacts related to the script content or its on-disk source.
+
+
+*False positive analysis*
+
+
+- Legitimate scripts that embed binary content as numeric arrays (for example, packaging resources into scripts or deploying configuration blobs) can appear digit-dense.
+- Administrative tooling that generates large reports, inventories, or exports may include extensive numeric identifiers and constants.
+- Some legitimate security or management products may produce numeric-heavy PowerShell content as part of automation; validate against known software, expected execution accounts, and change windows.
+
+
+*Response and remediation*
+
+
+- If malicious behavior is suspected, contain the affected host to prevent further execution and reduce the risk of follow-on activity.
+- Preserve the script content from `powershell.file.script_block_text` (and any reconstructed multi-part content) for deeper analysis and to support incident response and retrospective hunting.
+- If `file.path` is present and the source is not authorized, remove or quarantine the script and investigate related host artifacts and execution mechanisms.
+- Investigate potential account compromise for the associated `user.id` by reviewing recent authentication and endpoint activity; take credential and session remediation actions in line with your procedures.
+- Hunt for related activity using `host.id`, `agent.id`, `user.id`, and distinctive script patterns identified during triage to find additional impacted systems.
+- Apply preventive controls based on findings, such as tightening PowerShell usage for affected accounts, improving script provenance controls, and enhancing monitoring for similar obfuscation patterns.
+
+
+==== 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]
+----------------------------------
+from logs-windows.powershell_operational* metadata _id, _version, _index
+| where event.code == "4104"
+
+// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for
+| eval Esql.script_block_length = length(powershell.file.script_block_text)
+| where Esql.script_block_length > 1000
+
+// replace the patterns we are looking for with the 🔥 emoji to enable counting them
+// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1
+| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, """[0-9]""", "🔥")
+
+// count how many patterns were detected by calculating the number of 🔥 characters inserted
+| eval Esql.script_block_pattern_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, "🔥", ""))
+
+// Calculate the ratio of special characters to total length
+| eval Esql.script_block_ratio = Esql.script_block_pattern_count::double / Esql.script_block_length::double
+
+// keep the fields relevant to the query, although this is not needed as the alert is populated using _id
+| keep
+    Esql.script_block_pattern_count,
+    Esql.script_block_ratio,
+    Esql.script_block_length,
+    Esql.script_block_tmp,
+    powershell.file.*,
+    file.directory,
+    file.path,
+    powershell.sequence,
+    powershell.total,
+    _id,
+    _version,
+    _index,
+    host.name,
+    host.id,
+    agent.id,
+    user.id
+
+// Filter for scripts with high numeric character ratio
+| where Esql.script_block_ratio > 0.5
+
+// Exclude Windows Defender Noisy Patterns
+| where not (
+    file.directory == "C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads" or
+    file.directory like (
+        "C:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\DataCollection*",
+        "C:\\\\Program Files\\\\SentinelOne\\\\Sentinel Agent*"
+    )
+  )
+  // ESQL requires this condition, otherwise it only returns matches where file.directory exists.
+  or file.directory is null
+| where not powershell.file.script_block_text like "*[System.IO.File]::Open('C:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\DataCollection*"
+| where not powershell.file.script_block_text : "26a24ae4-039d-4ca4-87b4-2f64180311f0"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc
new file mode 100644
index 0000000000..e459547817
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc
@@ -0,0 +1,226 @@
+[[prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-invalid-escape-sequences]]
+=== Potential PowerShell Obfuscation via Invalid Escape Sequences
+
+Detects PowerShell scripts with repeated invalid backtick escapes between word characters (letters, digits, underscore, or dash), splitting tokens while preserving execution. Attackers use this obfuscation to fragment keywords and evade pattern-based detection and AMSI.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: PowerShell Logs
+* Resources: Investigation Guide
+
+*Version*: 11
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Obfuscation via Invalid Escape Sequences*
+
+
+This rule flags PowerShell script block content that repeatedly inserts invalid backtick escape sequences within otherwise contiguous word characters. This can fragment tokens (cmdlets, parameters, variable names, strings) while preserving execution and readability to the interpreter, which can hinder content inspection and pattern-based detections.
+
+Analyst goals:
+- Reconstruct complete script block content when split across multiple events.
+- Normalize the content (remove or correct invalid escapes) to reveal the underlying logic.
+- Determine execution context (host, user, script origin) and correlate with adjacent activity to assess intent and impact.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
+
+
+*Possible investigation steps*
+
+
+- Establish timeline and ownership:
+  - Anchor the activity using `@timestamp`, then record `host.name`, `host.id`, and `agent.id`.
+  - Identify the execution context with `user.name`, `user.domain`, and `user.id`. Note whether the account is expected to run PowerShell on this host and whether the host is commonly used for scripting.
+
+- Assess the likelihood of intentional obfuscation:
+  - Review `Esql.script_block_pattern_count` to understand how heavily the content is fragmented. Higher counts generally increase confidence that this is deliberate obfuscation rather than incidental escaping.
+  - Use `powershell.file.script_block_length` as size context and review `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_surprisal_stdev` to characterize the content (simple text vs. mixed/randomized payloads).
+  - Compare `Esql.script_block_tmp` to `powershell.file.script_block_text` to understand where obfuscation is concentrated (localized string vs. widespread token fragmentation).
+
+- Reconstruct complete content when split across events:
+  - If `powershell.total` is greater than 1, pivot on `powershell.file.script_block_id` and rebuild the script by ordering segments on `powershell.sequence`.
+  - Validate the reconstructed set is complete (sequence 1 through `powershell.total`). Missing segments should be treated as an investigative gap and may require additional scoping.
+
+- Determine script origin and delivery:
+  - If `file.path`, `file.directory`, and `file.name` are present, treat the script block as file-associated. Evaluate whether the location and naming are consistent with approved scripts or expected tooling for the endpoint.
+  - If file fields are absent, treat the script as inline or dynamically generated content and prioritize correlation by `host.id`, `user.id`, and time.
+
+- Normalize and interpret the script content safely:
+  - In a controlled analysis workflow, normalize the script by removing or correcting invalid backtick insertions so that split tokens become readable. Keep both the original and normalized versions for reporting.
+  - Review the normalized text for behaviors that indicate malicious intent (secondary payload retrieval, dynamic execution, decoding/decompression, data collection, persistence logic, or remote interaction).
+  - Extract and document indicators present in the content (network destinations, file paths/names, unique strings, or embedded encoded blobs) for scoping.
+
+- Correlate within PowerShell telemetry:
+  - Pivot on `host.id` and `user.id` to identify additional `powershell.file.script_block_text` events shortly before and after the alert time to capture staging, follow-on commands, and potential cleanup.
+  - Check for the same `powershell.file.script_block_id` appearing across hosts, or for repeated normalized strings, to identify automation reuse or broader activity.
+
+- Correlate with adjacent endpoint activity (if available in your environment):
+  - Review process execution around `@timestamp` on `host.name` to identify the PowerShell host process and its parent, then assess whether the launch chain aligns with expected activity for the user and endpoint.
+  - Review network activity around the alert time for connections that align with indicators extracted from the script content.
+  - Review file and registry activity around the same time window for artifacts consistent with the script (new or modified scripts, dropped files, or persistence-related changes).
+  - Review authentication activity associated with `user.id` around the alert time for suspicious logons or remote access that may align with script execution.
+
+- Scope impact:
+  - Search for other alerts/events with similar obfuscation characteristics on the same host and for the same user to determine whether this is a one-off execution or a repeated pattern.
+  - If multiple hosts are involved, prioritize investigation for critical assets and accounts with elevated privileges.
+
+
+*False positive analysis*
+
+
+- Legitimate scripts can contain backticks for formatting, string construction, or content generation; however, repeated invalid escape sequences embedded inside alphanumeric tokens are uncommon. Validate whether the execution context (`host.id`, `user.id`) aligns with known administrative or developer activity.
+- Some commercial or internal tools intentionally obfuscate PowerShell to protect intellectual property. Confirm whether the script origin (`file.path` when present), account context, and prevalence across the environment match an approved application or workflow.
+- Copy/paste artifacts and encoding transformations can introduce unexpected characters. When suspected, compare the normalized content to known-good scripts and assess whether the obfuscation is systematic (repeating across many tokens) versus localized.
+
+
+*Response and remediation*
+
+
+- If the activity is confirmed or strongly suspected malicious:
+  - Contain affected host(s) to prevent further execution and lateral movement.
+  - Preserve evidence: reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and alert-derived fields (`Esql.script_block_tmp`, `Esql.script_block_pattern_count`, and the script block metrics).
+  - If `file.path` is present, collect and quarantine the referenced script and review the surrounding directory for related artifacts.
+  - Use indicators extracted from normalized content to scope related activity across endpoints (pivot on `host.id`, `user.id`, `file.path`, and unique strings from the script).
+  - Coordinate credential remediation for affected accounts when remote execution, credential material, or post-exploitation behavior is suspected.
+
+- If the activity is benign but requires reduction:
+  - Document the legitimate source (expected hosts/users and `file.path` when applicable).
+  - Apply narrowly scoped tuning using stable attributes available in the alert (such as `host.id`, `user.id`, and `file.path`) and continue monitoring for deviations in script content and execution context.
+
+
+==== 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]
+----------------------------------
+from logs-windows.powershell_operational* metadata _id, _version, _index
+| where event.code == "4104" and powershell.file.script_block_text like "*`*"
+
+// replace the patterns we are looking for with the 🔥 emoji to enable counting them
+// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1
+| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, """[A-Za-z0-9_-]`(?![rntb]|\r|\n|\d)[A-Za-z0-9_-]""", "🔥")
+
+// count how many patterns were detected by calculating the number of 🔥 characters inserted
+| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", ""))
+
+// keep the fields relevant to the query, although this is not needed as the alert is populated using _id
+| keep
+    Esql.script_block_pattern_count,
+    Esql.script_block_tmp,
+    powershell.file.*,
+    file.name,
+    file.directory,
+    file.path,
+    powershell.sequence,
+    powershell.total,
+    _id,
+    _version,
+    _index,
+    host.name,
+    host.id,
+    agent.id,
+    user.id
+
+// Filter for scripts that match the pattern at least 20 times
+| where Esql.script_block_pattern_count >= 20
+
+| where file.name not like "TSS_*.psm1"
+  // ESQL requires this condition, otherwise it only returns matches where file.name exists.
+  or file.name is null
+
+// VSCode Shell integration
+| where not powershell.file.script_block_text like "*$([char]0x1b)]633*"
+
+| where not file.directory == "C:\\Program Files\\MVPSI\\JAMS\\Agent\\Temp"
+  // ESQL requires this condition, otherwise it only returns matches where file.directory exists.
+  or file.directory is null
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-reverse-keywords.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-reverse-keywords.asciidoc
new file mode 100644
index 0000000000..9dea1619ca
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-reverse-keywords.asciidoc
@@ -0,0 +1,213 @@
+[[prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-reverse-keywords]]
+=== Potential PowerShell Obfuscation via Reverse Keywords
+
+Detects PowerShell scripts containing reversed keyword strings associated with execution or network activity (for example, ekovni, noisserpxe, daolnwod, tcejbo-wen, tcejboimw, etc.). Attackers reverse keywords and reconstruct them at runtime to hide intent and evade static detection and AMSI.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: PowerShell Logs
+* Resources: Investigation Guide
+
+*Version*: 10
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Obfuscation via Reverse Keywords*
+
+
+This alert indicates PowerShell script block content contains multiple reversed keyword strings commonly associated with execution, string manipulation, environment discovery, or networking. Reversing strings is frequently paired with runtime reconstruction (for example, reversing character arrays or joining string fragments) to reduce readability and evade simple content inspection.
+
+Determine whether the script is part of expected administrative automation, software tooling, or an unauthorized execution chain. Prioritize analysis that reconstructs the full script, deobfuscates the reversed tokens, and identifies any follow-on behaviors such as dynamic execution, network access, or system discovery.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
+
+
+*Possible investigation steps*
+
+
+- Identify the execution scope and ownership:
+  - Review `host.name` / `host.id` to confirm the affected endpoint and its criticality.
+  - Review `user.id` (and `user.name` / `user.domain` if available) to understand the account context and whether this user is expected to run PowerShell on this host.
+- Prioritize based on obfuscation signals:
+  - Review `Esql.script_block_pattern_count`; higher counts suggest more extensive keyword hiding and can increase suspicion.
+  - Use `powershell.file.script_block_length`, `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_surprisal_stdev` to gauge how heavily obfuscated or machine-generated the content may be (treat these as supporting context, not proof of maliciousness).
+- Reconstruct the full script content when split:
+  - If `powershell.total` is greater than 1, retrieve all events with the same `powershell.file.script_block_id` and order them by `powershell.sequence` to rebuild the complete script block content.
+  - Preserve both the reconstructed script and the original per-event `powershell.file.script_block_text` to maintain context and ordering.
+- Deobfuscate and interpret intent:
+  - Review `powershell.file.script_block_text` for reversed tokens and reverse them to identify the intended keywords and operations (for example, indicators of dynamic execution, downloads, socket/connection handling, WMI usage, or Win32 references).
+  - Look for runtime string reconstruction patterns in the script content (for example, joins, character array operations, or replace operations) that turn reversed fragments into executable commands or parameters.
+  - Use `Esql.script_block_tmp` to quickly locate the matched areas, then validate findings against `powershell.file.script_block_text`.
+- Evaluate file-origin context (when present):
+  - Review `file.path` (and `file.directory` / `file.name` if available) to determine whether the script is associated with an on-disk file and whether that location aligns with your organization's expected script locations and deployment practices.
+  - If an on-disk script is indicated, coordinate collection of the referenced file for offline analysis and determine whether it is present on other systems.
+- Extract and operationalize indicators:
+  - From `powershell.file.script_block_text`, extract any embedded indicators such as hostnames, IP addresses, URLs, ports, file paths, or encoded blobs.
+  - Use extracted indicators to scope for related activity on the same `host.id` and across other hosts where the same `user.id` is active, focusing on the alert timeframe and immediately adjacent activity.
+- Correlate with adjacent telemetry to identify the execution chain and impact (as available in your environment):
+  - Process activity: identify the PowerShell host process and the initiating parent process to understand whether execution was interactive, scheduled, or launched by another program.
+  - Network activity: look for outbound connections aligned with the alert timestamp, especially if deobfuscated content suggests downloads or socket connections.
+  - File and registry activity: look for payload staging, new or modified files, or persistence-related changes that occur shortly after the script block execution.
+  - Authentication activity: review for suspicious logons, remote session creation, or lateral movement attempts around the same time on the affected host.
+- Determine severity and next actions:
+  - If the deobfuscated content indicates remote retrieval, execution of downloaded content, credential access, persistence, or lateral movement, treat the alert as potentially malicious and escalate for response.
+  - If the script appears benign, document the validated purpose, expected owner, and any recurring identifiers (such as file location patterns) to support future triage.
+
+
+*False positive analysis*
+
+
+- Internal scripts or tooling may use reversed strings as lightweight obfuscation to conceal configuration values or reduce casual readability. Validate the script's ownership, change history, and whether its presence and execution timing are expected for `host.id` and `user.id`.
+- Commercial software, endpoint management agents, or security tooling may generate or embed obfuscated PowerShell during installation, updates, or health checks. Validate whether the activity aligns with known maintenance windows, expected endpoints, and consistent script content and `file.path` patterns.
+- Authorized security testing may intentionally use string reversal. Confirm the scope, timing, and target hosts with the appropriate stakeholders before closing the alert.
+
+
+*Response and remediation*
+
+
+- If activity is suspicious or unauthorized, contain the affected host to prevent further script execution and potential follow-on actions.
+- Preserve evidence:
+  - Retain the full `powershell.file.script_block_text` (including all segments reconstructed via `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`).
+  - Retain `file.path` context and the alert metadata needed to pivot (such as `host.id` and `user.id`).
+- Identify and remediate the execution source:
+  - Determine how PowerShell was launched (interactive, scheduled, or by another process) using correlated telemetry, and remove the triggering mechanism.
+  - If an on-disk script is involved, remediate the file at `file.path` and any associated payloads or artifacts identified during analysis.
+- Scope and hunt:
+  - Search for the same or similar obfuscated content and extracted indicators across other endpoints, prioritizing systems accessed by the same `user.id` and systems with similar `file.path` patterns.
+- Account actions:
+  - If account misuse is suspected, follow organizational procedures to contain the account (for example, credential reset and session revocation) and review recent activity for additional suspicious behavior.
+- Recovery and hardening:
+  - Verify PowerShell logging coverage and retention are sufficient for incident response, and monitor for recurrence of similar reversed-keyword patterns on affected hosts and users.
+
+
+==== 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]
+----------------------------------
+from logs-windows.powershell_operational* metadata _id, _version, _index
+| where event.code == "4104"
+
+// Filter for scripts that contains these keywords using MATCH, boosts the query performance,
+// match will ignore the | and look for the individual words
+| where powershell.file.script_block_text : "rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman|vne|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod"
+
+// replace the patterns we are looking for with the 🔥 emoji to enable counting them
+// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1
+| eval Esql.script_block_tmp = replace(
+    powershell.file.script_block_text,
+    """(?i)(rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman\.|:vne$|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod)""",
+    "🔥"
+)
+
+// count how many patterns were detected by calculating the number of 🔥 characters inserted
+| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", ""))
+
+// keep the fields relevant to the query, although this is not needed as the alert is populated using _id
+| keep
+    Esql.script_block_pattern_count,
+    Esql.script_block_tmp,
+    powershell.file.*,
+    file.path,
+    powershell.sequence,
+    powershell.total,
+    _id,
+    _version,
+    _index,
+    host.name,
+    host.id,
+    agent.id,
+    user.id
+
+// Filter for scripts that match the pattern at least twice
+| where Esql.script_block_pattern_count >= 2
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-special-character-overuse.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-special-character-overuse.asciidoc
new file mode 100644
index 0000000000..52c746ecc0
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-special-character-overuse.asciidoc
@@ -0,0 +1,227 @@
+[[prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-special-character-overuse]]
+=== Potential PowerShell Obfuscation via Special Character Overuse
+
+Detects PowerShell scripts dominated by whitespace and special characters with low symbol diversity, a profile often produced by formatting or encoding obfuscation. Attackers use symbol-heavy encoding or formatting (for example, SecureString-style blobs or character-level transforms) to hide payloads and evade static analysis and AMSI.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: PowerShell Logs
+* Resources: Investigation Guide
+
+*Version*: 10
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Obfuscation via Special Character Overuse*
+
+
+This rule flags PowerShell script block content that is unusually long and dominated by whitespace and a narrow set of special characters. This profile is often associated with formatting or encoding obfuscation where payload logic is transformed into symbol-heavy strings and reconstructed at runtime. Use the steps below to validate execution context, reconstruct full content, determine likely intent, and scope related activity.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_ratio`: Proportion of the script block's characters that match the alert's target character set, divided by total script length (0-1).
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
+
+
+*Possible investigation steps*
+
+
+- Review alert context and scope:
+  - Use `@timestamp` to identify when the activity occurred and to bound the timeline for correlation.
+  - Review `host.name` and `host.id` to understand which endpoint produced the script block.
+  - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to run PowerShell on this host.
+  - If multiple alerts are present, group by `host.id` and `user.id` to identify concentrated or repeat activity.
+
+- Analyze the script block content for obfuscation and intent:
+  - Inspect `powershell.file.script_block_text` to understand what is being executed. Obfuscation commonly presents as large blocks of escaped characters, excessive punctuation, and character-level reassembly.
+  - Use `Esql.script_block_tmp` to quickly locate symbol-dense regions, then interpret the corresponding content in `powershell.file.script_block_text`.
+  - Use `Esql.script_block_ratio`, `powershell.file.script_block_unique_symbols`, `powershell.file.script_block_entropy_bits`, and `powershell.file.script_block_surprisal_stdev` to gauge how atypical the content is compared to known-good scripts in your environment.
+  - Identify deobfuscation and runtime execution patterns such as repeated string replacement, concatenation, `[char]` casting, `-join`, formatting operators, reflection, and dynamic invocation (for example, `Invoke-Expression` or executing decoded strings).
+  - Capture any embedded indicators from `powershell.file.script_block_text`, including URLs, hostnames, IP addresses, file paths, registry paths, or scheduled task/service names.
+
+- Reconstruct full script content when logged in chunks:
+  - If `powershell.total` indicates multiple fragments, pivot on `powershell.file.script_block_id` and reassemble the script in `powershell.sequence` order.
+  - Confirm completeness by comparing observed fragments to `powershell.total`. Missing segments can hide key decode or execution stages.
+
+- Validate script origin and expected usage:
+  - Review `file.path`, `file.directory`, and `file.name` (when present) to determine whether the script originated from disk, a module path, or an unusual location.
+  - If the script is file-backed, assess whether the file location and naming are consistent with approved administration and automation practices for the host and user.
+
+- Scope for related PowerShell activity:
+  - Pivot on `powershell.file.script_block_hash` (when available) to identify repeated executions of the same content across hosts and users.
+  - Review additional script blocks on the same `host.id` and `user.id` around the alert time for staging behavior (variable setup, decoding routines, or creation of additional script blocks).
+  - Use stable substrings from `powershell.file.script_block_text` (unique function names or strings) to find related executions that may not match this specific obfuscation profile.
+
+- Correlate with adjacent telemetry to confirm execution chain and impact (if available):
+  - Use `host.id`, `user.id`, and `@timestamp` to pivot into process telemetry and determine which process initiated PowerShell and whether the parent process is expected.
+  - Review activity on the same host around the alert time for signs of follow-on behavior such as outbound connections, file creation/modification, registry changes, or persistence mechanisms consistent with the recovered script logic.
+
+
+*False positive analysis*
+
+
+- Legitimate automation can embed large protected or serialized values (for example, encrypted configuration blobs or SecureString exports) that appear symbol-heavy.
+- Deployment and configuration tooling may generate templated PowerShell with extensive escaping or large here-strings, especially when embedding JSON/XML or code as data.
+- Authorized security testing may use obfuscation techniques that resemble this behavior.
+- To validate a benign source, confirm the script's provenance and repeatability:
+  - Check whether `file.path` (when present) and `powershell.file.script_block_hash` consistently map to an approved script, owner, and expected execution pattern.
+  - Compare the alerting `user.id` and `host.id` against known automation accounts and managed endpoints; unexpected combinations warrant escalation.
+
+
+*Response and remediation*
+
+
+- If malicious or suspicious activity is confirmed:
+  - Contain the affected host according to your incident response procedures to prevent additional execution and lateral movement.
+  - Preserve evidence for triage and forensics, including `powershell.file.script_block_text` (and any reconstructed content), `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, `powershell.file.script_block_hash` (if available), `file.path` (if present), and the execution context (`host.name`, `host.id`, `user.name`, `user.domain`, `user.id`, `agent.id`, `@timestamp`).
+  - Scope the activity by searching for the same `powershell.file.script_block_hash` and any extracted indicators across the environment.
+  - Identify and remediate follow-on actions associated with the script (downloaded payloads, dropped files, persistence changes, or credential access). Apply blocking controls for confirmed indicators where feasible.
+  - If the script content indicates credential material handling or unauthorized automation, rotate affected credentials and review account activity for misuse.
+
+- If the activity is determined to be benign:
+  - Document the script owner, purpose, and expected execution context (hosts, users, and schedule), using `file.path` and `powershell.file.script_block_hash` (when available) as stable identifiers.
+  - Monitor for drift, such as execution by different users/hosts, unexpected file paths, or material changes in the script block content.
+
+
+==== 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
+
+This rule uses the following fields that require the Windows Integration v3.3.0 and up: `powershell.file.script_block_unique_symbols`.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-windows.powershell_operational* metadata _id, _version, _index
+| where event.code == "4104"
+
+// filter for scripts with low unique symbol counts, which can indicate special character obfuscation
+| where powershell.file.script_block_unique_symbols < 50
+
+// replace repeated spaces used for formatting after a new line with a single space to reduce FPs
+| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, """\n\s+""", "\n ")
+
+// Look for scripts with more than 1000 chars
+| eval Esql.script_block_length = length(Esql.script_block_tmp)
+| where Esql.script_block_length > 1000
+
+// replace the patterns we are looking for with the 🔥 emoji to enable counting them
+// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1
+| eval Esql.script_block_tmp = replace(
+    Esql.script_block_tmp,
+    """[\s\$\{\}\+\@\=\(\)\^\\\"~\[\]\?\./%#\`\'\;\-\!\*]""",
+    "🔥"
+)
+
+// count how many patterns were detected by calculating the number of 🔥 characters inserted
+| eval Esql.script_block_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, "🔥", ""))
+
+// Calculate the ratio of special characters to total length
+| eval Esql.script_block_ratio = Esql.script_block_count::double / Esql.script_block_length::double
+
+// keep the fields relevant to the query, although this is not needed as the alert is populated using _id
+| keep
+    Esql.script_block_count,
+    Esql.script_block_length,
+    Esql.script_block_ratio,
+    Esql.script_block_tmp,
+    powershell.file.*,
+    file.path,
+    powershell.sequence,
+    powershell.total,
+    _id,
+    _version,
+    _index,
+    host.name,
+    host.id,
+    agent.id,
+    user.id
+
+// Filter for scripts with high whitespace and special character ratio
+| where Esql.script_block_ratio >= 0.75
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-string-concatenation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-string-concatenation.asciidoc
new file mode 100644
index 0000000000..6f8fa04347
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-string-concatenation.asciidoc
@@ -0,0 +1,213 @@
+[[prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-string-concatenation]]
+=== Potential PowerShell Obfuscation via String Concatenation
+
+Detects PowerShell scripts that repeatedly concatenates multiple quoted string literals with + to assemble commands or tokens at runtime. Attackers use string concatenation to fragment keywords or URLs and evade static analysis and AMSI.
+
+*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: Defense Evasion
+* Data Source: PowerShell Logs
+* Resources: Investigation Guide
+
+*Version*: 10
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Obfuscation via String Concatenation*
+
+
+This rule identifies PowerShell script block content that uses repeated concatenation of quoted string literals. This technique is commonly used to fragment keywords, URLs, and command text so they are assembled only at runtime. Focus the investigation on reconstructing the final strings, understanding how they are used within the script, and scoping related activity from the same host and user.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
+
+
+*Possible investigation steps*
+
+
+- Establish alert context and prioritize review:
+  - Review `host.name` / `host.id` and `user.name` / `user.domain` / `user.id` to understand where and under which account the script executed.
+  - Use `Esql.script_block_pattern_count` to gauge how heavily the script relies on concatenation. Higher counts can indicate more deliberate obfuscation.
+  - Review `powershell.file.script_block_length` and the statistical fields (`powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, `powershell.file.script_block_unique_symbols`) to assess whether the script contains high-variance or high-randomness content that may indicate encoding, packing, or layered obfuscation.
+
+- Identify the most likely script origin:
+  - Review `file.path`, `file.directory`, and `file.name` (when present) to determine whether the script block content was sourced from an on-disk script. Note whether the location is expected for administrative tooling or is user-writable/unusual for the host role.
+  - If file origin fields are not populated, treat the activity as potentially inline/interactive execution and prioritize identifying what initiated it through correlation with surrounding telemetry.
+
+- Recover the assembled strings and intent:
+  - Start with `Esql.script_block_tmp` to find where concatenation patterns occur, then inspect the surrounding text in `powershell.file.script_block_text` for the full logic.
+  - Reconstruct concatenated literals by joining the quoted fragments (preserving ordering and separators) to reveal the final keywords, paths, URLs, arguments, or identifiers the script is attempting to hide.
+  - Look for how reconstructed strings are used, especially:
+    - Dynamic invocation of reconstructed commands or expressions.
+    - Download or retrieval of remote content.
+    - Decoding/decryption routines and second-stage content handling.
+    - Construction of file paths, scheduled execution artifacts, or configuration changes.
+  - Capture any reconstructed indicators (domains, URLs, file names, directories, command fragments) that can be used to scope other activity.
+
+- Reconstruct full script content when split across events:
+  - Pivot on `powershell.file.script_block_id` to collect related script block events from the same execution context.
+  - If `powershell.total` is greater than 1, gather all fragments and order them by `powershell.sequence` to rebuild the complete script content before making a final determination.
+  - Review whether additional script blocks were executed in close succession by the same `user.id` on the same `host.id`, which may indicate staging or multi-step execution.
+
+- Scope the activity across hosts and accounts:
+  - On the same `host.id`, look for other script blocks that share the same `file.path` or distinctive reconstructed strings to determine if this is a single run or repeated behavior.
+  - Pivot on `user.id` to identify the same technique on other endpoints, which can indicate credential misuse or automated distribution.
+
+- Correlate with adjacent telemetry (as available in your environment):
+  - Process execution: identify the PowerShell host process and its parent process near the alert time to determine whether execution was interactive or spawned by another program.
+  - Network activity: if reconstructed strings include URLs/domains, check for outbound connections, downloads, or callbacks that align with the alert timeframe.
+  - Host changes: review nearby file and registry activity for payload drops, persistence creation, or configuration changes that match reconstructed paths or names.
+  - Authentication: review recent logon activity for `user.id` and `host.id` for anomalies that may explain the execution (new logon source, unusual logon type, or unexpected access patterns).
+
+
+*False positive analysis*
+
+
+- Legitimate administrative or operational scripts may concatenate many string literals to generate dynamic content (for example, configuration files, templated output, or complex argument strings). Validate whether the reconstructed strings align with expected internal tooling and whether the execution context (`host.id`, `user.id`, and `file.path`) matches normal operations.
+
+
+*Response and remediation*
+
+
+- If malicious or suspicious activity is confirmed:
+  - Contain the affected host to prevent follow-on execution or lateral movement.
+  - Preserve evidence from the alert, including `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence` / `powershell.total`, and any `file.path` details that indicate script origin.
+  - Use reconstructed strings to scope across the environment for related script blocks and any referenced artifacts (additional scripts, payload files, or remote destinations).
+  - Identify and remediate the initial execution vector by tracing the execution chain (user context and initiating process) and removing any persistence mechanisms discovered during investigation.
+  - If account compromise is suspected, reset credentials for the affected `user.id`, review recent access patterns, and apply least-privilege controls to limit further abuse.
+
+- If the activity is determined to be benign:
+  - Document the script purpose, expected execution context, and the specific concatenated strings that explain the detection.
+  - Monitor for deviations from the established baseline (new hosts, new accounts, unexpected file paths, or substantially different reconstructed content).
+
+
+==== 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]
+----------------------------------
+from logs-windows.powershell_operational* metadata _id, _version, _index
+| where event.code == "4104"
+
+// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for
+| eval Esql.script_block_length = length(powershell.file.script_block_text)
+| where Esql.script_block_length > 500
+
+// replace the patterns we are looking for with the 🔥 emoji to enable counting them
+// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1
+| eval Esql.script_block_tmp = replace(
+    powershell.file.script_block_text,
+    """['"][A-Za-z0-9.]+['"](\s?\+\s?['"][A-Za-z0-9.,\-\s]+['"]){2,}""",
+    "🔥"
+)
+
+// count how many patterns were detected by calculating the number of 🔥 characters inserted
+| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", ""))
+
+// keep the fields relevant to the query, although this is not needed as the alert is populated using _id
+| keep
+    Esql.script_block_pattern_count,
+    Esql.script_block_length,
+    Esql.script_block_tmp,
+    powershell.file.*,
+    file.path,
+    powershell.sequence,
+    powershell.total,
+    _id,
+    _version,
+    _index,
+    host.name,
+    host.id,
+    agent.id,
+    user.id
+
+// Filter for scripts that match the pattern at least twice
+| where Esql.script_block_pattern_count >= 2
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-string-reordering.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-string-reordering.asciidoc
new file mode 100644
index 0000000000..e756a7db7c
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-string-reordering.asciidoc
@@ -0,0 +1,235 @@
+[[prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-string-reordering]]
+=== Potential PowerShell Obfuscation via String Reordering
+
+Detects PowerShell scripts that uses format placeholders like "{0}{1}" with the -f operator or ::Format to reorder strings at runtime. Attackers use format-based reconstruction to hide commands or payload strings and evade static analysis and AMSI.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: PowerShell Logs
+* Resources: Investigation Guide
+
+*Version*: 12
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Obfuscation via String Reordering*
+
+
+This alert indicates a PowerShell script block used indexed format placeholders (for example, "{0}{1}") with runtime formatting (for example, the `-f` operator or `::Format`) to reorder and reconstruct strings. This technique can hide meaningful strings (commands, URLs, artifact names) from straightforward text inspection and can be used as part of staged execution.
+
+Because the detection requires repeated occurrences of these patterns in a larger script block, triage should focus on (1) execution context (host and user), (2) script origin (file-backed vs. in-memory/interactive), and (3) what strings are being reconstructed and what actions they enable.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
+
+
+*Possible investigation steps*
+
+
+- Confirm the execution context and initial scope:
+  - Identify the affected endpoint using `host.name` and `host.id`. Check for other security alerts or suspicious activity on the same host around the alert time.
+  - Identify the account context using `user.name`, `user.domain`, and `user.id`. Prioritize alerts where the user is unexpected for the host role or where the user does not typically run PowerShell.
+  - If `file.path` / `file.directory` / `file.name` are present, capture the script location and assess whether the path and filename are expected for that host and user. If file fields are missing, treat the activity as potentially interactive or in-memory and increase emphasis on correlated telemetry.
+
+- Review the script block content and determine what is being reconstructed:
+  - Start with `Esql.script_block_tmp` to quickly locate where formatting patterns occur, then use `powershell.file.script_block_text` as the authoritative source for analysis and evidence.
+  - Identify how formatting is used:
+    - Placeholder-only or placeholder-heavy format strings that primarily consist of `{n}` tokens.
+    - Out-of-order placeholder indexes (for example, `{3}{0}{2}{1}`) and repeated reordering blocks.
+    - Multiple reconstruction stages where formatted output is subsequently reformatted or concatenated.
+  - Reconstruct key strings by mapping placeholder indexes to the arguments/fragments used in each formatting operation. Record any reconstructed strings that indicate follow-on behavior (remote addresses, filenames, persistence identifiers, or execution flow).
+
+- Use the available scoring and statistics fields to guide prioritization:
+  - Review `Esql.script_block_pattern_count` to understand how heavily the script relies on formatting-based reconstruction. Higher counts generally increase suspicion.
+  - Review `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_length` to differentiate structured, readable scripts from highly variable or packed content.
+  - Treat these values as supporting signals; base the decision primarily on reconstructed strings and correlated activity.
+
+- Reconstruct full script content when split across multiple events:
+  - Pivot on `powershell.file.script_block_id` to gather all fragments for the same script block.
+  - Order fragments using `powershell.sequence` and confirm completeness using `powershell.total` before drawing conclusions.
+
+- Correlate and validate impact using adjacent telemetry available in your environment:
+  - Review other PowerShell script blocks from the same `host.id` and `user.id` to identify staging, deobfuscation, or follow-on execution.
+  - Correlate with endpoint telemetry for the same host and timeframe to understand how PowerShell was started and what occurred next (process ancestry, network activity, file/registry changes, and authentication activity). Use reconstructed strings to focus this correlation.
+
+- Expand the hunt to assess prevalence:
+  - Search for the same or similar content in `powershell.file.script_block_text` (shared fragments, repeated placeholder patterns) across other hosts.
+  - Use `Esql.script_block_pattern_count` and the script block statistics fields to identify other high-similarity or high-complexity scripts that may represent the same technique.
+
+
+*False positive analysis*
+
+
+- Legitimate automation can use indexed placeholders to build dynamic output, reports, or templated configuration content. Benign usage is more likely when the resulting strings are human-readable and the script has an expected on-disk origin (`file.path` / `file.name`) and consistent execution over time.
+- Some internally developed frameworks generate PowerShell dynamically and may include repeated formatting patterns. Validate ownership of the script source and whether execution by the identified `user.id` on the identified `host.id` is expected.
+- Localization or templating logic may use indexed placeholders. This is typically associated with readable templates and stable execution patterns rather than multi-stage reconstruction of operational strings.
+
+
+*Response and remediation*
+
+
+- If malicious or suspicious activity is confirmed:
+  - Contain the affected endpoint identified by `host.name` / `host.id` to prevent further execution and limit lateral movement.
+  - Preserve evidence, including `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and the alert enrichment fields (`Esql.script_block_tmp`, `Esql.script_block_pattern_count`, and script block statistics).
+  - Use reconstructed strings to drive scoping and impact assessment (look for related activity on the same host, and search for the same indicators across other hosts and users).
+
+- Eradication and recovery:
+  - Identify the execution mechanism and remove it (for example, an unexpected script file, a startup trigger, or other persistence identified during correlation).
+  - Remove or quarantine related artifacts discovered during analysis and validate that similar activity is not occurring on other endpoints.
+
+- If the activity is determined to be benign:
+  - Document the expected script source (`file.path` / `file.name`), the responsible team, and the expected execution context (`host.id`, `user.id`) to support faster triage of future alerts.
+  - Monitor for deviations from the established baseline (new hosts, new users, or materially different reconstructed strings).
+
+
+==== 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]
+----------------------------------
+from logs-windows.powershell_operational* metadata _id, _version, _index
+| where event.code == "4104" and powershell.file.script_block_text like "*{0}*"
+
+// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for
+| eval Esql.script_block_length = length(powershell.file.script_block_text)
+| where Esql.script_block_length > 500
+
+// replace the patterns we are looking for with the 🔥 emoji to enable counting them
+// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1
+| eval Esql.script_block_tmp = replace(
+    powershell.file.script_block_text,
+    """((\{\d+\}){2,}["']\s?-f|::Format[^\{]+(\{\d+\}){2,})""",
+    "🔥"
+)
+
+// count how many patterns were detected by calculating the number of 🔥 characters inserted
+| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", ""))
+
+// keep the fields relevant to the query, although this is not needed as the alert is populated using _id
+| keep
+    Esql.script_block_pattern_count,
+    Esql.script_block_length,
+    Esql.script_block_tmp,
+    powershell.file.*,
+    file.path,
+    file.directory,
+    powershell.sequence,
+    powershell.total,
+    _id,
+    _version,
+    _index,
+    host.name,
+    host.id,
+    agent.id,
+    user.id
+
+// Filter for scripts that match the pattern at least five times
+| where Esql.script_block_pattern_count >= 5
+
+// Exclude Noisy Patterns
+
+// Icinga Framework
+| where not file.directory == "C:\\Program Files\\WindowsPowerShell\\Modules\\icinga-powershell-framework\\cache"
+  // ESQL requires this condition, otherwise it only returns matches where file.directory exists.
+  or file.directory IS NULL
+
+| where not (powershell.file.script_block_text LIKE "*GitBranchStatus*" AND 
+    powershell.file.script_block_text LIKE "*$s.BranchBehindStatusSymbol.Text*")
+| where not
+    // https://wtfbins.wtf/17
+    (
+        (powershell.file.script_block_text like "*sentinelbreakpoints*" or
+         powershell.file.script_block_text like "*:::::\\\\windows\\\\sentinel*")
+        and
+        (powershell.file.script_block_text like "*$local:Bypassed*" or
+         powershell.file.script_block_text like "*origPSExecutionPolicyPreference*")
+    )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-process-injection-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-process-injection-via-powershell.asciidoc
new file mode 100644
index 0000000000..3850f593a8
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-process-injection-via-powershell.asciidoc
@@ -0,0 +1,198 @@
+[[prebuilt-rule-8-19-16-potential-process-injection-via-powershell]]
+=== Potential Process Injection via PowerShell
+
+Detects PowerShell scripts that combines Win32 APIs for allocation/protection or process access (for example, VirtualAlloc/VirtualProtect/OpenProcess/AdjustTokenPrivileges/LoadLibrary/GetProcAddress) with injection or execution APIs (WriteProcessMemory/CreateRemoteThread/NtCreateThreadEx/QueueUserAPC/ResumeThread). Attackers use these API chains to inject code into remote processes and execute payloads in memory for defense evasion.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.powershell*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://github.com/EmpireProject/Empire/blob/master/data/module_source/management/Invoke-PSInject.ps1
+* https://github.com/EmpireProject/Empire/blob/master/data/module_source/management/Invoke-ReflectivePEInjection.ps1
+* https://github.com/BC-SECURITY/Empire/blob/master/empire/server/data/module_source/credentials/Invoke-Mimikatz.ps1
+* https://www.elastic.co/security-labs/detect-credential-access
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Tactic: Execution
+* Resources: Investigation Guide
+* Data Source: PowerShell Logs
+
+*Version*: 217
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Process Injection via PowerShell*
+
+
+This rule Detects PowerShell scripts that references a combination of Win32 APIs commonly used to open a target process, allocate or change memory protections, write data into another process, and execute it via a remote thread or APC. This behavior is frequently associated with process injection and in-memory payload execution on Windows hosts.
+
+
+*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 and preserve the script content:
+  - Inspect `powershell.file.script_block_text` for the full API chain and surrounding logic (function definitions, payload construction, and execution flow).
+  - If the content is split across multiple events, reconstruct it by grouping on `powershell.file.script_block_id`, ordering by `powershell.sequence`, and validating completeness with `powershell.total`. Preserve the reconstructed content for follow-up analysis.
+  - Use `powershell.file.script_block_length` to help gauge whether the script is a small launcher or a larger framework with embedded payloads.
+
+- Identify the injection technique and likely target:
+  - Determine which execution primitive is being used (for example, `CreateRemoteThread`, `NtCreateThreadEx`, `QueueUserAPC`, or thread `SuspendThread`/`ResumeThread` patterns) and whether it suggests immediate or deferred execution.
+  - Look for how the target process is selected (process name strings, PID variables, or process enumeration logic) and capture any referenced process names or IDs for scoping.
+  - Note any privilege manipulation via `OpenProcessToken` and `AdjustTokenPrivileges`, which can indicate attempts to access protected processes.
+
+- Assess how native APIs are being invoked:
+  - Identify dynamic resolution patterns such as `LoadLibrary*`/`LdrLoadDll` with `GetProcAddress`, which are commonly used to avoid static imports and hinder analysis.
+  - If `GetDelegateForFunctionPointer` is present, review the surrounding text for delegate definitions and indirect invocation logic.
+
+- Validate execution context and script provenance:
+  - Review `user.name`, `user.domain`, and `user.id` for signs of unusual execution (unexpected account type, first-time observation on the host, or activity outside expected administrative workflows).
+  - Review `host.name` and `host.id` to understand the asset impacted and whether the behavior aligns with the host's role in your environment.
+  - If `file.path`, `file.directory`, or `file.name` are populated, assess whether the script originated from a controlled location and naming convention, or from a user-writable or temporary location.
+
+- Scope related PowerShell activity:
+  - On the same `host.id` and `user.id`, review additional script block events near `@timestamp` to identify staging actions that commonly bracket injection attempts (download, decode/decrypt, reflective loading, or cleanup).
+  - Search for repeated use of distinctive substrings from `powershell.file.script_block_text` across other hosts or users to determine prevalence and potential reuse.
+
+- Correlate with adjacent host telemetry (if available in your environment):
+  - Pivot from `host.name` and `@timestamp` to process activity to identify the PowerShell host process, its parent process, and any processes that may have been targeted for injection.
+  - Review network activity from the same `host.name` around the alert time for potential payload retrieval, command-and-control, or lateral movement.
+  - Review file activity related to `file.path` (when present) and for any new or modified scripts or binaries referenced by the script block.
+
+- Make a disposition:
+  - Treat as higher risk when the script combines process access (`OpenProcess`), memory modification (`VirtualAlloc*`/`VirtualProtect`), and execution (`CreateRemoteThread`/`NtCreateThreadEx`/`QueueUserAPC`), especially when coupled with privilege adjustment or dynamic API resolution.
+  - Treat as lower risk only when there is a clear, documented administrative or testing justification tied to the same `user.id`, `host.id`, and script origin.
+
+
+*False positive analysis*
+
+
+- Legitimate PowerShell can use Win32 API interop for diagnostics, automation, or compatibility work; however, the combination of remote memory operations and remote execution APIs is uncommon in routine administration.
+- Developer tooling or monitoring frameworks may load libraries or resolve symbols dynamically; validate that the script content aligns with expected tool behavior and that the script origin (`file.path`/`file.name`) is consistent and controlled.
+
+
+*Response and remediation*
+
+
+- If the activity is confirmed or strongly suspected malicious:
+  - Contain the affected host to prevent follow-on actions and lateral movement.
+  - Preserve evidence by retaining the reconstructed `powershell.file.script_block_text` (and associated `powershell.file.script_block_id`) and recording the alert context (`user.*`, `host.*`, and `file.*` where present).
+  - Identify the intended injection target from the script content and investigate that process and its recent activity for signs of compromise or anomalous behavior.
+  - Review the associated user account activity for additional suspicious behavior on the same host and other hosts, and take appropriate account actions if compromise is suspected.
+  - Hunt for the same script patterns across the environment using stable substrings from `powershell.file.script_block_text` and common `file.path`/`file.name` values, and remediate any additional impacted systems.
+
+- If the activity is verified as benign:
+  - Document the script purpose, owner, expected execution context (hosts and accounts), and expected script origin (`file.path`/`file.name`).
+  - Consider controlled rule tuning using stable, high-confidence identifiers from the verified benign workflow to reduce repeat alerts while maintaining coverage for new or unauthorized 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 : (
+   (VirtualAlloc or VirtualAllocEx or VirtualProtect or LdrLoadDll or LoadLibrary or LoadLibraryA or
+      LoadLibraryEx or GetProcAddress or OpenProcess or OpenProcessToken or AdjustTokenPrivileges) and
+   (WriteProcessMemory or CreateRemoteThread or NtCreateThreadEx or CreateThread or QueueUserAPC or
+      SuspendThread or ResumeThread or GetDelegateForFunctionPointer)
+  ) and not 
+  file.directory: (
+    "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\SenseCM" or
+    "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads"
+  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Process Injection
+** ID: T1055
+** Reference URL: https://attack.mitre.org/techniques/T1055/
+* Sub-technique:
+** Name: Dynamic-link Library Injection
+** ID: T1055.001
+** Reference URL: https://attack.mitre.org/techniques/T1055/001/
+* Sub-technique:
+** Name: Portable Executable Injection
+** ID: T1055.002
+** Reference URL: https://attack.mitre.org/techniques/T1055/002/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: 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-16/prebuilt-rule-8-19-16-potential-timestomp-in-executable-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-timestomp-in-executable-files.asciidoc
new file mode 100644
index 0000000000..442266217b
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-potential-timestomp-in-executable-files.asciidoc
@@ -0,0 +1,166 @@
+[[prebuilt-rule-8-19-16-potential-timestomp-in-executable-files]]
+=== Potential Timestomp in Executable Files
+
+Identifies the modification of a file creation time for executable files in sensitive system directories. Adversaries may modify file time attributes to blend malicious executables with legitimate system files. Timestomping is a technique that modifies the timestamps of a file often to mimic files that are in trusted directories.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.sysmon_operational-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: Sysmon
+* Resources: Investigation Guide
+
+*Version*: 110
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Timestomp in Executable Files*
+
+
+This alert indicates that a process modified the creation timestamp of a file with an executable extension in a sensitive Windows directory or a common persistence location. Timestomping can be used to make recently created or modified files appear older and blend in with legitimate system content.
+
+
+*Possible investigation steps*
+
+- Establish scope and validate context:
+  - Identify the affected endpoint using `host.name` and `host.id`, and determine whether similar alerts or related file-timestamp changes are occurring on the same host.
+  - Review `user.name`, `user.domain`, and `user.id` to understand whether the account typically performs administrative or software management activities on this endpoint.
+  - Use `@timestamp` to bound a focused time window for pivots (for example, shortly before and after the change).
+
+- Assess the timestamp change behavior:
+  - Compare `winlog.event_data.PreviousCreationUtcTime` to `winlog.event_data.CreationUtcTime` and note whether the timestamp was backdated, forward-dated, or aligned to an apparent baseline.
+  - Identify whether multiple files were modified in the same window by searching for additional events on the same `host.id` and `process.entity_id`.
+
+- Evaluate the target file:
+  - Review `file.path`, `file.directory`, `file.name`, and `file.extension` to determine whether the target is expected in that location and whether the name resembles a legitimate component for the directory.
+  - If the file is in a Startup location, treat it as a potential persistence artifact and prioritize determining whether it later executed on the host.
+  - If the file is in a system directory, assess whether the host role and recent maintenance activity could reasonably explain changes to that specific file.
+
+- Investigate the process responsible for the change:
+  - Review `process.executable` and `process.name` for signs of an unusual execution location, unexpected binary name, or a process that does not normally manage files in the target directory.
+  - Pivot using `process.entity_id` (or `process.pid` within a narrow time range) to reconstruct process ancestry and command context using your available process telemetry.
+  - Look for additional activity by the same process in the same time window, such as other file modifications involving the same `file.path` or other executable files in similar directories.
+
+- Check for follow-on execution and related activity:
+  - Search for subsequent activity on the same `host.id` where `process.executable` matches the alerted `file.path`, which can indicate the modified file was executed after timestomping.
+  - If the target is a shortcut (`file.extension` such as `lnk`), look for later execution on the host that aligns with user logon activity for `user.id` and the alert timeline.
+  - Identify whether the same `file.name` and `file.path` appear on other endpoints, which may indicate propagation, a shared deployment mechanism, or a broader intrusion set.
+
+
+*False positive analysis*
+
+- Enterprise software deployment, patching, and self-update mechanisms can rewrite binaries and adjust file metadata as part of normal operations.
+- Backup, restore, profile reset, and file synchronization workflows can preserve or reapply timestamps when placing executables into directories.
+- Administrative troubleshooting or recovery activities (for example, repairing installations or restoring components) may result in unexpected timestamp changes for legitimate files.
+
+
+*Response and remediation*
+
+- If the activity is unexpected or suspicious:
+  - Contain the host to limit further tampering and reduce the risk of execution or persistence.
+  - Preserve evidence for the alert by capturing the values of `file.path`, `process.executable`, `process.entity_id`, `user.id`, and the before/after timestamps, and collect related events on the same `host.id` in the surrounding window.
+  - Determine whether the affected file executed after the change by correlating activity on the same `host.id` and comparing `process.executable` to the alerted `file.path`.
+  - Acquire and analyze the target file and the modifying process binary using your standard tooling to assess reputation, integrity, and suspected origin.
+  - Remove or quarantine malicious files and remediate unauthorized persistence, especially for items placed in Startup locations.
+  - Scope across the environment for the same `file.path`, `file.name`, and `process.executable`, and apply containment actions to additional affected hosts as needed.
+  - If compromise is suspected, review access associated with `user.id` and follow incident response procedures for account containment and recovery.
+
+- If the activity is confirmed benign:
+  - Document the legitimate software or workflow responsible for the timestamp change, including the expected `process.executable` and target paths, to support consistent triage and future tuning.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Sysmon must be installed and configured to generate the events used by this rule (Event ID 2).
+Setup instructions: https://ela.st/sysmon-event-2-setup
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+file where host.os.type == "windows" and
+  event.provider == "Microsoft-Windows-Sysmon" and event.code == "2" and
+  file.extension : (
+    "exe", "dll", "sys", "msi", "scr", "pif", "lnk"
+  ) and
+  file.path : (
+    "?:\\Windows\\System32\\*",
+    "?:\\Windows\\SysWOW64\\*",
+    "?:\\ProgramData\\*",
+    "?:\\Users\\Public\\*",
+    "?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*",
+    "?:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*"
+  ) and
+  not process.executable : (
+    "?:\\Program Files\\*",
+    "?:\\Program Files (x86)\\*",
+    "?:\\Windows\\system32\\cleanmgr.exe",
+    "?:\\Windows\\system32\\msiexec.exe",
+    "?:\\Windows\\syswow64\\msiexec.exe",
+    "?:\\Windows\\system32\\svchost.exe",
+    "?:\\Windows\\System32\\Robocopy.exe",
+    "?:\\Windows\\SysWOW64\\Robocopy.exe"
+  ) and
+  not (process.executable : "?:\\Windows\\System32\\spoolsv.exe" and file.path : "?:\\Windows\\System32\\spool\\*") and
+  not user.name : ("SYSTEM", "Local Service", "Network Service")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Indicator Removal
+** ID: T1070
+** Reference URL: https://attack.mitre.org/techniques/T1070/
+* Sub-technique:
+** Name: Timestomp
+** ID: T1070.006
+** Reference URL: https://attack.mitre.org/techniques/T1070/006/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-obfuscation-via-negative-index-string-reversal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-obfuscation-via-negative-index-string-reversal.asciidoc
new file mode 100644
index 0000000000..0922d2cb74
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-obfuscation-via-negative-index-string-reversal.asciidoc
@@ -0,0 +1,204 @@
+[[prebuilt-rule-8-19-16-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.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: PowerShell Logs
+* Resources: Investigation Guide
+
+*Version*: 9
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Obfuscation via Negative Index String Reversal*
+
+
+This alert flags PowerShell script block content that uses negative index ranges to reverse strings or arrays and rebuild content at runtime. This pattern can be used to hide command text and reduce readability during review, so the primary goal is to recover the reconstructed content and determine what it does in the observed execution context.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
+
+
+*Possible investigation steps*
+
+
+- Review `powershell.file.script_block_text` and locate the reversal logic. Use `Esql.script_block_tmp` to quickly find match positions, then identify:
+  - The variable or array being reversed
+  - The reconstructed output (string, byte array, or command fragment)
+  - The sink where the output is used (for example, passed into a dynamic execution routine, used as a URL, or written to disk)
+- Reconstruct the final value produced by the reversal. Focus on what the script is trying to rebuild (commands, URLs, file paths, registry paths, encoded blobs, or arguments) and record the recovered strings for scoping.
+- If the script block is fragmented, pivot on `powershell.file.script_block_id` and use `powershell.sequence` and `powershell.total` to rebuild the full script in order. Reassess intent based on the complete content rather than a single fragment.
+- Use `Esql.script_block_pattern_count` to prioritize reviews:
+  - Single-use reversal may be utility logic and requires context to judge
+  - Repeated reversal across a long script is more consistent with obfuscation wrappers
+- Use script complexity signals to guide triage:
+  - High `powershell.file.script_block_entropy_bits` and high `powershell.file.script_block_unique_symbols` can indicate encoded or staged content
+  - Compare `powershell.file.script_block_surprisal_stdev` with the script content to determine whether the script mixes readable logic with high-randomness segments
+- Validate execution context with `user.name`, `user.domain`, `user.id`, `host.name`, and `host.id`. Prioritize investigation when the user is unexpected for the host, the host is sensitive, or similar activity is new for that account.
+- Review `file.path`, `file.directory`, and `file.name` (if present) to understand script origin. Treat unknown locations, new or renamed scripts, and ambiguous naming as higher risk, and check for additional script blocks tied to the same path.
+- Scope related activity by searching for additional PowerShell script block events on the same `host.id` and `user.id` around `@timestamp`, and by pivoting on the same `powershell.file.script_block_id`. Look for:
+  - Follow-on script blocks with clearer (deobfuscated) commands
+  - Repeated use of similar reversal segments or reconstructed indicators
+- If other endpoint telemetry is available, correlate activity on the same host and time window to identify what happened next (process launches, network connections, file writes, or other changes) and validate whether outcomes align with the reconstructed content.
+
+
+*False positive analysis*
+
+
+- Legitimate scripts may reverse arrays or strings for formatting, parsing, or testing. These cases typically remain readable end-to-end and do not rely on multiple layers of reconstruction to produce executable behavior.
+- Developer utilities and automation tooling can include dense string manipulation. Validate whether the observed `file.path` and execution context (`user.name`, `host.name`) align with approved workflows and whether the same script content recurs consistently across expected hosts.
+- If activity is confirmed benign, prefer context-based tuning using stable attributes visible in the alert (for example, consistent `file.path` and recognizable script content patterns) rather than suppressing the technique broadly.
+
+
+*Response and remediation*
+
+
+- If the reconstructed content indicates malicious behavior, isolate the affected host to limit further execution and reduce the risk of lateral movement.
+- Preserve evidence by retaining the full `powershell.file.script_block_text` and all related fragments grouped by `powershell.file.script_block_id`. Capture the reconstructed strings and relevant metadata (`powershell.sequence`, `powershell.total`, `Esql.script_block_pattern_count`) in case notes.
+- Identify and contain the execution source. If an unauthorized on-disk script is referenced by `file.path`, remove or quarantine it and investigate how it was introduced using your standard incident response workflow.
+- Investigate the associated account (`user.id`) for signs of compromise. Apply account controls (credential reset, session invalidation, privilege review) based on your procedures and observed scope.
+- Hunt for additional exposure by pivoting on recovered indicators and on recurrence of the reversal technique across hosts and users. Remediate any additional impacted endpoints identified during scoping.
+- After containment, improve preventative controls appropriate for your environment, such as restricting PowerShell usage to approved users/hosts and enhancing monitoring for obfuscation and dynamic execution patterns.
+
+
+==== 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]
+----------------------------------
+from logs-windows.powershell_operational* metadata _id, _version, _index
+| where event.code == "4104"
+
+// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for
+| eval Esql.script_block_length = length(powershell.file.script_block_text)
+| where Esql.script_block_length > 500
+
+// replace the patterns we are looking for with the 🔥 emoji to enable counting them
+// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1
+| eval Esql.script_block_tmp = replace(
+    powershell.file.script_block_text,
+    """\$\w+\[\-\s?1\.\.""",
+    "🔥"
+)
+
+// count how many patterns were detected by calculating the number of 🔥 characters inserted
+| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", ""))
+
+// keep the fields relevant to the query, although this is not needed as the alert is populated using _id
+| keep
+    Esql.script_block_pattern_count,
+    Esql.script_block_length,
+    Esql.script_block_tmp,
+    powershell.file.*,
+    file.name,
+    file.path,
+    powershell.sequence,
+    powershell.total,
+    _id,
+    _version,
+    _index,
+    host.name,
+    host.id,
+    agent.id,
+    user.id
+
+// Filter for scripts that match the pattern at least once
+| where Esql.script_block_pattern_count >= 1
+
+// FP Patterns
+| where not powershell.file.script_block_text like "*GENESIS-5654*"
+
+| where file.name not like ("PSFzf.psm1", "Tenable_API_AssetLists_IPv6Seeder.ps1", "Utility.ps1")
+  // ESQL requires this condition, otherwise it only returns matches where file.name exists.
+  or file.name is null
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-psreflect-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-psreflect-script.asciidoc
new file mode 100644
index 0000000000..ca9e6023e3
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-psreflect-script.asciidoc
@@ -0,0 +1,184 @@
+[[prebuilt-rule-8-19-16-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.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.powershell*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<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*: 317
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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.
+
+- 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.
+
+- 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.
+
+- 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`.
+
+- 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.
+
+- 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.
+
+
+*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.
+
+
+*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).
+
+
+==== 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-16/prebuilt-rule-8-19-16-powershell-script-block-logging-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-script-block-logging-disabled.asciidoc
new file mode 100644
index 0000000000..16dd44f6f5
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-script-block-logging-disabled.asciidoc
@@ -0,0 +1,187 @@
+[[prebuilt-rule-8-19-16-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.
+
+*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*: 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://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.PowerShell::EnableScriptBlockLogging
+
+*Tags*: 
+
+* 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 for Endpoint
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+
+*Version*: 315
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Script Block Logging Disabled*
+
+
+This alert indicates a registry modification that set `EnableScriptBlockLogging` to a disabled value (`registry.data.strings` of `0` or `0x00000000`). Disabling Script Block Logging reduces visibility into PowerShell execution and is commonly used to evade detection, especially when followed by script-driven activity.
+
+
+*Key alert fields to review*
+
+
+- `process.executable`: The process responsible for modifying the registry value.
+- `registry.value`: The registry value name that was changed (`EnableScriptBlockLogging`).
+- `registry.data.strings`: The new data indicating the setting was disabled.
+- `registry.path`: The full registry path of the modified value.
+- `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.
+
+
+*Possible investigation steps*
+
+
+- Establish the affected endpoint and time window:
+  - Use `host.name`, `host.id`, and `@timestamp` to identify the impacted endpoint and define a review window (include activity immediately before and after the change).
+  - Prioritize based on endpoint role and criticality (for example, servers and admin workstations).
+
+- Validate the registry change and its scope:
+  - Review `registry.path`, `registry.value`, and `registry.data.strings` to confirm the setting was disabled and to understand where it was applied.
+  - Compare `registry.path` to common policy locations for Script Block Logging (for example, `HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging\EnableScriptBlockLogging`).
+  - Determine whether the change is likely machine-wide or user-scoped based on the hive reflected in `registry.path`, and assess the blast radius accordingly.
+  - Check for repeated changes (toggling) to the same `registry.path` and `registry.value` around the alert time, which can indicate attempted evasion or policy enforcement conflicts.
+
+- Identify the modifying process and execution context:
+  - Review `process.executable` for legitimacy (expected binary name, expected install path) and whether it typically performs configuration changes.
+  - Pivoting using `process.entity_id`, review `process.command_line` to understand how the value was set and whether the command line suggests interactive administration, scripts, or automation.
+  - Using nearby endpoint process telemetry on the same host, reconstruct the process tree to identify the initiating process (parent) and any immediate follow-on execution that may have benefited from reduced PowerShell logging.
+
+- Assess the user context and authorization:
+  - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to manage logging or policy settings on this endpoint.
+  - If the change is attributed to a service or system context, identify the associated service, scheduled activity, or management workflow that could have performed the modification.
+  - Scope the user across other hosts for similar activity during the same window to identify potential credential misuse.
+
+- Hunt for related activity that may be masked by reduced logging:
+  - Review host activity immediately before the change for suspicious behavior that could explain the need to disable Script Block Logging (initial access, privilege escalation, or tool staging).
+  - Review host activity after the change for suspicious process launches, script interpreter activity, persistence attempts, credential access behavior, or lateral movement indicators.
+  - Review network activity from the host around the change for connections consistent with payload retrieval, remote access, or command and control.
+  - Review other registry changes around the same time that may further impair visibility or weaken defenses.
+
+- Scope and impact assessment across the environment:
+  - Search for other instances where `registry.value` is `EnableScriptBlockLogging` and `registry.data.strings` indicates a disabled state to determine whether this is isolated or widespread.
+  - Pivot on `process.executable` and `user.id` to identify other endpoints where the same process or account modified this setting.
+  - Identify whether the setting was later restored on the same host by looking for subsequent changes to the same `registry.path` and `registry.value`.
+
+
+*False positive analysis*
+
+
+- Authorized policy, baseline, or hardening changes that intentionally modify PowerShell logging settings, supported by change records and consistent execution by expected accounts and tooling.
+- Provisioning or imaging workflows where configuration changes occur during early host lifecycle stages and are consistent across a known deployment batch.
+- Short-lived administrative troubleshooting where the setting is temporarily changed and promptly restored, with supporting documentation.
+
+
+*Response and remediation*
+
+
+- If the change is unexpected or suspicious:
+  - Treat as potential defense evasion and escalate according to incident response procedures.
+  - Contain the endpoint if there are indicators of follow-on malicious activity in the surrounding timeframe.
+  - Preserve evidence related to the change, including `process.executable`, `process.command_line`, user context, and any correlated endpoint telemetry.
+
+- Restore and enforce PowerShell visibility:
+  - Re-enable Script Block Logging using approved administrative processes and verify the setting persists through policy enforcement.
+  - Monitor for repeated attempts to disable Script Block Logging, especially from the same user or originating process.
+
+- Remediate root cause and reduce recurrence:
+  - Identify and remove unauthorized tooling or persistence associated with the modifying process.
+  - Investigate potential account compromise for the associated user and take appropriate actions (credential reset and access review), prioritizing privileged accounts.
+  - Hunt for additional endpoints impacted by the same user or process and remediate as needed.
+  - Apply least-privilege controls to limit who can modify logging-related registry settings and improve alerting for additional defense impairment behaviors observed during the investigation window.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+registry where host.os.type == "windows" and event.type == "change" and
+    registry.value : "EnableScriptBlockLogging" and
+    registry.data.strings : ("0", "0x00000000") and
+    not process.executable : (
+          "?:\\Windows\\System32\\svchost.exe",
+          "?:\\Windows\\System32\\DeviceEnroller.exe",
+          "?:\\Windows\\system32\\omadmclient.exe",
+          "?:\\Program Files\\Trend Micro\\Cloud Endpoint\\CloudEndpointService.exe",
+          "?:\\Program Files (x86)\\N-able Technologies\\AutomationManagerAgent\\AutomationManager.AgentService.exe",
+          
+          /* Crowdstrike specific exclusion as it uses NT Object paths */
+          "\\Device\\HarddiskVolume*\\Windows\\System32\\svchost.exe",
+          "\\Device\\HarddiskVolume*\\Windows\\System32\\DeviceEnroller.exe",
+          "\\Device\\HarddiskVolume*\\Windows\\system32\\omadmclient.exe",
+          "\\Device\\HarddiskVolume*\\Program Files\\Trend Micro\\Cloud Endpoint\\CloudEndpointService.exe",
+          "\\Device\\HarddiskVolume*\\Program Files (x86)\\N-able Technologies\\AutomationManagerAgent\\AutomationManager.AgentService.exe"
+    )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* 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: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
+* Sub-technique:
+** Name: Disable Windows Event Logging
+** ID: T1562.002
+** Reference URL: https://attack.mitre.org/techniques/T1562/002/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-script-with-encryption-decryption-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-script-with-encryption-decryption-capabilities.asciidoc
new file mode 100644
index 0000000000..f17ffe2a75
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-script-with-encryption-decryption-capabilities.asciidoc
@@ -0,0 +1,184 @@
+[[prebuilt-rule-8-19-16-powershell-script-with-encryption-decryption-capabilities]]
+=== PowerShell Script with Encryption/Decryption Capabilities
+
+Identifies PowerShell script block content that uses .NET cryptography APIs for file encryption or decryption. Attackers abuse these routines to encrypt data for impact or decrypt staged payloads to evade defenses.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.powershell*
+
+*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: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: PowerShell Logs
+* Resources: Investigation Guide
+
+*Version*: 112
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Script with Encryption/Decryption Capabilities*
+
+
+This rule identifies PowerShell script block content that implements cryptographic encryption or decryption using .NET APIs. Matching script blocks commonly include symmetric cryptography classes (for example, AES/Rijndael or the SymmetricAlgorithm base type), key derivation helpers (for example, PasswordDeriveBytes or Rfc2898DeriveBytes), explicit cipher configuration (CipherMode and PaddingMode), and calls that create an encryptor or decryptor.
+
+This behavior can be legitimate (protecting configuration values, packaging content, or controlled encryption for business workflows). It can also indicate malicious activity such as encrypting local data for impact or decrypting staged content to reduce static visibility before follow-on execution. Prioritize determining what data is being transformed, where outputs are written, and whether the user/host/script origin aligns with expected activity.
+
+
+*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 `powershell.file.script_block_text` to understand the cryptographic intent and data flow:
+  - Identify whether the logic is primarily encrypting, decrypting, or doing both.
+  - Note which cryptographic primitives are used (for example, AES/Rijndael, hashing helpers, and key derivation routines) and how keys/IVs are produced (hard-coded values, derived from passwords, generated randomly, or passed in).
+  - Identify the transformed data source and destination:
+    - File-oriented operations: look for path construction, directory traversal patterns, repeated read/write loops, file extension changes, renames, or deletion of originals.
+    - In-memory operations: look for large embedded blobs, byte arrays, stream usage, or logic that converts decrypted content into executable form or writes it to a new artifact.
+  - Extract and preserve any embedded secrets or deterministic derivation parameters (password strings, salts, iteration counts, static IVs, or key material), as these can be critical for impact assessment and recovery.
+
+- Determine whether the alert contains the full implementation or only a fragment:
+  - Use `powershell.file.script_block_length` to gauge whether this is a complete routine (larger blocks) versus a wrapper or function invocation (smaller blocks).
+  - If the script appears incomplete, pivot on `powershell.file.script_block_id` and use `powershell.sequence` / `powershell.total` to retrieve and order all fragments before concluding intent.
+
+- Validate execution context and provenance:
+  - Review `user.name`, `user.domain`, and `user.id` to determine whether this account typically performs encryption/decryption tasks and whether the account scope matches the host role.
+  - Review `host.name` and `host.id` to determine asset criticality and whether similar activity is expected on this system (for example, administrative hosts may have more automation than standard endpoints).
+  - If `file.path` / `file.name` is present, evaluate whether the script origin is expected:
+    - Compare the path and name to approved automation locations and naming conventions.
+    - Treat unexpected paths, user-writable directories, or newly observed script locations as higher risk.
+
+- Scope the activity using alert fields:
+  - On the same host, search for additional script blocks tied to the same `powershell.file.script_block_id` to find related functions or setup code not visible in the initial alert fragment.
+  - Search across hosts for repeating patterns in `powershell.file.script_block_text` and for the same `file.name` to determine whether this is a widely deployed administrative script or isolated activity.
+  - Pivot on `user.id` to identify whether similar script blocks appear on multiple hosts, which may indicate coordinated activity.
+
+- Correlate with adjacent telemetry around `@timestamp` for the same `host.id` and `user.id` (if available in your environment):
+  - Process execution telemetry to identify the PowerShell host process and what initiated it, helping distinguish interactive use from automation or remotely initiated activity.
+  - File activity telemetry to identify bursts of file modifications/creations consistent with bulk encryption/decryption and to determine which directories and file types were affected.
+  - Network telemetry to identify connections that could support retrieval of encrypted content, exchange of key material, or staging/downloading of additional payloads.
+  - Authentication telemetry to identify unusual logons or session types for the user preceding execution.
+
+- Determine disposition and urgency:
+  - Treat as higher severity if the script indicates broad file processing, writes many outputs, modifies user data locations, or includes embedded key material/blobs associated with staged content.
+  - Treat as lower severity if the script is clearly tied to approved operations, originates from a known `file.path`, is executed by expected accounts, and shows consistent recurrence patterns with expected scope.
+
+
+*False positive analysis*
+
+
+- Legitimate PowerShell automation may implement encryption/decryption for secure configuration handling, packaging, data protection, or interoperability with other systems.
+- Benign activity is more likely to have consistent `file.path` / `file.name` values, execute under expected administrative accounts, and recur on appropriate hosts with stable script content.
+- If the script is determined to be benign, document what data it protects, where it is expected to run, which accounts execute it, and what normal recurrence looks like to reduce future triage time.
+
+
+*Response and remediation*
+
+
+- If the activity is suspicious or malicious:
+  - Contain the host to prevent further encryption/decryption activity and reduce the risk of spread or data impact.
+  - Preserve evidence from the alert, including the full `powershell.file.script_block_text` and any reconstructed fragments correlated via `powershell.file.script_block_id`.
+  - If `file.path` is present, collect the referenced script from disk and preserve it for forensic review and scoping.
+  - Identify impacted systems and data:
+    - If file-impact is suspected, prioritize backup protection, incident response escalation, and recovery planning.
+    - If payload staging is suspected, prioritize identifying the decrypted output or follow-on execution artifacts.
+  - Scope and hunt across the environment for related activity using `user.id`, `host.id`, recurring `file.name`, and distinctive fragments of `powershell.file.script_block_text`.
+  - Remediate the associated account and access path: validate legitimacy, reset credentials if compromise is suspected, and apply least-privilege controls where appropriate.
+  - Remove or block the identified script and any related artifacts discovered during analysis, and monitor for recurrence.
+
+- If the activity is confirmed benign:
+  - Record the expected `file.path` / `file.name`, the responsible `user.id`, and normal execution patterns to support consistent future triage and tuning decisions.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.category:process and host.os.type:windows and
+  powershell.file.script_block_text : (
+    (
+      "Cryptography.AESManaged" or
+      "Cryptography.RijndaelManaged" or
+      "Cryptography.SHA1Managed" or
+      "Cryptography.SHA256Managed" or
+      "Cryptography.SHA384Managed" or
+      "Cryptography.SHA512Managed" or
+      "Cryptography.SymmetricAlgorithm" or
+      "PasswordDeriveBytes" or
+      "Rfc2898DeriveBytes"
+    ) and
+    (
+      CipherMode and PaddingMode
+    ) and
+    (
+      ".CreateEncryptor" or
+      ".CreateDecryptor"
+    )
+  ) and
+  not user.id : "S-1-5-18" and
+  not (
+    file.name : "Bootstrap.Octopus.FunctionAppenderContext.ps1" and
+    powershell.file.script_block_text : ("function Decrypt-Variables" or "github.com/OctopusDeploy")
+  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-script-with-token-impersonation-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-script-with-token-impersonation-capabilities.asciidoc
new file mode 100644
index 0000000000..30d5c45e3d
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-script-with-token-impersonation-capabilities.asciidoc
@@ -0,0 +1,227 @@
+[[prebuilt-rule-8-19-16-powershell-script-with-token-impersonation-capabilities]]
+=== PowerShell Script with Token Impersonation Capabilities
+
+Detects PowerShell scripts that references token manipulation and impersonation APIs such as CreateProcessWithTokenW, DuplicateToken/ImpersonateLoggedOnUser, or AdjustTokenPrivileges (SeDebugPrivilege). Attackers abuse token impersonation to elevate privileges and bypass access controls.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.powershell*
+
+*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/decoder-it/psgetsystem
+* https://github.com/PowerShellMafia/PowerSploit/blob/master/Privesc/Get-System.ps1
+* https://github.com/EmpireProject/Empire/blob/master/data/module_source/privesc/Invoke-MS16032.ps1
+* 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: Privilege Escalation
+* Data Source: PowerShell Logs
+* Resources: Investigation Guide
+
+*Version*: 118
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Script with Token Impersonation Capabilities*
+
+
+This rule Detects PowerShell scripts that includes token manipulation and impersonation primitives. Such functionality can be used to execute follow-on actions under a different security context, including elevated or alternate user tokens. The primary investigation goals are to (1) reconstruct and understand the script intent, (2) validate whether the activity is authorized, and (3) identify any resulting privileged execution on the host.
+
+
+*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*
+
+
+- Preserve and reconstruct the full script block content:
+  - Capture `powershell.file.script_block_text` from the alert for analysis and evidence retention.
+  - If the script is logged in multiple fragments, pivot on `powershell.file.script_block_id` and reassemble in order using `powershell.sequence`. Use `powershell.total` to confirm you have the complete set of fragments.
+  - Use `powershell.file.script_block_length` to help gauge completeness and identify unusually large blocks that may contain reusable libraries or modules.
+
+- Identify which token technique is present and what outcome the script is attempting:
+  - Review the reconstructed content for indicators of:
+    - Token duplication and impersonation (for example: `DuplicateToken`, `DuplicateTokenEx`, `SetThreadToken`, `ImpersonateLoggedOnUser`, `NtImpersonateThread`).
+    - Named pipe impersonation (`ImpersonateNamedPipeClient`).
+    - Privilege enablement (`AdjustTokenPrivileges` with `SeDebugPrivilege`).
+    - Token-based process creation (for example: `CreateProcessWithTokenW`, `CreateProcessAsUserW`, `CreateProcessAsUserA`) and related extended startup attributes (`STARTUPINFOEX`, `UpdateProcThreadAttribute`).
+    - Higher-level wrappers commonly associated with token manipulation (for example: `Invoke-TokenManipulation`).
+  - Determine whether the script only defines helper functions/types versus actively invoking them. Content that both defines and calls token APIs within the same execution window is higher risk.
+  - Note any embedded targeting details in the script content (for example: intended user context, target process identifiers, or follow-on payload references), and preserve them for scoping and hunting.
+
+- Validate execution context and expectedness:
+  - Use `host.name` and `host.id` to understand where the activity occurred and whether the system role typically requires privileged PowerShell usage.
+  - Use `user.name`, `user.domain`, and `user.id` to identify the executing account and determine whether this user is expected to run scripts that manipulate access tokens on this host.
+  - Prioritize alerts involving unexpected users, unusual hosts (for example, servers with limited admin access), or repeated/recurrent script blocks indicating persistence or automation.
+
+- Assess script provenance when file context is present:
+  - If `file.path` is populated, determine whether the script came from a known module or an on-disk script file, and whether the location and naming are consistent with approved tooling.
+  - If only `file.directory` and `file.name` are populated, use them to pivot to related script blocks and identify other executions from the same origin.
+  - If the origin appears unfamiliar or user-writable, treat the artifact as suspicious and prioritize collecting the referenced file (and any adjacent module content) for deeper analysis.
+
+- Correlate with surrounding host activity to determine impact:
+  - Pivot on `host.name` and the alert `@timestamp` into adjacent telemetry to identify the PowerShell host process and its initiating parent/source (interactive session, remote management, scheduled execution, or another process).
+  - Look for follow-on activity shortly after the alert time that would indicate successful impersonation or privilege escalation, such as:
+    - New process execution under a different user context than `user.name`.
+    - Privileged actions that require elevated rights (for example, service/task changes, registry modifications, or access to protected resources).
+  - If multiple script blocks occur close together for the same `user.id` and `host.id`, review them as a single activity chain to understand staging, execution, and any post-escalation behavior.
+
+- Scope and hunt for related activity:
+  - Search for additional occurrences of distinctive substrings from `powershell.file.script_block_text` (function names, API names, unique strings) across other users and hosts to identify reuse.
+  - Review whether the same `user.id` is associated with similar script blocks on other `host.id` values, which can indicate broad automation or a compromised account used across systems.
+  - If `file.path` is present, check for the same path and file name across the environment, and identify unexpected hosts where the artifact appears.
+
+
+*False positive analysis*
+
+
+- Legitimate administrative automation may use token impersonation to run tasks under alternate credentials, perform controlled privilege transitions, or integrate with management workflows.
+- Development and troubleshooting scripts may contain token API references as reusable helpers without being used for malicious outcomes.
+
+To reduce false positives, focus on provenance and behavior: scripts from known, approved sources and executed by expected administrative identities on expected hosts are more likely benign, while ad-hoc or newly introduced scripts, unfamiliar file origins, and follow-on privileged execution increase concern.
+
+
+*Response and remediation*
+
+
+- If the activity is unauthorized or suspicious:
+  - Contain the host to prevent further privileged execution and limit lateral movement according to your incident response procedures.
+  - Preserve evidence: the reconstructed script block content, associated `powershell.file.script_block_id` fragments, and any referenced on-disk artifacts from `file.path` (or `file.directory`/`file.name`).
+  - Investigate and remediate outcomes of token impersonation, including processes started under unexpected security contexts and any privileged system changes occurring after the alert time.
+
+- Reduce attacker access and recurrence:
+  - Review the executing account identified in `user.id`; reset credentials and invalidate active sessions as appropriate.
+  - Review privileged access assignments for the involved accounts and hosts, and remove unauthorized privilege grants where identified.
+  - If the script enabled sensitive privileges (for example, `SeDebugPrivilege`), assess for additional post-exploitation activity that could leverage enhanced access to protected processes and resources.
+
+- Eradicate and recover:
+  - Remove unauthorized scripts/modules and any secondary artifacts or persistence mechanisms discovered during investigation.
+  - Monitor for repeat executions by hunting for the same token manipulation indicators observed in `powershell.file.script_block_text` across the environment.
+  - Ensure PowerShell script block logging is enabled and retained on systems where PowerShell is permitted so future activity can be reconstructed and scoped effectively.
+
+
+==== 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:(
+    "Invoke-TokenManipulation" or
+    "ImpersonateNamedPipeClient" or
+    "NtImpersonateThread" or
+    (
+      "STARTUPINFOEX" and
+      "UpdateProcThreadAttribute"
+    ) or
+    (
+      "AdjustTokenPrivileges" and
+      "SeDebugPrivilege"
+    ) or
+    (
+      ("DuplicateToken" or
+      "DuplicateTokenEx") and
+      ("SetThreadToken" or
+      "ImpersonateLoggedOnUser" or
+      "CreateProcessWithTokenW" or
+      "CreatePRocessAsUserW" or
+      "CreateProcessAsUserA")
+    ) 
+  ) and
+  not (
+    user.id:("S-1-5-18" or "S-1-5-19" or "S-1-5-20") and
+    file.directory: "C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads"
+  ) and
+  not powershell.file.script_block_text : (
+    "sentinelbreakpoints" and "Set-PSBreakpoint" and "PowerSploitIndicators"
+  ) and
+  not (
+    powershell.file.script_block_text : "New-HPPrivateToastNotificationLogo" and
+    file.path : "C:\Program Files\HPConnect\hp-cmsl-wl\modules\HP.Notifications\HP.Notifications.psm1"
+  )
+
+----------------------------------
+
+*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/
+* 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-16/prebuilt-rule-8-19-16-powershell-script-with-windows-defender-tampering-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-script-with-windows-defender-tampering-capabilities.asciidoc
new file mode 100644
index 0000000000..009eebcc20
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-script-with-windows-defender-tampering-capabilities.asciidoc
@@ -0,0 +1,207 @@
+[[prebuilt-rule-8-19-16-powershell-script-with-windows-defender-tampering-capabilities]]
+=== PowerShell Script with Windows Defender Tampering Capabilities
+
+Detects PowerShell scripts that uses Set-MpPreference with parameters that disable or weaken Defender. Attackers tamper with antivirus settings to reduce detection and enable follow-on payload execution.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.powershell*
+
+*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: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: PowerShell Logs
+* Resources: Investigation Guide
+
+*Version*: 108
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Script with Windows Defender Tampering Capabilities*
+
+
+This alert highlights PowerShell script block activity that attempts to change Windows Defender preferences in ways that can reduce host protections. These changes are frequently used to create a window for follow-on execution (for example, staging payloads, running tools, or maintaining access with reduced scanning and response).
+
+Triage should focus on (1) what protections were targeted and how, (2) who initiated the change and on which host(s), (3) whether the change took effect and persisted, and (4) whether there is surrounding activity that suggests initial access or follow-on malicious actions.
+
+
+*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 script block content and determine the intended Defender impact:
+  - Inspect `powershell.file.script_block_text` and enumerate each `Set-MpPreference` parameter present.
+  - Capture whether the script is disabling protections (for example, real-time monitoring, script scanning, network file scanning) or changing default threat actions (low/moderate/high) to more permissive outcomes.
+  - Note whether the script changes multiple settings in one execution, repeats the changes, or includes additional logic that suggests deliberate defense impairment rather than a single configuration adjustment.
+
+- Reconstruct full script content when it is split across multiple events:
+  - If `powershell.total` is greater than 1, pivot on `powershell.file.script_block_id` and order fragments by `powershell.sequence` to rebuild the full script.
+  - Ensure you capture all fragments for the same `powershell.file.script_block_id` on the same `host.id` and `user.id` near the alert time; missing fragments can hide follow-on behavior embedded in later chunks.
+
+- Establish scope across hosts and accounts:
+  - Use `@timestamp`, `host.name` / `host.id`, and `user.name` / `user.domain` / `user.id` to determine whether the activity is isolated or distributed.
+  - Look for the same user context making similar changes across multiple hosts in a short time window (suggesting automation or compromised credentials).
+  - Look for multiple distinct user contexts making similar changes on the same host (suggesting lateral movement or multiple access paths).
+
+- Determine the execution and origin context:
+  - If `file.path` or `file.name` is populated, treat the activity as file-backed scripting and capture the location for scoping (where else this script exists, who can write to it, and when it was last introduced).
+  - If the file fields are not populated, treat the activity as potentially interactive or dynamically generated content and expand the search for adjacent script blocks from the same `user.id` on the same `host.id` around `@timestamp` to identify staging, execution flow, or repeated attempts.
+
+- Validate whether Defender settings were actually changed and whether the change persisted:
+  - Using available endpoint security telemetry and configuration auditing, validate whether the targeted preferences were applied on the affected host(s) and whether they remained in the weakened state after the alert time.
+  - Compare against your approved baseline for Defender settings and identify deviations that would materially reduce protection coverage.
+
+- Correlate with adjacent activity to identify initial access and follow-on execution:
+  - Correlate by `host.id` and time to nearby process activity to identify the PowerShell host process and its launching context (interactive use vs scheduled/automated execution vs another process initiating PowerShell).
+  - Review file and network telemetry around the same time for indicators of payload staging or execution (new files written, unusual outbound connections, or repeated attempts after the change).
+  - Check for repeated Defender preference modifications over time on the same host (suggesting persistent tampering) and for other suspicious activity tied to the same `user.id`.
+
+
+*False positive analysis*
+
+
+Legitimate activity can modify Defender preferences, but it should be explainable, consistent, and controlled.
+
+- Common benign drivers:
+  - Approved endpoint management or administrative maintenance that adjusts scanning behavior for performance or operational compatibility.
+  - Controlled troubleshooting where settings are temporarily changed and later restored.
+
+- Validation questions to reduce uncertainty:
+  - Does `user.id` map to an expected administrative or management identity for this host population?
+  - Is the activity aligned with known maintenance windows, change records, and documented procedures?
+  - Is `file.path` (when present) consistent with a known, maintained script location, and does the script content align with an approved baseline?
+
+If the activity is benign, document the owner, expected scope (hosts/users), expected recurrence, and the intended steady-state protection posture.
+
+
+*Response and remediation*
+
+
+If the activity is unauthorized or suspicious, treat it as a defense evasion attempt with potential follow-on actions.
+
+- Contain and preserve evidence:
+  - Prioritize affected endpoints identified by `host.id` / `host.name` and preserve relevant evidence, including the full reconstructed script from `powershell.file.script_block_id` and `powershell.file.script_block_text`.
+  - Capture the initiating identity context (`user.name`, `user.domain`, `user.id`) for incident scoping and credential review.
+
+- Restore protections and eliminate the change source:
+  - Restore Windows Defender preferences to the approved baseline using authorized operational processes and verify protections are active.
+  - If `file.path` is present, identify the responsible script and remove or disable unauthorized automation that applies the changes.
+  - If the activity appears user-driven or interactive, investigate how the user obtained execution capability on the host and address the root cause.
+
+- Address potential account compromise and lateral movement:
+  - Review recent activity associated with the initiating account and affected hosts for signs of credential misuse, unexpected access patterns, or follow-on execution.
+  - Apply appropriate credential remediation for impacted identities and review privileged access assignments relevant to the affected endpoints.
+
+- Scope and monitor:
+  - Hunt for the same Defender-tampering parameters within `powershell.file.script_block_text` across other hosts and users to identify additional impacted systems.
+  - Continue monitoring for recurrence of similar preference changes tied to the same `user.id`, as repeated tampering may indicate persistence or an active intrusion.
+
+
+==== 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: "Set-MpPreference" and
+  powershell.file.script_block_text: (
+    DisableArchiveScanning or DisableBehaviorMonitoring or
+    DisableIntrusionPreventionSystem or DisableIOAVProtection or
+    DisableRemovableDriveScanning or DisableBlockAtFirstSeen or
+    DisableScanningMappedNetworkDrivesForFullScan or
+    DisableScanningNetworkFiles or DisableScriptScanning or
+    DisableRealtimeMonitoring or LowThreatDefaultAction or
+    ModerateThreatDefaultAction or HighThreatDefaultAction
+  )
+) and
+not powershell.file.script_block_text : (
+  ("cmdletization" and "cdxml-Help.xml") or
+  ("function Set-MpPreference" and "Microsoft.PowerShell.Cmdletization.GeneratedTypes.MpPreference.SubmitSamplesConsentType")
+) and
+not file.directory : "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\SenseCM" and
+not user.id : "S-1-5-18"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
+* Sub-technique:
+** Name: Disable or Modify Tools
+** ID: T1562.001
+** Reference URL: https://attack.mitre.org/techniques/T1562/001/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-share-enumeration-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-share-enumeration-script.asciidoc
new file mode 100644
index 0000000000..7e7b2c9ce2
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-share-enumeration-script.asciidoc
@@ -0,0 +1,215 @@
+[[prebuilt-rule-8-19-16-powershell-share-enumeration-script]]
+=== PowerShell Share Enumeration Script
+
+Detects PowerShell scripts that uses ShareFinder functions (Invoke-ShareFinder/Invoke-ShareFinderThreaded) or Windows share enumeration APIs (shi1_netname/shi1_remark with NetShareEnum/NetApiBufferFree). Attackers use share enumeration to map accessible network shares for collection, lateral movement, or ransomware targeting.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.powershell*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.advintel.io/post/hunting-for-corporate-insurance-policies-indicators-of-ransom-exfiltrations
+* https://thedfirreport.com/2022/04/04/stolen-images-campaign-ends-in-conti-ransomware/
+* 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: Discovery
+* Tactic: Collection
+* Tactic: Execution
+* Resources: Investigation Guide
+* Data Source: PowerShell Logs
+
+*Version*: 115
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Share Enumeration Script*
+
+
+This alert indicates PowerShell script block content consistent with Windows network share enumeration. The matched text includes ShareFinder functions (for example, `Invoke-ShareFinder` or `Invoke-ShareFinderThreaded`) and/or native share enumeration API references (for example, `NetShareEnum` / `NetApiBufferFree` and `shi1_netname` / `shi1_remark`). Share discovery can be a normal administrative activity, but in attacks it is frequently used to map accessible shares prior to data collection, lateral movement, or impact activity.
+
+
+*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*
+
+
+- Establish context and triage priority:
+  - Use `@timestamp` as the activity anchor and note the executing `user.name` / `user.domain` / `user.id` and affected `host.name` / `host.id`.
+  - Determine whether the account and host are expected to perform share inventory (for example, administrative workstation or management server vs. a standard user endpoint).
+  - Check whether similar share enumeration activity has occurred recently for the same `user.id` or on the same `host.id` to identify repeated scanning or automation.
+
+- Review the script block content and classify the activity:
+  - Inspect `powershell.file.script_block_text` and capture relevant excerpts for the case record (function names, API calls, and any referenced hosts/shares).
+  - Differentiate between a function definition/import and an actual invocation:
+    - Function definition or module load (lower confidence): the text contains the function name as part of a definition or import logic.
+    - Function invocation (higher confidence): the text shows parameters, target lists, or loops that initiate enumeration.
+  - Identify which pattern is present and what it implies about scope:
+    - `Invoke-ShareFinder`: share discovery logic implemented in PowerShell.
+    - `Invoke-ShareFinderThreaded`: broader or faster discovery due to concurrent enumeration.
+    - `NetShareEnum` / `NetApiBufferFree` with `shi1_netname` / `shi1_remark`: direct use of Windows share enumeration APIs and may reflect customized scripting.
+  - Extract scoping and intent details from the text when available:
+    - Target hostnames/IPs, server lists, domain-related identifiers, or UNC paths.
+    - Filters for share names and remarks, or include/exclude logic that focuses discovery on specific systems or shares.
+    - Use of alternate credentials or explicit authentication material embedded in the script (if present).
+    - Any output handling (formatting, writing results to disk, or staging).
+
+- Reconstruct full content when script blocks are split:
+  - Pivot on `powershell.file.script_block_id` to collect all related fragments for the same execution context.
+  - Use `powershell.sequence` and `powershell.total` to order fragments and identify missing pieces (if populated).
+  - Review adjacent script blocks for the same `host.id` and `user.id` near `@timestamp` to capture supporting functions or follow-on actions that may not appear in the triggering fragment.
+
+- Determine whether the activity originated from an on-disk script:
+  - If present, use `file.path` / `file.directory` / `file.name` to identify the script source.
+  - Assess whether the script location and name align with approved administrative tooling. Scripts originating from user-writable or temporary locations are higher risk than centrally managed locations.
+  - If an on-disk script is involved, preserve the file for further analysis and determine whether it appears on additional hosts (pivot on `file.name` where applicable).
+
+- Scope across users and hosts:
+  - Look for additional events containing the same discovery keywords in `powershell.file.script_block_text` to identify other affected endpoints.
+  - Check whether the same `user.id` performed similar activity from multiple `host.id` values in a short period, which can indicate automation or credential misuse.
+  - Identify whether multiple users are performing similar enumeration from the same host, which can indicate a shared jump box or a compromised administrative endpoint.
+
+- Correlate with adjacent telemetry (as available) to confirm intent and detect follow-on behavior:
+  - Process execution telemetry on the same `host.id` around `@timestamp` to determine how PowerShell was launched and whether the initiating process and execution pattern are consistent with expected activity for `user.id`.
+  - Network telemetry around `@timestamp` for access to multiple remote hosts consistent with share enumeration and subsequent SMB activity.
+  - Authentication telemetry for `user.id` around `@timestamp` for unusual access to file servers or multiple servers, especially if the behavior is new for the account.
+  - File activity telemetry (endpoint and/or file server) for unusual access patterns to shared locations following the enumeration (for example, rapid directory traversal or access to sensitive paths).
+
+- Assess risk and impact:
+  - Prioritize investigation if the script targets high-value systems (for example, file servers) or if the discovery appears broad (large target lists, threading, repeated runs).
+  - If the executing `user.id` is privileged or the host is sensitive, treat the alert as higher risk and expand scoping to additional related activity.
+
+
+*False positive analysis*
+
+
+- Legitimate administrative share inventory, auditing, or documentation activity performed by IT or infrastructure teams.
+- Approved operational scripts used for backup validation, migration planning, access reviews, or troubleshooting that enumerate shares across servers.
+
+
+*Response and remediation*
+
+
+- If the activity is unauthorized or suspicious:
+  - Contain the affected endpoint (`host.id`) following your incident response procedures to reduce the risk of further discovery and lateral movement.
+  - Preserve evidence by retaining the complete `powershell.file.script_block_text` content and all fragments linked by `powershell.file.script_block_id` (including ordered reconstruction using `powershell.sequence` / `powershell.total` when available).
+  - Identify and prioritize potential targets referenced in the script content (servers and shares) and coordinate review of access patterns to those resources.
+  - Investigate the executing account (`user.name` / `user.id`) for compromise, including recent authentication activity and unexpected resource access, and take appropriate containment actions (credential reset, privilege review, and session invalidation where applicable).
+  - Expand hunting for additional share enumeration and subsequent access attempts associated with the same `user.id` or originating from the same `host.id`.
+  - If an on-disk script was used (`file.path` / `file.name` present), remove or quarantine the artifact per your response process and check for the same file on other systems.
+
+- If the activity is confirmed benign:
+  - Document the owner, purpose, expected timing, and expected scope (accounts and endpoints) of the share enumeration.
+  - If tuning is required, scope it narrowly to stable identifiers present in the alert (for example, specific `user.id` values and known management `host.id` endpoints) and continue to monitor for deviations from the expected pattern.
+  - Consider establishing a documented allowlist of approved share inventory scripts and their expected execution locations to reduce future triage time.
+
+
+==== 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:(
+    "Invoke-ShareFinder" or
+    "Invoke-ShareFinderThreaded" or
+    (
+      "shi1_netname" and
+      "shi1_remark"
+    ) or
+    (
+      "NetShareEnum" and
+      "NetApiBufferFree"
+    )
+  ) and not 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: Network Share Discovery
+** ID: T1135
+** Reference URL: https://attack.mitre.org/techniques/T1135/
+* 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/
+* Tactic:
+** Name: Collection
+** ID: TA0009
+** Reference URL: https://attack.mitre.org/tactics/TA0009/
+* Technique:
+** Name: Data from Network Shared Drive
+** ID: T1039
+** Reference URL: https://attack.mitre.org/techniques/T1039/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-suspicious-discovery-related-windows-api-functions.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-suspicious-discovery-related-windows-api-functions.asciidoc
new file mode 100644
index 0000000000..47ebeda163
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-suspicious-discovery-related-windows-api-functions.asciidoc
@@ -0,0 +1,246 @@
+[[prebuilt-rule-8-19-16-powershell-suspicious-discovery-related-windows-api-functions]]
+=== PowerShell Suspicious Discovery Related Windows API Functions
+
+Detects PowerShell scripts that references native Windows API functions commonly used for discovery of users, groups, shares, sessions, domain trusts, and service security. Attackers use these APIs for situational awareness and targeting prior to lateral movement or collection.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.powershell*
+
+*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://github.com/BC-SECURITY/Empire/blob/9259e5106986847d2bb770c4289c0c0f1adf2344/data/module_source/situational_awareness/network/powerview.ps1#L21413
+* 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: Discovery
+* Tactic: Collection
+* Tactic: Execution
+* Resources: Investigation Guide
+* Data Source: PowerShell Logs
+
+*Version*: 319
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Suspicious Discovery Related Windows API Functions*
+
+
+This rule flags PowerShell script block content that references Windows API functions commonly used to enumerate users, groups, shares, sessions, domain trusts, and service security. These APIs are frequently accessed via native interop patterns (for example, runtime-compiled type definitions) and can be used to build an inventory of the environment before follow-on activity such as lateral movement or collection.
+
+
+*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*
+
+
+- Establish context and expected behavior:
+  - Review `host.name`/`host.id` to understand where the activity occurred and whether the host is expected to perform administrative discovery.
+  - Review `user.name`, `user.domain`, and `user.id` to determine whether the executing identity aligns with expected administrative or automation activity for that host.
+  - Use `powershell.file.script_block_length` (when present) as a quick indicator of complexity; unusually large blocks may indicate embedded helper libraries or inline compiled source.
+
+- Review, reconstruct, and characterize the script content:
+  - Inspect `powershell.file.script_block_text` and identify which API function name(s) are present and what discovery objective they imply.
+  - If the script is fragmented, reconstruct it by grouping events on `powershell.file.script_block_id` and ordering by `powershell.sequence` until `powershell.total` is reached. Capture the complete reconstructed content for case notes.
+  - Look for indicators of native API invocation rather than standard cmdlets, such as embedded type definitions, interop attributes, or inline compiled source. This can increase confidence that the script was designed to directly call Windows APIs.
+  - Identify additional capabilities in the same script block (or neighboring fragments) that may indicate follow-on behavior, such as credential access, remote execution logic, output staging, or data access from remote resources.
+
+- Map API functions to likely discovery intent:
+  - Share and server discovery: `NetShareEnum`, `NetServerGetInfo`, `GetComputerNameEx`.
+  - User and group discovery: `NetUserEnum`, `NetUserGetInfo`, `NetGroupEnum`, `NetGroupGetInfo`, `NetGroupGetUsers`, `NetLocalGroupEnum`, `NetLocalGroupGetMembers`, `GetUserNameEx`, `NetUserModalsGet`.
+  - Session and workstation discovery: `NetSessionEnum`, `NetWkstaUserEnum`, `NetWkstaGetInfo`, `NetWkstaTransportEnum`, `WTSEnumerateSessionsEx`, `WTSQuerySessionInformation`, `LsaGetLogonSessionData`.
+  - Domain trust and site discovery: `DsEnumerateDomainTrusts`, `LsaEnumerateTrustedDomains`, `DsGetSiteName`.
+  - Service permission discovery: `QueryServiceObjectSecurity`.
+  - Job discovery: `NetScheduleJobEnum`.
+
+- Determine discovery scope and targets from the content:
+  - Extract any referenced hostnames, domain names, share names, or service names directly from `powershell.file.script_block_text` (when present) and record them as potential discovery targets.
+  - Look for indications of remote enumeration (for example, multiple target strings, iteration constructs, or repeated API calls with varying targets) versus single-host local discovery.
+  - Prioritize cases that include higher-impact reconnaissance (trust enumeration, session enumeration, logon session data, or service security descriptor queries), especially when the account or host context is unusual.
+
+- Validate script origin and execution source:
+  - If file context is present, review `file.path`, `file.directory`, and `file.name` to understand whether the script block originated from an on-disk script and whether that location aligns with approved tooling.
+  - Treat scripts originating from unexpected or user-writable locations, or scripts with unusual naming, as higher risk and scope for other related activity on the same host and by the same user.
+
+- Scope for related activity using alert-available pivots:
+  - Search for other script blocks with the same `powershell.file.script_block_id` to ensure no fragments are missed and to identify repeated execution.
+  - Search for additional hits of the same `file.path`/`file.name` across hosts to determine whether the script is broadly deployed or opportunistically introduced.
+  - Identify other occurrences of similar discovery content by pivoting on distinctive substrings within `powershell.file.script_block_text` (such as specific API function names) and the same `user.id` to detect a broader reconnaissance pattern.
+
+- Correlate with adjacent telemetry (as available in your environment):
+  - Process context: determine how PowerShell was started and whether the initiation method is consistent with expected activity for `user.name` on `host.name`.
+  - Authentication and remote access: look for logons or remote session activity involving the same `user.name` around the alert time, especially if the script content suggests remote enumeration of servers or sessions.
+  - Network and share access: review evidence of access to discovered targets (servers/shares) following the enumeration to identify potential collection from network shares.
+  - Persistence or privilege escalation follow-on: if service security or job enumeration is present, look for subsequent changes consistent with service or scheduled job manipulation.
+
+
+*False positive analysis*
+
+
+- Benign administrative discovery can occur during routine inventory, troubleshooting, or access validation, especially from dedicated administration hosts and by well-known administrative identities.
+- False positives are more likely when the same script content appears regularly, is consistently associated with the same `file.path`/`file.name`, and is executed by expected `user.name` accounts on expected hosts.
+- Prioritize as suspicious when the activity is new for the environment, originates from an unexpected script location, is executed by a non-administrative or unusual account, or appears across multiple hosts in a short period.
+
+
+*Response and remediation*
+
+
+- If the activity is confirmed or strongly suspected malicious:
+  - Contain the affected host and restrict the involved account to prevent further reconnaissance and follow-on actions.
+  - Preserve evidence from the alert, including the fully reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, and any extracted target identifiers, along with `host.id` and `user.id` for reliable correlation.
+  - Scope across the environment for additional executions using pivots on `user.id`, `host.id`, `file.path`/`file.name`, and distinctive content within `powershell.file.script_block_text`.
+  - Review the enumerated targets (hosts, shares, users/groups, trusts, services, sessions) for unauthorized access attempts and follow-on activity such as network share access, credential misuse, or lateral movement.
+
+- If the activity is determined to be legitimate but unexpected:
+  - Identify the script owner and document the business purpose, expected execution scope (hosts/users), and expected cadence.
+  - Reduce future noise by baselining approved scripts and execution contexts, and ensure logging and monitoring coverage remains sufficient to investigate future occurrences.
+
+
+==== 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 : (
+    NetShareEnum or
+    NetWkstaUserEnum or
+    NetSessionEnum or
+    NetLocalGroupEnum or
+    NetLocalGroupGetMembers or
+    DsGetSiteName or
+    DsEnumerateDomainTrusts or
+    WTSEnumerateSessionsEx or
+    WTSQuerySessionInformation or
+    LsaGetLogonSessionData or
+    QueryServiceObjectSecurity or
+    GetComputerNameEx or
+    NetWkstaGetInfo or
+    GetUserNameEx or
+    NetUserEnum or
+    NetUserGetInfo or
+    NetGroupEnum or
+    NetGroupGetInfo or
+    NetGroupGetUsers or
+    NetWkstaTransportEnum or
+    NetServerGetInfo or
+    LsaEnumerateTrustedDomains  or
+    NetScheduleJobEnum or
+    NetUserModalsGet
+  ) and
+  not powershell.file.script_block_text : (
+    ("DsGetSiteName" and ("DiscoverWindowsComputerProperties.ps1" and "param($SourceType, $SourceId, $ManagedEntityId, $ComputerIdentity)")) or
+    ("# Copyright: (c) 2018, Ansible Project" and "#Requires -Module Ansible.ModuleUtils.AddType" and "#AnsibleRequires -CSharpUtil Ansible.Basic") or
+    ("Ansible.Windows.Setup" and "Ansible.Windows.Setup" and "NativeMethods.NetWkstaGetInfo(null, 100, out netBuffer);")
+  ) and
+  not file.directory: "C:\Program Files (x86)\Automox\WDK\Win32\WinSession"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Discovery
+** ID: TA0007
+** Reference URL: https://attack.mitre.org/tactics/TA0007/
+* Technique:
+** Name: Permission Groups Discovery
+** ID: T1069
+** Reference URL: https://attack.mitre.org/techniques/T1069/
+* Sub-technique:
+** Name: Local Groups
+** ID: T1069.001
+** Reference URL: https://attack.mitre.org/techniques/T1069/001/
+* Technique:
+** Name: Account Discovery
+** ID: T1087
+** Reference URL: https://attack.mitre.org/techniques/T1087/
+* Sub-technique:
+** Name: Local Account
+** ID: T1087.001
+** Reference URL: https://attack.mitre.org/techniques/T1087/001/
+* Technique:
+** Name: Network Share Discovery
+** ID: T1135
+** Reference URL: https://attack.mitre.org/techniques/T1135/
+* Technique:
+** Name: Domain Trust Discovery
+** ID: T1482
+** Reference URL: https://attack.mitre.org/techniques/T1482/
+* 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/
+* Tactic:
+** Name: Collection
+** ID: TA0009
+** Reference URL: https://attack.mitre.org/tactics/TA0009/
+* Technique:
+** Name: Data from Network Shared Drive
+** ID: T1039
+** Reference URL: https://attack.mitre.org/techniques/T1039/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-suspicious-payload-encoded-and-compressed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-suspicious-payload-encoded-and-compressed.asciidoc
new file mode 100644
index 0000000000..12ebd76921
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-powershell-suspicious-payload-encoded-and-compressed.asciidoc
@@ -0,0 +1,203 @@
+[[prebuilt-rule-8-19-16-powershell-suspicious-payload-encoded-and-compressed]]
+=== PowerShell Suspicious Payload Encoded and Compressed
+
+Identifies PowerShell script block content that combines Base64 decoding with .NET decompression (Deflate/GZip). Attackers use this pattern to deobfuscate and reconstruct payloads in memory to evade defenses.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.powershell*
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+* Data Source: PowerShell Logs
+
+*Version*: 318
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Suspicious Payload Encoded and Compressed*
+
+
+This rule flags PowerShell script blocks that decode Base64 data and decompress it using .NET Deflate or GZip streams. This pattern is frequently used to conceal secondary script content or payloads until runtime. Focus on reconstructing the full script, recovering the decoded content, and identifying any follow-on execution on the host.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
+
+
+*Possible investigation steps*
+
+
+- Establish scope and priority using alert context:
+  - Review `host.name` / `host.id` to identify the affected endpoint and its role (workstation, server, jump host).
+  - Review `user.name` / `user.domain` / `user.id` to determine whether the account is expected to run PowerShell on this host and whether it is privileged or widely used.
+  - Check whether this user-host pairing is common or rare in your environment to help prioritize.
+
+- Identify script provenance and how it was introduced:
+  - Review `file.path`, `file.directory`, and `file.name` to determine whether the script block was sourced from an on-disk file.
+  - If `file.path` is present, assess whether the location aligns with normal administrative or automation activity for this host, or whether it appears user-writable, temporary, or otherwise unusual for the account and system role.
+  - If `file.path` is not present or is not informative, treat the content as potentially interactive or dynamically generated and prioritize reconstructing full script content.
+
+- Interpret the entropy indicators to guide analysis focus:
+  - Use `powershell.file.script_block_length` with `powershell.file.script_block_entropy_bits` to understand whether the alert is driven by a large embedded blob versus smaller obfuscation fragments.
+  - Use `powershell.file.script_block_surprisal_stdev` to distinguish between:
+    - Uniformly random-looking blocks (often consistent with compressed/encrypted data).
+    - Mixed content (often consistent with a readable wrapper that transforms and then executes an embedded payload).
+  - Use `powershell.file.script_block_unique_symbols` to identify whether the content resembles a limited alphabet encoding (for example, Base64-like) versus broader character sets.
+
+- Review and reconstruct script content before making a determination:
+  - Review `powershell.file.script_block_text` to identify:
+    - Large contiguous encoded strings, byte arrays, or character arrays.
+    - Transform routines (decode, decrypt, decompress) that produce secondary content.
+    - Secondary execution patterns where transformed content is immediately evaluated or invoked.
+    - Embedded external references (URLs, domains, IPs) or instructions to write content to disk.
+
+- Rebuild full content when script blocks are split across events:
+  - Pivot on `powershell.file.script_block_id` to collect all related fragments.
+  - Order fragments using `powershell.sequence` and validate completeness using `powershell.total`.
+  - Perform content review on the reconstructed output, not on individual fragments, to avoid missing loader logic or the embedded payload boundaries.
+
+- Extract indicators and correlate with adjacent telemetry to confirm impact:
+  - From `powershell.file.script_block_text` (and any safely decoded or decompressed content), extract indicators such as domains, URLs, IPs, file names/paths, and distinctive strings.
+  - Correlate on the same `host.id` and approximate timeframe with available endpoint telemetry to identify the PowerShell host process and its launch source (parent process or initiating mechanism). Use that context to assess whether execution is user-initiated, automation-driven, or suspicious.
+  - Correlate on the same `host.id` and timeframe with available network, file, registry, and authentication telemetry to identify follow-on activity consistent with script execution (downloads, file writes, persistence changes, or unusual sign-ins).
+
+- Expand scope to detect related activity:
+  - Search for additional high-entropy script blocks on the same `host.id` and `user.id` before and after the alert.
+  - Identify other hosts where the same `file.name` / `file.path` appears with similar suspicious content characteristics.
+  - Look for repeated substrings or structural similarities in `powershell.file.script_block_text` across different alerts to identify shared tooling or campaigns.
+
+
+*False positive analysis*
+
+
+- Benign activity can produce high-entropy script blocks when scripts embed packaged resources or data blobs (for example, installers, large configuration payloads, certificates, or compressed content used by administrative tooling).
+- Indicators that support a benign determination:
+  - Consistent `file.path` / `file.name` associated with a known internal automation package or vendor tool across many hosts.
+  - Stable and expected `user.name` / `user.id` usage (for example, dedicated automation accounts) with predictable host targeting.
+  - Repeated, consistent script structure over time where decoding or decompression results in recognizable administrative logic rather than staging or secondary execution.
+- If the alert is verified benign:
+  - Document the owning team/tool, expected hosts, and typical execution cadence.
+  - Suppress recurring noise by scoping on stable attributes available in the alert (for example, `user.id`, `host.id`, and `file.path`) while preserving visibility for new or unusual sources.
+
+
+*Response and remediation*
+
+
+- If malicious or suspicious activity is confirmed:
+  - Contain the affected host to limit further execution and lateral movement.
+  - Preserve evidence from the alert, including `powershell.file.script_block_text`, reconstructed content (using `powershell.file.script_block_id` / `powershell.sequence` / `powershell.total`), and associated context (`user.*`, `host.*`, `file.*`, and entropy metrics).
+  - Use extracted indicators from the script content to hunt for related activity across the environment and to identify additional affected hosts or accounts.
+  - Remediate any identified persistence or staging artifacts associated with the activity and remove malicious content from affected systems.
+  - If account compromise is suspected, reset credentials for `user.id` / `user.name` and review access paths and recent authentication activity for that account.
+
+- If benign activity is confirmed:
+  - Record the business justification and expected behavior for the script source, including the relevant `file.path` (when present) and the associated `user.id`.
+  - Monitor for deviations from the established benign baseline, such as new script sources, new hosts, or materially different `powershell.file.script_block_text` structure or entropy characteristics.
+
+
+==== 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
+
+This rule uses the following fields that require the Windows Integration v3.3.0 and up: `powershell.file.script_block_entropy_bits`.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.category:process and host.os.type:windows and
+  powershell.file.script_block_entropy_bits >= 4.5 and
+  powershell.file.script_block_text : (
+    (
+      "System.IO.Compression.DeflateStream" or
+      "System.IO.Compression.GzipStream" or
+      "IO.Compression.DeflateStream" or
+      "IO.Compression.GzipStream"
+    ) and
+    FromBase64String
+  ) and
+  not user.id : "S-1-5-18"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-program-files-directory-masquerading.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-program-files-directory-masquerading.asciidoc
new file mode 100644
index 0000000000..a374aec566
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-program-files-directory-masquerading.asciidoc
@@ -0,0 +1,147 @@
+[[prebuilt-rule-8-19-16-program-files-directory-masquerading]]
+=== Program Files Directory Masquerading
+
+Identifies execution from a directory masquerading as the Windows Program Files directories. These paths are trusted and usually host trusted third party programs. An adversary may leverage masquerading, along with low privileges to bypass detections allowlisting those folders.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* endgame-*
+* logs-crowdstrike.fdr*
+* logs-endpoint.events.process-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-system.security*
+* logs-windows.forwarded*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Windows Security Event Logs
+* Data Source: Microsoft Defender for Endpoint
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 319
+
+*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 Program Files Directory Masquerading*
+
+
+The Program Files directories in Windows are trusted locations for legitimate software. Adversaries may exploit this trust by creating similarly named directories to execute malicious files, bypassing security measures. The detection rule identifies suspicious executions from these masquerading paths, excluding known legitimate directories, to flag potential threats. This helps in identifying defense evasion tactics used by attackers.
+
+
+*Possible investigation steps*
+
+
+- Review the process executable path to confirm if it matches any known masquerading patterns, such as unexpected directories containing "Program Files" in their path.
+- Check the parent process of the suspicious executable to determine how it was launched and assess if the parent process is legitimate or potentially malicious.
+- Investigate the user account associated with the process execution to determine if it has low privileges and if the activity aligns with typical user behavior.
+- Correlate the event with other security logs or alerts from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns.
+- Examine the file hash of the executable to see if it matches known malware signatures or if it has been flagged in threat intelligence databases.
+- Assess the network activity associated with the process to identify any unusual outbound connections that could indicate data exfiltration or command-and-control communication.
+
+
+*False positive analysis*
+
+
+- Legitimate software installations or updates may create temporary directories resembling Program Files paths. Users can monitor installation logs and exclude these specific paths if they are verified as part of a legitimate process.
+- Some enterprise applications may use custom directories that mimic Program Files for compatibility reasons. IT administrators should document these paths and add them to the exclusion list to prevent false alerts.
+- Development environments might create test directories with similar naming conventions. Developers should ensure these paths are excluded during active development phases to avoid unnecessary alerts.
+- Security tools or scripts that perform regular checks or updates might execute from non-standard directories. Verify these tools and add their execution paths to the exception list if they are confirmed safe.
+- Backup or recovery software might temporarily use directories that resemble Program Files for storing executable files. Confirm the legitimacy of these operations and exclude the paths if they are part of routine backup processes.
+
+
+*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 any suspicious processes identified as executing from masquerading directories to halt any ongoing malicious actions.
+- 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 restore any altered system configurations or settings to their original state to ensure system integrity.
+- 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 additional monitoring on the affected system and similar environments to detect any recurrence of the threat or similar tactics.
+- Update security policies and access controls to prevent unauthorized creation of directories that mimic trusted paths, enhancing defenses against similar masquerading attempts.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+  process.executable : (
+    "C:\\*Program Files*\\*.exe",
+    "\\Device\\HarddiskVolume*\\*Program Files*\\*.exe"
+  ) and
+  not process.executable : (
+        "?:\\Program Files\\*.exe",
+        "?:\\Program Files (x86)\\*.exe",
+        "?:\\Users\\*.exe",
+        "?:\\ProgramData\\*.exe",
+        "?:\\Windows\\Downloaded Program Files\\*.exe",
+        "?:\\Windows\\Temp\\.opera\\????????????\\CProgram?FilesOpera*\\*.exe",
+        "?:\\Windows\\Temp\\.opera\\????????????\\CProgram?Files?(x86)Opera*\\*.exe",
+
+        /* NT Object Paths */
+        "\\Device\\HarddiskVolume*\\Program Files\\*.exe",
+        "\\Device\\HarddiskVolume*\\Program Files (x86)\\*.exe",
+        "\\Device\\HarddiskVolume*\\Users\\*.exe",
+        "\\Device\\HarddiskVolume*\\ProgramData\\*.exe",
+        "\\Device\\HarddiskVolume*\\Windows\\Downloaded Program Files\\*.exe"
+  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Masquerading
+** ID: T1036
+** Reference URL: https://attack.mitre.org/techniques/T1036/
+* Sub-technique:
+** Name: Match Legitimate Resource Name or Location
+** ID: T1036.005
+** Reference URL: https://attack.mitre.org/techniques/T1036/005/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-spike-in-number-of-connections-made-from-a-source-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-spike-in-number-of-connections-made-from-a-source-ip.asciidoc
new file mode 100644
index 0000000000..a0da36dff0
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-spike-in-number-of-connections-made-from-a-source-ip.asciidoc
@@ -0,0 +1,139 @@
+[[prebuilt-rule-8-19-16-spike-in-number-of-connections-made-from-a-source-ip]]
+=== Spike in Number of Connections Made from a Source IP
+
+A machine learning job has detected a high count of destination IPs establishing an RDP connection with a single source IP. Once an attacker has gained access to one system, they might attempt to access more in the network in search of valuable assets, data, or further access points.
+
+*Rule type*: machine_learning
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 15m
+
+*Searches indices from*: now-12h ({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/security/current/prebuilt-ml-jobs.html
+* https://docs.elastic.co/en/integrations/lmd
+* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration
+* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security
+
+*Tags*: 
+
+* Use Case: Lateral Movement Detection
+* Rule Type: ML
+* Rule Type: Machine Learning
+* Tactic: Lateral Movement
+* Resources: Investigation Guide
+
+*Version*: 8
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Spike in Number of Connections Made from a Source IP*
+
+
+Remote Desktop Protocol (RDP) is a common tool for remote management, but adversaries exploit it for lateral movement within networks. By establishing numerous connections from a single IP, attackers seek to expand their access. This detection rule leverages machine learning to identify unusual spikes in RDP connections, signaling potential unauthorized access attempts, and aids in early threat identification.
+
+
+*Possible investigation steps*
+
+
+- Review the source IP address to determine if it is a known or trusted entity within the network.
+- Analyze the list of destination IPs to identify any unusual or unauthorized systems being accessed.
+- Check the timestamps of the connections to see if they align with expected activity patterns or occur during unusual hours.
+- Investigate the user account associated with the RDP connections to verify if it has been compromised or is being misused.
+- Correlate the spike in connections with any recent changes or incidents in the network that might explain the activity.
+- Examine network logs and RDP session logs for any signs of suspicious behavior or anomalies during the connection attempts.
+
+
+*False positive analysis*
+
+
+- Routine administrative tasks can trigger spikes in RDP connections. Regularly scheduled maintenance or software updates may cause a high number of connections from a single IP. To manage this, identify and whitelist IPs associated with known administrative activities.
+- Automated scripts or tools used for network management might establish multiple RDP connections. Review and document these tools, then create exceptions for their IP addresses to prevent false alerts.
+- Load balancers or proxy servers can appear as a single source IP making numerous connections. Verify the network architecture and exclude these IPs from the rule to avoid misidentification.
+- Security scans or vulnerability assessments conducted by internal teams can result in a spike of connections. Coordinate with security teams to recognize these activities and exclude their IPs from triggering the rule.
+- Remote work solutions or VPNs might centralize connections through a single IP, leading to false positives. Identify these IPs and adjust the rule to accommodate legitimate remote access patterns.
+
+
+*Response and remediation*
+
+
+- Isolate the affected system immediately to prevent further lateral movement within the network. Disconnect it from the network or place it in a quarantine VLAN.
+- Terminate any unauthorized RDP sessions originating from the identified source IP to halt ongoing unauthorized access attempts.
+- Conduct a thorough review of the affected system for signs of compromise, including checking for unauthorized user accounts, changes in system configurations, and the presence of malware or suspicious files.
+- Reset credentials for any accounts accessed via the compromised system to prevent further unauthorized access using stolen credentials.
+- Implement network segmentation to limit RDP access to only necessary systems and users, reducing the attack surface for lateral movement.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach.
+- Update and enhance monitoring rules to detect similar patterns of unusual RDP connection spikes, ensuring early detection of future attempts.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
+
+
+*Lateral Movement Detection Setup*
+
+The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Lateral Movement Detection.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+- Windows RDP process events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] integration.
+- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation].
+
+
+*The following steps should be executed to install assets associated with the Lateral Movement Detection integration:*
+
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-spike-in-number-of-connections-made-to-a-destination-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-spike-in-number-of-connections-made-to-a-destination-ip.asciidoc
new file mode 100644
index 0000000000..311cba0ede
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-spike-in-number-of-connections-made-to-a-destination-ip.asciidoc
@@ -0,0 +1,138 @@
+[[prebuilt-rule-8-19-16-spike-in-number-of-connections-made-to-a-destination-ip]]
+=== Spike in Number of Connections Made to a Destination IP
+
+A machine learning job has detected a high count of source IPs establishing an RDP connection with a single destination IP. Attackers might use multiple compromised systems to attack a target to ensure redundancy in case a source IP gets detected and blocked.
+
+*Rule type*: machine_learning
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 15m
+
+*Searches indices from*: now-12h ({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/security/current/prebuilt-ml-jobs.html
+* https://docs.elastic.co/en/integrations/lmd
+* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration
+* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security
+
+*Tags*: 
+
+* Use Case: Lateral Movement Detection
+* Rule Type: ML
+* Rule Type: Machine Learning
+* Tactic: Lateral Movement
+* Resources: Investigation Guide
+
+*Version*: 8
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Spike in Number of Connections Made to a Destination IP*
+
+
+Remote Desktop Protocol (RDP) is crucial for remote management and troubleshooting in IT environments. However, adversaries exploit RDP by using multiple compromised IPs to overwhelm a target, ensuring persistence even if some IPs are blocked. The detection rule leverages machine learning to identify unusual spikes in RDP connections to a single IP, signaling potential lateral movement attempts by attackers.
+
+
+*Possible investigation steps*
+
+
+- Review the list of source IPs that have established RDP connections to the destination IP to identify any known malicious or suspicious IP addresses.
+- Check historical data for the destination IP to determine if it has been targeted in previous attacks or if it is a high-value asset within the network.
+- Analyze the timing and frequency of the RDP connections to identify any unusual patterns or spikes that could indicate coordinated activity.
+- Investigate the user accounts associated with the RDP connections to ensure they are legitimate and have not been compromised.
+- Correlate the detected activity with any other security alerts or logs to identify potential lateral movement or further exploitation attempts within the network.
+
+
+*False positive analysis*
+
+
+- Routine administrative tasks may trigger false positives if multiple IT staff connect to a server for maintenance. Consider creating exceptions for known administrative IPs.
+- Automated scripts or monitoring tools that frequently connect to servers for health checks can cause spikes. Identify and exclude these IPs from the rule.
+- Load balancers or proxy servers that aggregate connections from multiple clients might appear as a spike. Exclude these devices from the detection rule.
+- Scheduled software updates or deployments that require multiple connections to a server can be mistaken for an attack. Whitelist the IPs involved in these processes.
+- Internal network scans or vulnerability assessments conducted by security teams can generate high connection counts. Ensure these activities are recognized and excluded.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected destination IP from the network to prevent further unauthorized RDP connections and potential lateral movement.
+- Conduct a thorough review of the logs and network traffic associated with the destination IP to identify all source IPs involved in the spike and assess the scope of the compromise.
+- Block all identified malicious source IPs at the firewall or network perimeter to prevent further connections to the destination IP.
+- Reset credentials and enforce multi-factor authentication for accounts that were accessed via RDP to mitigate unauthorized access.
+- Perform a security assessment of the affected systems to identify any signs of compromise or unauthorized changes, and restore systems from clean backups if necessary.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or networks are affected.
+- Update and enhance monitoring rules to detect similar patterns of unusual RDP connection spikes in the future, ensuring quick identification and response to potential threats.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
+
+
+*Lateral Movement Detection Setup*
+
+The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Lateral Movement Detection.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+- Windows RDP process events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] integration.
+- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation].
+
+
+*The following steps should be executed to install assets associated with the Lateral Movement Detection integration:*
+
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-spike-in-number-of-processes-in-an-rdp-session.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-spike-in-number-of-processes-in-an-rdp-session.asciidoc
new file mode 100644
index 0000000000..1857379f9f
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-spike-in-number-of-processes-in-an-rdp-session.asciidoc
@@ -0,0 +1,138 @@
+[[prebuilt-rule-8-19-16-spike-in-number-of-processes-in-an-rdp-session]]
+=== Spike in Number of Processes in an RDP Session
+
+A machine learning job has detected unusually high number of processes started in a single RDP session. Executing a large number of processes remotely on other machines can be an indicator of lateral movement activity.
+
+*Rule type*: machine_learning
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 15m
+
+*Searches indices from*: now-12h ({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/security/current/prebuilt-ml-jobs.html
+* https://docs.elastic.co/en/integrations/lmd
+* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration
+* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security
+
+*Tags*: 
+
+* Use Case: Lateral Movement Detection
+* Rule Type: ML
+* Rule Type: Machine Learning
+* Tactic: Lateral Movement
+* Resources: Investigation Guide
+
+*Version*: 8
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Spike in Number of Processes in an RDP Session*
+
+
+Remote Desktop Protocol (RDP) allows users to connect to other computers over a network, facilitating remote work and administration. However, adversaries can exploit RDP for lateral movement by executing numerous processes on a target machine. The detection rule leverages machine learning to identify anomalies in process activity during RDP sessions, flagging potential exploitation attempts indicative of lateral movement tactics.
+
+
+*Possible investigation steps*
+
+
+- Review the specific RDP session details, including the source and destination IP addresses, to identify the involved machines and users.
+- Analyze the list of processes that were started during the RDP session to identify any unusual or suspicious processes that are not typically associated with legitimate remote work activities.
+- Check the user account associated with the RDP session for any signs of compromise, such as recent password changes or unusual login times.
+- Correlate the detected spike in processes with other security events or logs, such as firewall logs or intrusion detection system alerts, to identify any related suspicious activities.
+- Investigate the network traffic between the source and destination machines during the RDP session to detect any anomalies or unauthorized data transfers.
+- Review historical data for the involved user and machines to determine if similar spikes in process activity have occurred in the past, which could indicate a pattern of malicious behavior.
+
+
+*False positive analysis*
+
+
+- High-volume automated tasks or scripts executed during RDP sessions can trigger false positives. Identify and document these tasks, then create exceptions in the detection rule to exclude them from analysis.
+- Routine administrative activities, such as software updates or system maintenance, may result in a spike in processes. Regularly review and whitelist these activities to prevent unnecessary alerts.
+- Scheduled batch jobs or data processing tasks that run during RDP sessions can be mistaken for lateral movement. Ensure these are logged and excluded from the rule's scope by setting up appropriate filters.
+- Development or testing environments where multiple processes are frequently started as part of normal operations can lead to false positives. Clearly define these environments and adjust the rule to ignore such sessions.
+
+
+*Response and remediation*
+
+
+- Isolate the affected machine from the network to prevent further lateral movement and contain the threat.
+- Terminate any suspicious or unauthorized processes identified during the RDP session to halt potential malicious activity.
+- Conduct a thorough review of the affected machine's security logs to identify any additional indicators of compromise or related suspicious activity.
+- Reset credentials for any accounts that were used during the suspicious RDP session to prevent unauthorized access.
+- Apply security patches and updates to the affected machine and any other vulnerable systems to mitigate exploitation of known vulnerabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Enhance monitoring and detection capabilities for RDP sessions by implementing stricter access controls and logging to detect similar anomalies in the future.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
+
+
+*Lateral Movement Detection Setup*
+
+The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Lateral Movement Detection.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+- Windows RDP process events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] integration.
+- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation].
+
+
+*The following steps should be executed to install assets associated with the Lateral Movement Detection integration:*
+
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-spike-in-remote-file-transfers.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-spike-in-remote-file-transfers.asciidoc
new file mode 100644
index 0000000000..2681eda977
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-spike-in-remote-file-transfers.asciidoc
@@ -0,0 +1,139 @@
+[[prebuilt-rule-8-19-16-spike-in-remote-file-transfers]]
+=== Spike in Remote File Transfers
+
+A machine learning job has detected an abnormal volume of remote files shared on the host indicating potential lateral movement activity. One of the primary goals of attackers after gaining access to a network is to locate and exfiltrate valuable information. Attackers might perform multiple small transfers to match normal egress activity in the network, to evade detection.
+
+*Rule type*: machine_learning
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 15m
+
+*Searches indices from*: now-90m ({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/security/current/prebuilt-ml-jobs.html
+* https://docs.elastic.co/en/integrations/lmd
+* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration
+* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security
+
+*Tags*: 
+
+* Use Case: Lateral Movement Detection
+* Rule Type: ML
+* Rule Type: Machine Learning
+* Tactic: Lateral Movement
+* Resources: Investigation Guide
+
+*Version*: 8
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Spike in Remote File Transfers*
+
+
+Remote file transfer technologies facilitate data sharing across networks, essential for collaboration and operations. However, adversaries exploit these to move laterally within a network, often transferring data stealthily to avoid detection. The 'Spike in Remote File Transfers' detection rule leverages machine learning to identify unusual transfer volumes, signaling potential malicious activity by comparing against established network baselines.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific host and time frame associated with the abnormal file transfer activity.
+- Analyze network logs and remote file transfer logs to determine the source and destination of the transfers, focusing on any unusual or unauthorized endpoints.
+- Cross-reference the identified host with known assets and user accounts to verify if the activity aligns with expected behavior or if it involves unauthorized access.
+- Investigate any associated user accounts for signs of compromise, such as unusual login times or locations, by reviewing authentication logs.
+- Check for any recent changes or anomalies in the network baseline that could explain the spike in file transfers, such as new software deployments or legitimate large data migrations.
+- Correlate the detected activity with other security alerts or incidents to identify potential patterns or coordinated attacks within the network.
+
+
+*False positive analysis*
+
+
+- Regularly scheduled data backups or synchronization tasks can trigger false positives. Identify these tasks and create exceptions to prevent them from being flagged.
+- Automated software updates or patch management systems may cause spikes in file transfers. Exclude these systems from the rule to reduce false alerts.
+- Internal data sharing between departments for legitimate business purposes might be misidentified. Establish a baseline for these activities and adjust the detection thresholds accordingly.
+- High-volume data transfers during specific business operations, such as end-of-month reporting, can be mistaken for malicious activity. Temporarily adjust the rule settings during these periods to accommodate expected increases in transfer volumes.
+- Frequent file transfers from trusted external partners or vendors should be monitored and, if consistently benign, added to an allowlist to minimize unnecessary alerts.
+
+
+*Response and remediation*
+
+
+- Isolate the affected host immediately to prevent further lateral movement and potential data exfiltration. Disconnect it from the network to contain the threat.
+- Conduct a thorough analysis of the transferred files to determine if sensitive data was involved and assess the potential impact of the data exposure.
+- Review and terminate any unauthorized remote access sessions or services on the affected host to prevent further exploitation.
+- Reset credentials for any accounts that were used or potentially compromised during the incident to prevent unauthorized access.
+- Apply security patches and updates to the affected systems to address any vulnerabilities that may have been exploited by the attackers.
+- Monitor network traffic for any additional unusual remote file transfer activities, using enhanced logging and alerting 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.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
+
+
+*Lateral Movement Detection Setup*
+
+The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Lateral Movement Detection.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+- File events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] integration.
+- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation].
+
+
+*The following steps should be executed to install assets associated with the Lateral Movement Detection integration:*
+
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspected-lateral-movement-from-compromised-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspected-lateral-movement-from-compromised-host.asciidoc
new file mode 100644
index 0000000000..53b6929a27
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspected-lateral-movement-from-compromised-host.asciidoc
@@ -0,0 +1,147 @@
+[[prebuilt-rule-8-19-16-suspected-lateral-movement-from-compromised-host]]
+=== Suspected Lateral Movement from Compromised Host
+
+Detects potential lateral movement or post-compromise activity by correlating alerts where the host.ip of one alert matches the source.ip of a subsequent alert. This behavior may indicate a compromised host being used to authenticate to another system or resource, including cloud services.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 29m
+
+*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*: None
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Resources: Investigation Guide
+
+*Version*: 4
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Suspected Lateral Movement from Compromised Host*
+
+
+The detection rule uses alert data to determine when multiple alerts from different integrations involving the same user.name are triggered.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific host involved and the different modules and rules that triggered the alert.
+- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
+- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
+- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
+- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
+- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
+
+
+*False positive analysis*
+
+
+- Vulnerability scanners.
+- Jump hosts, NAT gateways and proxies.
+
+
+*Response and remediation*
+
+
+- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
+- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
+- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from .alerts-security.*
+
+// any alerts excluding deprecated, low severity and threat_match rules
+| where kibana.alert.rule.name is not null and kibana.alert.risk_score > 21 and
+        kibana.alert.rule.type != "threat_match" and
+        not kibana.alert.rule.name like "Deprecated - *" and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) and
+        not kibana.alert.rule.name in ("Abnormally Large DNS Response", "Web Application Suspicious Activity: No User Agent")
+
+// alerts with existing source.ip or host.ip
+| eval alert_source_ip = CASE(source.ip is not null, source.ip, null),
+       alert_host_ip = CASE(host.ip is not null and source.ip is null, host.ip, null)
+
+| eval Esql.source_ip = COALESCE(alert_source_ip, alert_host_ip)
+| where Esql.source_ip is not null and Esql.source_ip != "127.0.0.1" and Esql.source_ip != "::1"
+
+| stats Esql.alerts_count = COUNT(*),
+        Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
+        Esql.host_id_distinct_count = COUNT_DISTINCT(host.id),
+        Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
+        Esql.event_module_values = VALUES(event.module),
+        Esql.message_values = VALUES(message),
+        Esql.rule_name = VALUES(kibana.alert.rule.name),
+        Esql.event_action_values = VALUES(event.action),
+        Esql.event_category_values = VALUES(event.category),
+        Esql.process_executable_values = VALUES(process.executable),
+        Esql.process_cmdline_values = VALUES(process.command_line),
+        Esql.file_path_values = VALUES(file.path),
+        Esql.host_id_values = VALUES(host.id),
+        Esql.host_ip_values = VALUES(host.ip),
+        Esql.destination_ip_values = VALUES(destination.ip),
+        Esql.user_name_values = VALUES(user.name),
+        SRC_IP = VALUES(source.ip)
+        by Esql.source_ip
+
+// filter for different alerts from multiple hosts and where the host.ip of one alert matches the source.ip of the other alert
+| eval concat_ip_values = MV_CONCAT(TO_STRING(Esql.host_ip_values), ",")
+| eval host_ip_equal_to_source_ip =LOCATE(concat_ip_values, TO_STRING(Esql.source_ip))
+| where Esql.rule_name_distinct_count >= 2 and Esql.host_id_distinct_count >= 2 and host_ip_equal_to_source_ip > 0 and SRC_IP is not null and Esql.alerts_count <= 100
+
+// Move single values to their corresponding ECS fields for alerts exclusion
+| eval source.ip = mv_min(Esql.source_ip),
+       host.id = mv_min(Esql.host_id_values)
+| KEEP Esql.*, source.ip, host.id
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspicious-command-prompt-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspicious-command-prompt-network-connection.asciidoc
new file mode 100644
index 0000000000..9dd2978b1f
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspicious-command-prompt-network-connection.asciidoc
@@ -0,0 +1,179 @@
+[[prebuilt-rule-8-19-16-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.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-endpoint.events.process-*
+* logs-endpoint.events.network-*
+* logs-windows.sysmon_operational-*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Execution
+* Resources: Investigation Guide
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: SentinelOne
+
+*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 Command Prompt Network Connection*
+
+
+This alert identifies a Windows `cmd.exe` process start event that is quickly followed by a network connection from the same `cmd.exe` instance (`process.entity_id`). The command line indicates scripted execution (batch files), references to remote resources (URL-like strings), or execution launched by a Microsoft Office application. This pattern can be used to download payloads, stage execution, or establish command and control.
+
+
+*Triage and analysis steps*
+
+
+- Confirm the matched sequence and keep analysis tied to the correct process instance:
+  - Use the `Investigate in timeline` button in the Alerts table or pivot on `process.entity_id` to review both the process start event and the associated network event(s).
+  - Example KQL pivots:
+    - `process.entity_id:"<process_entity_id>" and event.category:process`
+    - `process.entity_id:"<process_entity_id>" and event.category:network`
+
+- Determine why `cmd.exe` matched and assess intent:
+  - Review `process.args` to confirm the interpreter switch (`/c` to execute and exit, `/k` to remain open).
+  - Identify which match condition applies:
+    - Batch script: `process.args` includes a `.bat` or `.cmd` reference.
+    - Remote resource: `process.command_line` contains `http://`, `https://`, or `ftp://`.
+    - Office parent: `process.parent.name` is one of `winword.exe`, `excel.exe`, `powerpnt.exe`, `outlook.exe`, `msaccess.exe`, or `mspub.exe`.
+  - Look for staging or obfuscation patterns in `process.command_line` (for example: `&`/`&&`/`||`, pipes `|`, redirection `>`/`>>`, escaping `^`, environment variables, or long encoded strings).
+
+- Validate the execution context and launch vector:
+  - Review `user.*` fields to determine who ran the command and whether it is expected for the host role.
+  - Review `process.parent.name` (and `process.parent.command_line` if available) to understand the initial trigger:
+    - Office parent: prioritize identifying the initiating document or message and any user interaction around `@timestamp`.
+    - Management tooling or installer parent: validate change control and whether the command line and destination are consistent with that software.
+  - If a batch script is referenced, locate the script on the host (if telemetry allows) and capture path and hash (`file.path`, `file.hash.sha256`) for scoping.
+
+- Analyze the outbound destination:
+  - Review `destination.ip` and `destination.port` for expectedness (business relationship, known vendor, or organization-owned public IP space).
+  - Note: the rule excludes common private and reserved address ranges, but it can still alert on connections to legitimate public services.
+  - Pivot on `destination.ip` to identify other hosts contacting the same destination near `@timestamp`:
+    - `destination.ip:"<destination_ip>" and event.category:network`
+  - Check whether the same `process.entity_id` generated repeated connections (potential beaconing) versus a single connection (one-time retrieval).
+
+- Reconstruct follow-on activity and potential impact:
+  - Identify child processes spawned by `cmd.exe` and look for common follow-on tooling (for example: `powershell.exe`, `mshta.exe`, `rundll32.exe`, `regsvr32.exe`, `certutil.exe`, `bitsadmin.exe`, `curl.exe`, `wget.exe`).
+  - If file telemetry is available, review file creation/modification shortly after `@timestamp` and correlate any new binaries or scripts with hashes and execution events.
+
+- Scope the activity (blast radius):
+  - Search for the same `process.command_line` (or distinctive substrings), script name, or extracted URL across endpoints.
+  - Search for other `cmd.exe` instances connecting to the same `destination.ip` or the same destination port/protocol.
+  - If the parent is Office, scope for the same parent-child relationship (`process.parent.name` -> `cmd.exe`) across users and hosts.
+
+
+*False positive analysis*
+
+
+- Software deployment, packaging, or endpoint management workflows that use `cmd.exe /c` to run batch scripts and contact vendor services.
+- Signed installer or updater activity where `cmd.exe` is used as a helper process with stable command lines.
+- Documented Office macros/add-ins/templates that legitimately spawn `cmd.exe` with consistent command lines and destinations.
+
+A benign determination is more likely when the combination of `process.parent.name`, stable `process.command_line`, and consistent `destination.ip`/`destination.port` repeats across an expected set of hosts and users and aligns to a documented workflow owner.
+
+
+*Response and remediation*
+
+
+- If the activity is suspicious or cannot be attributed to an approved workflow:
+  - Contain the affected endpoint (`host.id`) using available endpoint or network controls.
+  - Preserve evidence (at minimum):
+    - `@timestamp`, `host.*`, `user.*`
+    - `process.entity_id`, `process.command_line`, `process.args`, `process.parent.*`
+    - `destination.ip`, `destination.port`, `network.*`
+    - Any related child processes and file artifacts (paths and hashes) identified during triage
+  - Scope for related activity by searching for additional occurrences of the same destination and command-line patterns.
+  - If Office is the launch vector, identify and quarantine the initiating document or email and assess whether similar content was delivered to other users.
+  - If a script is involved, collect and review the script contents and investigate how it was introduced (downloads, email attachments, shared drives, logon scripts, scheduled tasks).
+  - If account compromise is suspected, follow established identity response procedures (credential reset, session review, and access auditing).
+
+- If the activity is confirmed benign:
+  - Document the expected parent process, command-line pattern, and destinations.
+  - Consider adding a narrowly scoped exception using stable identifiers and constrained conditions (for example, specific `process.command_line` patterns and known destinations) to reduce recurring noise.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by process.entity_id with maxspan=15s
+  [process where host.os.type == "windows" and event.type == "start" and
+    process.name : "cmd.exe" and process.args : ("/c", "/k") and
+    (
+      process.args : ("*.bat", "*.cmd") or
+      process.command_line : ("*http://*", "*https://*", "*ftp://*") or
+      process.parent.name : ("excel.exe", "msaccess.exe", "mspub.exe", "powerpnt.exe", "winword.exe", "outlook.exe")
+    )
+  ]
+  [network where host.os.type == "windows" and process.name : "cmd.exe" and
+     not 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")]
+
+----------------------------------
+
+*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: 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-16/prebuilt-rule-8-19-16-suspicious-execution-from-a-mounted-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspicious-execution-from-a-mounted-device.asciidoc
new file mode 100644
index 0000000000..1bb0d572cf
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspicious-execution-from-a-mounted-device.asciidoc
@@ -0,0 +1,153 @@
+[[prebuilt-rule-8-19-16-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.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-endpoint.events.process-*
+* logs-windows.sysmon_operational-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.microsoft.com/security/blog/2021/05/27/new-sophisticated-email-based-attack-from-nobelium/
+* https://www.volexity.com/blog/2021/05/27/suspected-apt29-operation-launches-election-fraud-themed-phishing-campaigns/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Tactic: Execution
+* 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*
+
+
+> **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 a Mounted Device*
+
+
+In Windows environments, script interpreters and signed binaries are essential for executing legitimate tasks. However, adversaries can exploit these by launching them from non-standard directories, such as mounted devices, to bypass security measures. The detection rule identifies such anomalies by monitoring processes initiated from unexpected directories, especially when triggered by common parent processes like explorer.exe, thus flagging potential defense evasion attempts.
+
+
+*Possible investigation steps*
+
+
+- Review the process details to confirm the executable path and working directory, ensuring they match the criteria of being launched from a non-standard directory (e.g., not from "C:\\").
+- Investigate the parent process, explorer.exe, to determine if there are any unusual activities or user actions that might have triggered the suspicious execution.
+- Check the user account associated with the process to verify if the activity aligns with their typical behavior or if the account might be compromised.
+- Analyze the command line arguments used by the suspicious process to identify any potentially malicious scripts or commands being executed.
+- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise.
+- Examine the mounted device from which the process was executed to determine its origin, legitimacy, and any associated files that might be malicious.
+
+
+*False positive analysis*
+
+
+- Legitimate software installations or updates may trigger the rule if they are executed from a mounted device. Users can create exceptions for known software update processes that are verified as safe.
+- Portable applications running from USB drives or external storage can be flagged. To mitigate this, users should whitelist specific applications that are frequently used and deemed non-threatening.
+- IT administrative scripts executed from network shares or mounted drives for maintenance tasks might be detected. Users can exclude these scripts by specifying trusted network paths or script names.
+- Development environments where scripts are tested from non-standard directories can cause alerts. Developers should ensure their working directories are recognized as safe or use designated development machines with adjusted monitoring rules.
+- Backup or recovery operations that utilize mounted devices for script execution may be misidentified. Users should identify and exclude these operations by defining exceptions for known backup tools and processes.
+
+
+*Response and remediation*
+
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified by the detection rule, such as those initiated by script interpreters or signed binaries from non-standard directories.
+- Conduct a forensic analysis of the mounted device and the affected system to identify any malicious payloads or scripts and remove them.
+- Review and restore any altered system configurations or registry settings to their original state to ensure system integrity.
+- Update and patch the system to close any vulnerabilities that may have been exploited by the attacker.
+- Monitor for any recurrence of similar activities by enhancing logging and alerting mechanisms, focusing on process execution from non-standard directories.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and process.executable : "C:\\*" and
+  (
+    process.working_directory : ("D:\\*", "E:\\*", "F:\\*") or
+    ?process.Ext.device.product_id : ("Virtual DVD-ROM", "Virtual Disk")
+  ) and
+  process.parent.name : "explorer.exe" and
+  process.name : (
+    "rundll32.exe", "mshta.exe", "powershell.exe", "pwsh.exe", "cmd.exe", "regsvr32.exe", "cscript.exe",
+    "wscript.exe", "certutil.exe", "bitsadmin.exe", "msiexec.exe", "wmic.exe", "schtasks.exe", "msbuild.exe"
+  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* 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/
+* Sub-technique:
+** Name: Regsvr32
+** ID: T1218.010
+** Reference URL: https://attack.mitre.org/techniques/T1218/010/
+* 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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspicious-net-reflection-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspicious-net-reflection-via-powershell.asciidoc
new file mode 100644
index 0000000000..a9352e7aaa
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspicious-net-reflection-via-powershell.asciidoc
@@ -0,0 +1,205 @@
+[[prebuilt-rule-8-19-16-suspicious-net-reflection-via-powershell]]
+=== Suspicious .NET Reflection via PowerShell
+
+Detects PowerShell scripts that invoke Reflection.Assembly or Assembly.Load to load .NET assemblies. Attackers use this method to load executables and DLLs without writing to the disk, bypassing security solutions.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.powershell*
+
+*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/dotnet/api/system.reflection.assembly.load
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Tactic: Execution
+* Resources: Investigation Guide
+* Data Source: PowerShell Logs
+
+*Version*: 321
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Suspicious .NET Reflection via PowerShell*
+
+
+This alert indicates PowerShell script block content attempted to load a .NET assembly using reflection-based APIs (for example, `[System.Reflection.Assembly]::Load` or `Assembly.Load(...)`). While this can be used for legitimate extensibility, it is also commonly used to execute .NET payloads in memory and reduce file-based artifacts.
+
+
+*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*
+
+
+- Triage the execution context:
+  - Identify the affected host and user using `host.name`, `host.id`, `user.name`, `user.domain`, and `user.id`.
+  - Prioritize alerts where the user is unexpected for the host role, or where the same user appears across multiple hosts in a short time window.
+- Analyze the assembly load behavior in `powershell.file.script_block_text`:
+  - Identify what is being passed into the load call (assembly name vs. byte array or dynamically generated content).
+  - Check for indicators of staged content within the same script block, such as long encoded blobs, dynamic string construction, or multiple transformation steps (decoding, decompression, or concatenation) that produce the assembly bytes.
+  - Look for immediate follow-on actions suggesting the loaded assembly is executed (for example, accessing types/methods and invoking them after the load).
+- Reconstruct the full script block when needed:
+  - If the content appears partial, group related events by `powershell.file.script_block_id` and order by `powershell.sequence` to `powershell.total` to rebuild the full script block before assessing intent.
+  - Use `powershell.file.script_block_length` as a signal for embedded content (large or unusually variable sizes can indicate payload staging).
+- Determine script origin and persistence indicators:
+  - If `file.path`/`file.name` are present, assess whether the script is stored in an expected location for the user and host role, or in a user-writable / temporary directory indicated by `file.directory`.
+  - If `file.path` is present, retrieve and review the corresponding script file for additional context (embedded payloads, additional functions, or execution logic not visible in a single script block event).
+  - If `file.path` is not present, treat the activity as potentially interactive or remotely delivered and rely on `powershell.file.script_block_id` and time-based pivots to gather surrounding context.
+- Scope related PowerShell activity on the same host and user:
+  - Pivot on `host.id` and `user.id` to identify additional script blocks around the alert time that may show setup, staging, or follow-on actions.
+  - Check for repeated `Assembly.Load` usage across multiple `powershell.file.script_block_id` values, which may indicate iterative execution attempts or multiple payload stages.
+- Scope across the environment:
+  - Search for the same `file.path`/`file.name` and similar `powershell.file.script_block_text` patterns on other hosts to identify propagation or reuse.
+  - Identify whether the same `user.id` is associated with similar script blocks across multiple `host.id` values to assess potential lateral movement or shared automation.
+- Correlate with adjacent telemetry (if available in your environment):
+  - Process telemetry: Determine how PowerShell was launched and by what parent process around the alert time to understand delivery (interactive use, scheduled execution, service context, or another process).
+  - Network telemetry: Review outbound activity near the alert time for signs of payload retrieval, staging infrastructure, or command-and-control.
+  - File/registry telemetry: Look for newly created or modified scripts, DLLs, or persistence-related changes temporally aligned with the script block execution.
+  - Authentication telemetry: Review logon patterns for the same user and host around the alert time to identify unusual access patterns that could explain the execution.
+- If response actions are available:
+  - Collect host DNS cache and a snapshot of running/installed services to support scoping and to identify suspicious services or recent name resolution consistent with payload staging.
+
+
+*False positive analysis*
+
+
+- Legitimate scripts may load assemblies to support internal tooling, plugin models, packaged dependencies, or automation tasks that embed .NET functionality in PowerShell.
+- Benign activity is more likely when:
+  - `file.path`/`file.name` map to a known, owned script with a stable operational purpose.
+  - The same `user.id` consistently runs the same script on the same `host.id` as part of normal operations.
+  - `powershell.file.script_block_text` is readable and clearly loads expected assemblies without embedded blobs or multi-step content staging.
+- Suspicious activity is more likely when:
+  - The assembly is loaded from dynamically generated bytes (encoded or transformed content) and is followed by reflection-based invocation.
+  - The script originates from an unusual `file.directory` or the execution context (`user.name`/`host.name`) is inconsistent with expected administrative workflows.
+- If confirmed benign, document the owning team, expected execution pattern, and the specific script identity (`file.path`/`file.name`) to enable narrowly scoped tuning.
+
+
+*Response and remediation*
+
+
+- If the activity is confirmed or strongly suspected to be malicious:
+  - Isolate the affected host to prevent further in-memory execution and follow-on activity.
+  - Preserve evidence from the alert:
+    - Export the full reconstructed script block content using `powershell.file.script_block_id` with `powershell.sequence`/`powershell.total`.
+    - Capture `host.id`, `host.name`, `user.id`, `user.name`, `user.domain`, and any associated `file.path`/`file.name` context.
+  - Identify and contain related activity:
+    - Hunt for additional related script blocks on the same host/user and across other hosts for similar `powershell.file.script_block_text` patterns.
+    - Contain any identified infrastructure or artifacts based on indicators found in the script content (for example, domains, IPs, or downloaded file names).
+  - Remediate:
+    - Remove persistence and stop any related malicious processes discovered during triage and correlation.
+    - Review the impacted account (`user.id`) for compromise and rotate credentials as appropriate, prioritizing privileged access.
+    - Validate the host is remediated and monitored for recurrence before returning it to service.
+- If the activity is benign but requires reduction in alert volume:
+  - Record the approved use case and expected execution context (host role, user role, and script location).
+  - Apply targeted tuning anchored to stable identifiers (for example, specific `file.path` and expected accounts) rather than broadly suppressing assembly load behavior.
+  - Review PowerShell governance and monitoring to ensure in-memory loading is limited to approved workflows.
+
+
+==== 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 : (
+    "[System.Reflection.Assembly]::Load" or
+    "[Reflection.Assembly]::Load" or
+    "Assembly.Load("
+  ) and
+  powershell.file.script_block_text : (
+      "FromBase64String" or "GzipStream" or "DeflateStream" or "IO.Compression" or
+      "MemoryStream" or "DownloadData" or "WebClient" or "ReadAllBytes"
+  )
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Process Injection
+** ID: T1055
+** Reference URL: https://attack.mitre.org/techniques/T1055/
+* Sub-technique:
+** Name: Dynamic-link Library Injection
+** ID: T1055.001
+** Reference URL: https://attack.mitre.org/techniques/T1055/001/
+* Sub-technique:
+** Name: Portable Executable Injection
+** ID: T1055.002
+** Reference URL: https://attack.mitre.org/techniques/T1055/002/
+* Technique:
+** Name: Reflective Code Loading
+** ID: T1620
+** Reference URL: https://attack.mitre.org/techniques/T1620/
+* 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-16/prebuilt-rule-8-19-16-suspicious-portable-executable-encoded-in-powershell-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspicious-portable-executable-encoded-in-powershell-script.asciidoc
new file mode 100644
index 0000000000..589d44ec7a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspicious-portable-executable-encoded-in-powershell-script.asciidoc
@@ -0,0 +1,176 @@
+[[prebuilt-rule-8-19-16-suspicious-portable-executable-encoded-in-powershell-script]]
+=== Suspicious Portable Executable Encoded in Powershell Script
+
+Detects PowerShell scripts that includes a base64-encoded portable executable (PE) header, indicating an embedded binary payload. Attackers embed PEs in scripts to load payloads in memory and avoid writing executables to disk.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.powershell*
+
+*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/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
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+* Data Source: PowerShell Logs
+
+*Version*: 216
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Suspicious Portable Executable Encoded in Powershell Script*
+
+
+This alert indicates PowerShell Script Block Logging captured script content that contains a base64-encoded Portable Executable (PE) header pattern, suggesting an embedded Windows binary payload. This technique is commonly used to stage executables for in-memory loading or later execution while minimizing on-disk artifacts.
+
+
+*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*
+
+
+- Capture and reconstruct the full script content:
+  - Review `powershell.file.script_block_text` in full to identify the encoded blob boundaries and any surrounding helper logic (string concatenation, chunking, decryption, decompression, or obfuscation).
+  - If `powershell.file.script_block_id` is present, collect all related events for that ID and use `powershell.sequence` and `powershell.total` to reconstruct the complete script when content is split across multiple records.
+  - Confirm reconstruction completeness by ensuring the sequence range is consistent with `powershell.total` and that the combined content is coherent.
+  - Use `powershell.file.script_block_length` to help prioritize unusually large script blocks that are more likely to contain full payloads or staged components.
+- Determine the script origin and execution context:
+  - Use `user.name`, `user.domain`, and `user.id` to identify the initiating account and whether this activity is expected for that user (approved automation vs. unusual interactive activity).
+  - Use `host.name` and `host.id` to identify the affected asset, its owner/role, and whether PowerShell automation is typical for this host.
+  - If `file.path`, `file.directory`, or `file.name` are present, treat the alert as file-sourced script execution:
+    - Validate whether the path and name align with approved administrative tooling and distribution locations.
+    - Prioritize investigation when scripts are sourced from user-writable locations, temporary directories, or uncommon paths for your environment.
+- Identify likely payload handling behavior within the script:
+  - Look for logic that transforms the encoded content into executable bytes and how it is consumed (written to disk, loaded as an assembly, reflectively invoked, or mapped into memory).
+  - Note any secondary behaviors in the same script block that increase risk, such as staged downloads, persistence-related actions, or attempts to reduce visibility.
+  - Identify whether the script constructs multiple encoded blobs, and document which blob is ultimately used for execution.
+- Scope the activity using alert pivots:
+  - Search for additional script block events for the same `host.id` and `user.id` around `@timestamp` to identify lead-up actions and follow-on behavior.
+  - Search across hosts for the same `powershell.file.script_block_text` patterns (the encoded header and any unique strings nearby) to identify other potentially affected systems.
+  - If a script file is indicated by `file.path`/`file.name`, search for the same path/name across your environment to determine distribution and reuse.
+- Correlate with adjacent telemetry (if available):
+  - Pivot on `host.id`/`host.name` and `@timestamp` into process telemetry to identify the PowerShell session and any processes that appear shortly after the script ran, which may indicate payload execution outcomes.
+  - Pivot on `host.id`/`host.name` and `@timestamp` into network telemetry to identify outbound connections that could indicate payload retrieval or command-and-control activity shortly before or after script execution.
+  - Review authentication activity for the same `user.id` around the alert time to identify unusual logons (unexpected host, timing, or access pattern) that could explain how the execution context was obtained.
+- Analyze the embedded payload in an isolated workflow (when permitted):
+  - Decode the base64 content and validate whether it forms a legitimate PE.
+  - Derive stable indicators (hashes, unique strings, and high-level metadata) and use them to widen the scope across endpoints and historical telemetry.
+  - Preserve decoded artifacts and analysis notes according to your incident handling and evidence retention procedures.
+
+
+*False positive analysis*
+
+
+- Approved administrative or deployment automation that embeds executables in PowerShell scripts for distribution in tightly controlled environments.
+- Vendor-provided installers, updaters, or management tooling that stages binaries through PowerShell as part of legitimate maintenance activity.
+- Authorized security testing or adversary emulation that intentionally uses embedded payloads or in-memory loading techniques.
+- False positives are more likely when `file.path` points to known software distribution locations and the executing `user.id` is an approved automation account; validate against change records and expected tooling.
+
+
+*Response and remediation*
+
+
+- If the activity is unexpected or malicious:
+  - Contain the affected host(s) based on criticality to prevent further execution or lateral movement.
+  - Preserve evidence by saving the full reconstructed script content (using `powershell.file.script_block_id` plus all fragments, if split) and recording the associated `@timestamp`, `host.id`, `host.name`, and `user.id` for timeline reconstruction.
+- Assess scope and impact:
+  - Hunt for the same script patterns across other hosts and users, and expand scoping using any indicators derived from payload analysis.
+  - Review the initiating account for signs of compromise; apply credential hygiene actions per policy (reset credentials, revoke sessions, and review access).
+- Eradicate and recover:
+  - Remove or remediate the script source indicated by `file.path` (if present) and any persistence mechanisms identified during triage (for example, suspicious or newly introduced services).
+  - If a PE payload is confirmed, follow malware incident procedures to determine whether host reimaging or deeper forensic review is required.
+- Post-incident improvements:
+  - Review PowerShell governance for the affected population (script approval processes, least privilege, and monitoring of script block content) to reduce recurrence.
+  - Document validated benign patterns and trusted automation paths to streamline future triage and reduce alert fatigue.
+
+
+==== 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 : (
+    TVqQAAMAAAAEAAAA
+  ) 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/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* 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-16/prebuilt-rule-8-19-16-suspicious-windows-powershell-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspicious-windows-powershell-arguments.asciidoc
new file mode 100644
index 0000000000..48a01445b4
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-suspicious-windows-powershell-arguments.asciidoc
@@ -0,0 +1,226 @@
+[[prebuilt-rule-8-19-16-suspicious-windows-powershell-arguments]]
+=== Suspicious Windows Powershell Arguments
+
+Identifies the execution of PowerShell with suspicious argument values. This behavior is often observed during malware installation leveraging PowerShell.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.process-*
+* logs-crowdstrike.fdr*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-system.security*
+* logs-windows.forwarded*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+* endgame-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<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 for Endpoint
+* Data Source: Crowdstrike
+* Data Source: Elastic Endgame
+* Resources: Investigation Guide
+
+*Version*: 211
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Suspicious Windows Powershell Arguments*
+
+
+PowerShell is a powerful scripting language and command-line shell used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's capabilities to execute malicious scripts, download payloads, and obfuscate commands. The detection rule identifies unusual PowerShell arguments indicative of such abuse, focusing on patterns like encoded commands, suspicious downloads, and obfuscation techniques, thereby flagging potential threats for further investigation.
+
+
+*Possible investigation steps*
+
+
+- Review the process command line and arguments to identify any encoded or obfuscated content, such as Base64 strings or unusual character sequences, which may indicate malicious intent.
+- Check the parent process of the PowerShell execution, especially if it is explorer.exe or cmd.exe, to determine if the PowerShell instance was launched from a suspicious or unexpected source.
+- Investigate any network activity associated with the PowerShell process, particularly looking for connections to known malicious domains or IP addresses, or the use of suspicious commands like DownloadFile or DownloadString.
+- Examine the user account associated with the PowerShell execution to determine if it aligns with expected behavior or if it might be compromised.
+- Correlate the event with other security alerts or logs from the same host or user to identify patterns or additional indicators of compromise.
+- Assess the risk and impact of the detected activity by considering the context of the environment, such as the presence of sensitive data or critical systems that might be affected.
+
+
+*False positive analysis*
+
+
+- Legitimate administrative scripts may use encoded commands for obfuscation to protect sensitive data. Review the script's source and purpose to determine if it is authorized. If confirmed, add the script's hash or specific command pattern to an allowlist.
+- Automated software deployment tools might use PowerShell to download and execute scripts from trusted internal sources. Verify the source and destination of the download. If legitimate, exclude the specific tool or process from the detection rule.
+- System maintenance tasks often involve PowerShell scripts that manipulate files or system settings. Identify routine maintenance scripts and exclude their specific command patterns or file paths from triggering the rule.
+- Security software may use PowerShell for scanning or remediation tasks, which can mimic suspicious behavior. Confirm the software's legitimacy and add its processes to an exception list to prevent false alerts.
+- Developers might use PowerShell for testing or development purposes, which can include obfuscation techniques. Validate the developer's activities and exclude their specific development environments or scripts from the rule.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activities.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or scripts.
+- Review and clean up any unauthorized changes to system configurations or scheduled tasks that may have been altered by the malicious PowerShell activity.
+- Restore any affected files or system components from known good backups to ensure system integrity and functionality.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Implement additional monitoring and logging for PowerShell activities across the network to enhance detection of similar threats in the future.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+ process.name : "powershell.exe" and
+
+  not (
+    ?user.id == "S-1-5-18" and
+    /* Don't apply the user.id exclusion to Sysmon for compatibility */
+    not event.dataset : ("windows.sysmon_operational", "windows.sysmon")
+  ) and
+
+  not process.parent.executable : (
+        "?:\\Program Files\\*.exe",
+        "?:\\Program Files (x86)\\*.exe"
+  ) and
+
+  (
+    process.command_line : (
+          "*^*^*^*^*^*^*^*^*^*",
+          "*`*`*`*`*",
+          "*+*+*+*+*+*+*",
+          "*[char[]](*)*-join*",
+          "*Base64String*",
+          "*[*Convert]*",
+          "*.Compression.*",
+          "*-join($*",
+          "*.replace*",
+          "*MemoryStream*",
+          "*WriteAllBytes*",
+          "* -enc *",
+          "* -ec *",
+          "* /e *",
+          "* /enc *",
+          "* /ec *",
+          "*WebClient*",
+          "*DownloadFile*",
+          "*DownloadString*",
+          "* iex*",
+          "* iwr*",
+          "* aQB3AHIAIABpA*",
+          "*Reflection.Assembly*",
+          "*Assembly.GetType*",
+          "*$env:temp\\*start*",
+          "*powercat*",
+          "*nslookup -q=txt*",
+          "*$host.UI.PromptForCredential*",
+          "*Net.Sockets.TCPClient*",
+          "*curl *;Start*",
+          "powershell.exe \"<#*",
+          "*ssh -p *",
+          "*http*|iex*",
+          "*@SSL\\DavWWWRoot\\*.ps1*",
+          "*.lnk*.Seek(0x*",
+          "*[string]::join(*",
+          "*[Array]::Reverse($*",
+          "* hidden $(gc *",
+          "*=wscri& set*",
+          "*http'+'s://*",
+          "*.content|i''Ex*",
+          "*//:sptth*",
+          "*//:ptth*",
+          "*h''t''t''p*",
+          "*'tp'':''/'*",
+          "*$env:T\"E\"MP*",
+          "*;cmd /c $?",
+          "*s''t''a''r*",
+          "*$*=Get-Content*AppData*.SubString(*$*",
+          "*=cat *AppData*.substring(*);*$*",
+          "*-join'';*|powershell*",
+          "*.Content;sleep *|powershell*",
+          "*h\''t\''tp:\''*",
+          "*-e aQB3AHIAIABp*",
+          "*iwr *https*).Content*",
+          "*$env:computername*http*",
+          "*;InVoKe-ExpRESsIoN $COntent.CONTENt;*",
+          "*WebClient*example.com*",
+          "*=iwr $*;iex $*",
+          "*ServerXmlHttp*IEX*",
+          "*XmlDocument*IEX*"
+    ) or
+
+    (process.args : "-c" and process.args : "&{'*") or
+
+    (process.args : "-Outfile" and process.args : "Start*") or
+
+    (process.args : "-bxor" and process.args : "0x*") or
+
+    process.args : "$*$*;set-alias" or
+
+    process.args == "-e" or
+
+    // ATHPowerShellCommandLineParameter
+    process.args : ("-EncodedCommandParamVariation", "-UseEncodedArguments", "-CommandParamVariation") or
+
+    (
+      process.parent.name : ("explorer.exe", "cmd.exe") and
+      process.command_line : ("*-encodedCommand*", "*Invoke-webrequest*", "*WebClient*", "*Reflection.Assembly*"))
+    ) and
+    not process.command_line : (
+      "*Use-Icinga -Minimal*",
+      "*& {$j = sajb {Add-Type -AssemblyName*"
+    )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-system-information-discovery-via-dmidecode-from-parent-shell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-system-information-discovery-via-dmidecode-from-parent-shell.asciidoc
new file mode 100644
index 0000000000..609adb2ef4
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-system-information-discovery-via-dmidecode-from-parent-shell.asciidoc
@@ -0,0 +1,173 @@
+[[prebuilt-rule-8-19-16-system-information-discovery-via-dmidecode-from-parent-shell]]
+=== System Information Discovery via dmidecode from Parent Shell
+
+This rule detects the use of dmidecode to gather system information from a Linux host when executed from a parent shell process. Adversaries may use dmidecode to collect detailed hardware and system information, which can aid in further exploitation or lateral movement within a network, or be used as a fingerprint for a compromised system.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.*
+* endgame-*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://research.checkpoint.com/2024/29676/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Discovery
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* 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 System Information Discovery via dmidecode from Parent Shell*
+
+
+This rule flags dmidecode launched from a parent shell, signaling collection of hardware and firmware inventory that adversaries use to profile a host and inform exploitation or lateral movement. A typical pattern is an intruder running bash -c 'dmidecode -t system -t bios' within a post-exploitation script to harvest model, serial, BIOS vendor, and hypervisor indicators, then tailoring payload choices or host-based evasion accordingly.
+
+
+*Possible investigation steps*
+
+
+- Extract the full parent shell command payload to see exact dmidecode arguments, targeted DMI types, and any output redirection or piping to grep, gzip, curl, scp, or similar utilities indicating data collection or exfiltration.
+- Correlate execution context by tying the parent shell to the user, TTY versus non-interactive origin (cron/systemd/SSH), source IP, and presence of unexpected sudo/root elevation to judge intent and privilege.
+- Pivot on the parent PID and session to list adjacent commands within the timeline to identify broader discovery or staging chains and any script or binary loader used.
+- Search for captured output by reviewing recent file writes under /tmp, /var/tmp, /dev/shm, and home directories for DMI dumps, hardware inventory files, or compressed archives, and triage ownership and timestamps.
+- Investigate network activity from the shell and its children around the event for outbound connections, especially HTTP/S3/SSH transfers that could carry dmidecode output, and capture destination details for enrichment.
+
+
+*False positive analysis*
+
+
+- A system administrator runs a shell with -c to execute dmidecode during manual troubleshooting; corroborate with an interactive TTY, a known admin user, and absence of adjacent collection or network activity.
+- A legitimate cron or systemd maintenance/provisioning job calls a shell with -c to run dmidecode for hardware inventory; verify the scheduled unit or service, script location under /etc, and expected run cadence.
+
+
+*Response and remediation*
+
+
+- Immediately kill the shell process running '-c "dmidecode ..."', terminate its children (e.g., grep, gzip, curl, scp), and isolate the host if the command chained output to a network transfer.
+- Block observed exfil destinations by adding temporary egress rules for the IP/domain referenced in the parent shell (curl/wget/scp targets), and confiscate any DMI dumps or archives found under /tmp, /var/tmp, or /dev/shm.
+- Remove persistence by deleting scripts and jobs that call dmidecode, including entries under /etc/cron.*, systemd units in /etc/systemd/system, or shell scripts dropped in home directories and /opt, and clear residual output files.
+- Recover by validating integrity of /usr/sbin/dmidecode and shell binaries (bash/sh/zsh), restoring from backup if tampering is detected, and re-enable network only after rotating passwords and SSH keys for affected accounts.
+- Escalate to incident response if dmidecode output is compressed/encoded then sent externally (e.g., '/tmp/dmi.txt.gz' piped to curl or scp), if run via sudo by an unexpected user, or observed on multiple hosts in a short window.
+- Harden by restricting dmidecode use to approved scripts via sudoers and AppArmor/SELinux profiles, alerting on shell '-c' hardware inventory commands, auditing writes to /tmp and /var/tmp, and replacing ad-hoc inventory with signed, centrally managed tooling.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from one of the following integrations:
+- Elastic Defend
+- Auditbeat
+
+
+*Elastic Defend Integration Setup*
+
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+
+
+*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide].
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide].
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide].
+
+
+*Auditbeat Setup*
+
+Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.
+
+
+*The following steps should be executed in order to add the Auditbeat on a Linux System:*
+
+- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
+- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide].
+- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide].
+- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide].
+- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and
+process.name == "dmidecode" and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
+process.parent.args == "-c" and not (
+  process.parent.command_line in (
+    "/bin/sh -c /usr/sbin/dmidecode | /bin/grep VMware", "sh -c dmidecode -s system-manufacturer"
+  ) or
+  ?process.working_directory in (
+    "/data/oem_agent/agent_inst/sysman/emd", "/opt/rapid7/ir_agent/components/insight_agent/common", "/opt/veeam/transport",
+    "/data/app/oracle/agent/agent_inst/sysman/emd", "/home/nessus", "/opt/commvault", "/opt/nessus_agent/var/nessus/mod/com.tenable.nessus_agent/data"
+  ) or
+  process.parent.args like "printf*"
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Discovery
+** ID: TA0007
+** Reference URL: https://attack.mitre.org/tactics/TA0007/
+* Technique:
+** Name: System Information Discovery
+** ID: T1082
+** Reference URL: https://attack.mitre.org/techniques/T1082/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-unusual-remote-file-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-unusual-remote-file-directory.asciidoc
new file mode 100644
index 0000000000..fe0af89137
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-unusual-remote-file-directory.asciidoc
@@ -0,0 +1,139 @@
+[[prebuilt-rule-8-19-16-unusual-remote-file-directory]]
+=== Unusual Remote File Directory
+
+An anomaly detection job has detected a remote file transfer on an unusual directory indicating a potential lateral movement activity on the host. Many Security solutions monitor well-known directories for suspicious activities, so attackers might use less common directories to bypass monitoring.
+
+*Rule type*: machine_learning
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 15m
+
+*Searches indices from*: now-90m ({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/security/current/prebuilt-ml-jobs.html
+* https://docs.elastic.co/en/integrations/lmd
+* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration
+* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security
+
+*Tags*: 
+
+* Use Case: Lateral Movement Detection
+* Rule Type: ML
+* Rule Type: Machine Learning
+* Tactic: Lateral Movement
+* Resources: Investigation Guide
+
+*Version*: 8
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Unusual Remote File Directory*
+
+
+The 'Unusual Remote File Directory' detection leverages machine learning to identify atypical file transfers in directories not commonly monitored, which may indicate lateral movement by adversaries. Attackers exploit these less scrutinized paths to evade detection, often using remote services to transfer malicious payloads. This rule flags such anomalies, aiding in early detection of potential breaches.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific unusual directory involved in the file transfer and note any associated file names or types.
+- Check the source and destination IP addresses involved in the transfer to determine if they are known or trusted entities within the network.
+- Investigate the user account associated with the file transfer to verify if the activity aligns with their typical behavior or role within the organization.
+- Examine recent logs or events from the host to identify any other suspicious activities or anomalies that may correlate with the file transfer.
+- Cross-reference the detected activity with known threat intelligence sources to determine if the file transfer or directory is associated with any known malicious campaigns or tactics.
+- Assess the potential impact of the file transfer by evaluating the sensitivity of the data involved and the criticality of the systems affected.
+
+
+*False positive analysis*
+
+
+- Routine administrative tasks may trigger alerts if they involve file transfers to directories not typically monitored. Users can create exceptions for known administrative activities to prevent unnecessary alerts.
+- Automated backup processes might be flagged if they store files in uncommon directories. Identifying and excluding these backup operations can reduce false positives.
+- Software updates or patches that deploy files to less common directories could be mistaken for suspicious activity. Users should whitelist these update processes to avoid false alerts.
+- Development or testing environments often involve file transfers to non-standard directories. Users can configure exceptions for these environments to minimize false positives.
+- Legitimate remote services used for file transfers, such as cloud storage synchronization, may be flagged. Users should identify and exclude these trusted services from monitoring.
+
+
+*Response and remediation*
+
+
+- Isolate the affected host immediately to prevent further lateral movement and contain the potential threat. Disconnect it from the network to stop any ongoing malicious activity.
+- Conduct a thorough analysis of the unusual directory and any files transferred to identify malicious payloads. Use endpoint detection and response (EDR) tools to scan for known malware signatures and behaviors.
+- Remove any identified malicious files and artifacts from the affected directory and host. Ensure that all traces of the threat are eradicated to prevent re-infection.
+- Reset credentials and review access permissions for the affected host and any associated accounts to mitigate the risk of unauthorized access. Ensure that least privilege principles are enforced.
+- Monitor network traffic and logs for any signs of further lateral movement or exploitation attempts. Pay special attention to remote service connections and unusual directory access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional hosts or systems are compromised.
+- Update detection mechanisms and rules to enhance monitoring of less common directories and improve the detection of similar threats in the future.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
+
+
+*Lateral Movement Detection Setup*
+
+The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Lateral Movement Detection.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+- File events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] integration.
+- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation].
+
+
+*The following steps should be executed to install assets associated with the Lateral Movement Detection integration:*
+
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-unusual-remote-file-extension.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-unusual-remote-file-extension.asciidoc
new file mode 100644
index 0000000000..e7b9af14af
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-unusual-remote-file-extension.asciidoc
@@ -0,0 +1,139 @@
+[[prebuilt-rule-8-19-16-unusual-remote-file-extension]]
+=== Unusual Remote File Extension
+
+An anomaly detection job has detected a remote file transfer with a rare extension, which could indicate potential lateral movement activity on the host.
+
+*Rule type*: machine_learning
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 15m
+
+*Searches indices from*: now-90m ({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/security/current/prebuilt-ml-jobs.html
+* https://docs.elastic.co/en/integrations/lmd
+* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration
+* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security
+
+*Tags*: 
+
+* Use Case: Lateral Movement Detection
+* Rule Type: ML
+* Rule Type: Machine Learning
+* Tactic: Lateral Movement
+* Resources: Investigation Guide
+
+*Version*: 8
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Unusual Remote File Extension*
+
+
+The detection of unusual remote file extensions leverages machine learning to identify anomalies in file transfers, which may suggest lateral movement by adversaries. Attackers often exploit remote services to transfer files with uncommon extensions, bypassing standard security measures. This rule flags such anomalies, aiding in early detection of potential threats by correlating rare file extensions with known lateral movement tactics.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific file extension and the source and destination of the file transfer.
+- Check the historical data for the identified file extension to determine if it has been used previously in legitimate activities or if it is indeed rare.
+- Investigate the source host to identify any recent changes or suspicious activities, such as new user accounts or unusual login patterns.
+- Examine the destination host for any signs of compromise or unauthorized access, focusing on recent file modifications or unexpected processes.
+- Correlate the file transfer event with other security alerts or logs to identify potential patterns of lateral movement or exploitation of remote services.
+- Consult threat intelligence sources to determine if the rare file extension is associated with known malware or adversary tactics.
+
+
+*False positive analysis*
+
+
+- Common internal file transfers with rare extensions may trigger false positives. Review and whitelist known benign file extensions used by internal applications or processes.
+- Automated backup or synchronization tools might use uncommon file extensions. Identify these tools and create exceptions for their typical file extensions to prevent unnecessary alerts.
+- Development environments often generate files with unique extensions. Collaborate with development teams to understand these patterns and exclude them from detection if they are verified as non-threatening.
+- Security tools or scripts that transfer diagnostic or log files with unusual extensions can be mistaken for lateral movement. Document these tools and adjust the rule to ignore their specific file extensions.
+- Regularly review and update the list of excluded extensions to ensure it reflects current operational practices and does not inadvertently allow malicious activity.
+
+
+*Response and remediation*
+
+
+- Isolate the affected host immediately to prevent further lateral movement and contain the potential threat.
+- Review and terminate any suspicious remote sessions or connections identified on the host to cut off unauthorized access.
+- Conduct a thorough scan of the affected system for malware or unauthorized software that may have been transferred using the unusual file extension.
+- Restore the affected system from a known good backup if any malicious activity or compromise is confirmed.
+- Update and patch all software and systems on the affected host to close any vulnerabilities that may have been exploited.
+- Monitor network traffic for any further unusual file transfers or connections, focusing on rare file extensions and remote service exploitation patterns.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
+
+
+*Lateral Movement Detection Setup*
+
+The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Lateral Movement Detection.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+- File events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] integration.
+- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation].
+
+
+*The following steps should be executed to install assets associated with the Lateral Movement Detection integration:*
+
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-unusual-remote-file-size.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-unusual-remote-file-size.asciidoc
new file mode 100644
index 0000000000..cb47f93085
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-unusual-remote-file-size.asciidoc
@@ -0,0 +1,138 @@
+[[prebuilt-rule-8-19-16-unusual-remote-file-size]]
+=== Unusual Remote File Size
+
+A machine learning job has detected an unusually high file size shared by a remote host indicating potential lateral movement activity. One of the primary goals of attackers after gaining access to a network is to locate and exfiltrate valuable information. Instead of multiple small transfers that can raise alarms, attackers might choose to bundle data into a single large file transfer.
+
+*Rule type*: machine_learning
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 15m
+
+*Searches indices from*: now-90m ({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/security/current/prebuilt-ml-jobs.html
+* https://docs.elastic.co/en/integrations/lmd
+* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration
+* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security
+
+*Tags*: 
+
+* Use Case: Lateral Movement Detection
+* Rule Type: ML
+* Rule Type: Machine Learning
+* Tactic: Lateral Movement
+* Resources: Investigation Guide
+
+*Version*: 8
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Unusual Remote File Size*
+
+Machine learning models in security environments analyze file transfer patterns to identify anomalies, such as unusually large files shared remotely. Adversaries exploit this by aggregating data into large files to avoid detection during lateral movement. The 'Unusual Remote File Size' rule leverages ML to flag these anomalies, aiding in early detection of potential data exfiltration activities.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to identify the specific remote host and file size involved in the anomaly.
+- Check the historical file transfer patterns of the identified remote host to determine if this large file size is truly unusual.
+- Investigate the contents and purpose of the large file, if accessible, to assess whether it contains sensitive or valuable information.
+- Analyze network logs to trace the origin and destination of the file transfer, looking for any unauthorized or suspicious connections.
+- Correlate the event with other security alerts or logs to identify any concurrent suspicious activities that might indicate lateral movement or data exfiltration.
+- Verify the user account associated with the file transfer to ensure it has not been compromised or misused.
+
+
+*False positive analysis*
+
+
+- Large file transfers related to legitimate business operations, such as backups or data migrations, can trigger false positives. Users should identify and whitelist these routine activities to prevent unnecessary alerts.
+- Software updates or patches distributed across the network may also appear as unusually large file transfers. Establishing a baseline for expected file sizes during these updates can help in distinguishing them from potential threats.
+- Remote file sharing services used for collaboration might generate alerts if large files are shared frequently. Monitoring and excluding these services from the rule can reduce false positives.
+- Automated data processing tasks that involve transferring large datasets between systems should be documented and excluded from the rule to avoid false alarms.
+- Regularly review and update the list of known safe hosts and services that are permitted to transfer large files, ensuring that only legitimate activities are excluded from detection.
+
+
+*Response and remediation*
+
+
+- Isolate the affected host immediately to prevent further lateral movement and potential data exfiltration. Disconnect it from the network to contain the threat.
+- Conduct a thorough analysis of the large file transfer to determine its contents and origin. Verify if sensitive data was included and assess the potential impact.
+- Review and terminate any unauthorized remote sessions or connections identified during the investigation to prevent further exploitation.
+- Reset credentials and review access permissions for the affected host and any associated accounts to mitigate the risk of compromised credentials being used for further attacks.
+- Implement network segmentation to limit the ability of attackers to move laterally within the network, reducing the risk of similar incidents in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation actions are taken.
+- Enhance monitoring and logging for unusual file transfer activities and remote access attempts to improve early detection of similar threats in the future.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
+
+
+*Lateral Movement Detection Setup*
+
+The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Lateral Movement Detection.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+- File events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] integration.
+- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation].
+
+
+*The following steps should be executed to install assets associated with the Lateral Movement Detection integration:*
+
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-unusual-time-or-day-for-an-rdp-session.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-unusual-time-or-day-for-an-rdp-session.asciidoc
new file mode 100644
index 0000000000..9f2342f397
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rule-8-19-16-unusual-time-or-day-for-an-rdp-session.asciidoc
@@ -0,0 +1,139 @@
+[[prebuilt-rule-8-19-16-unusual-time-or-day-for-an-rdp-session]]
+=== Unusual Time or Day for an RDP Session
+
+A machine learning job has detected an RDP session started at an usual time or weekday. An RDP session at an unusual time could be followed by other suspicious activities, so catching this is a good first step in detecting a larger attack.
+
+*Rule type*: machine_learning
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 15m
+
+*Searches indices from*: now-12h ({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/security/current/prebuilt-ml-jobs.html
+* https://docs.elastic.co/en/integrations/lmd
+* https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration
+* https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security
+
+*Tags*: 
+
+* Use Case: Lateral Movement Detection
+* Rule Type: ML
+* Rule Type: Machine Learning
+* Tactic: Lateral Movement
+* Resources: Investigation Guide
+
+*Version*: 8
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Unusual Time or Day for an RDP Session*
+
+
+Remote Desktop Protocol (RDP) enables remote access to systems, crucial for IT management but also a target for adversaries seeking unauthorized access. Attackers exploit RDP by initiating sessions at odd hours to avoid detection. The detection rule leverages machine learning to identify atypical RDP session timings, flagging potential lateral movement attempts for further investigation.
+
+
+*Possible investigation steps*
+
+
+- Review the timestamp of the RDP session to determine the specific unusual time or day it was initiated, and correlate it with known business hours or scheduled maintenance windows.
+- Identify the source and destination IP addresses involved in the RDP session to determine if they are internal or external, and check for any known associations with previous security incidents.
+- Examine the user account used to initiate the RDP session, verifying if it is a legitimate account and if the login aligns with the user's typical behavior or role within the organization.
+- Check for any additional suspicious activities or alerts involving the same user account or IP addresses around the time of the unusual RDP session, such as failed login attempts or access to sensitive files.
+- Investigate any recent changes or anomalies in the network or system configurations that could have facilitated the unusual RDP session, such as newly opened ports or modified firewall rules.
+- Consult logs from other security tools or systems, such as SIEM or endpoint detection and response (EDR) solutions, to gather more context on the RDP session and any related activities.
+
+
+*False positive analysis*
+
+
+- Regular maintenance activities by IT staff during off-hours can trigger false positives. Identify and document these activities to create exceptions in the detection rule.
+- Scheduled automated tasks or scripts that initiate RDP sessions at unusual times may be misclassified. Review and whitelist these tasks to prevent unnecessary alerts.
+- Time zone differences for remote employees accessing systems outside of standard business hours can lead to false positives. Adjust detection parameters to account for these time zone variations.
+- Third-party vendors or contractors who require access at non-standard times should be documented and their access patterns reviewed to establish exceptions.
+- Emergency access situations where IT staff need to respond to critical incidents outside normal hours should be logged and considered when analyzing alerts.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate the suspicious RDP session to halt any ongoing unauthorized activities.
+- Conduct a thorough review of the affected system's logs and processes to identify any malicious activities or changes made during the session.
+- Reset credentials for any accounts accessed during the unusual RDP session to prevent further unauthorized use.
+- Apply security patches and updates to the affected system to address 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 compromised.
+- Implement enhanced monitoring on the affected system and related network segments to detect any further suspicious activities or attempts at unauthorized access.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
+
+
+*Lateral Movement Detection Setup*
+
+The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Lateral Movement Detection.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+- Windows RDP process events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] integration.
+- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation].
+
+
+*The following steps should be executed to install assets associated with the Lateral Movement Detection integration:*
+
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+
+
+*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/
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rules-8-19-16-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rules-8-19-16-appendix.asciidoc
new file mode 100644
index 0000000000..8b33a6d142
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rules-8-19-16-appendix.asciidoc
@@ -0,0 +1,117 @@
+["appendix",role="exclude",id="prebuilt-rule-8-19-16-prebuilt-rules-8-19-16-appendix"]
+= Downloadable rule update v8.19.16
+
+This section lists all updates associated with version 8.19.16 of the Fleet integration *Prebuilt Security Detection Rules*.
+
+
+include::prebuilt-rule-8-19-16-elastic-defend-alert-followed-by-telemetry-loss.asciidoc[]
+include::prebuilt-rule-8-19-16-fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc[]
+include::prebuilt-rule-8-19-16-correlated-alerts-on-similar-user-identities.asciidoc[]
+include::prebuilt-rule-8-19-16-aws-guardduty-member-account-manipulation.asciidoc[]
+include::prebuilt-rule-8-19-16-aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc[]
+include::prebuilt-rule-8-19-16-aws-iam-oidc-provider-created-by-rare-user.asciidoc[]
+include::prebuilt-rule-8-19-16-aws-iam-saml-provider-created.asciidoc[]
+include::prebuilt-rule-8-19-16-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc[]
+include::prebuilt-rule-8-19-16-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-okta-brute-force-multi-source.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-okta-password-spray-multi-source.asciidoc[]
+include::prebuilt-rule-8-19-16-okta-successful-login-after-credential-attack.asciidoc[]
+include::prebuilt-rule-8-19-16-bpf-program-tampering-via-bpftool.asciidoc[]
+include::prebuilt-rule-8-19-16-kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc[]
+include::prebuilt-rule-8-19-16-bpf-program-or-map-load-via-bpftool.asciidoc[]
+include::prebuilt-rule-8-19-16-kernel-module-load-from-unusual-location.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-powershell-obfuscated-script-via-high-entropy.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-notepad-markdown-rce-exploitation.asciidoc[]
+include::prebuilt-rule-8-19-16-connection-to-common-large-language-model-endpoints.asciidoc[]
+include::prebuilt-rule-8-19-16-fortigate-socks-traffic-from-an-unusual-process.asciidoc[]
+include::prebuilt-rule-8-19-16-elastic-agent-service-terminated.asciidoc[]
+include::prebuilt-rule-8-19-16-detection-alert-on-a-process-exhibiting-cpu-spike.asciidoc[]
+include::prebuilt-rule-8-19-16-multiple-alerts-on-a-host-exhibiting-cpu-spike.asciidoc[]
+include::prebuilt-rule-8-19-16-lateral-movement-alerts-from-a-newly-observed-source-address.asciidoc[]
+include::prebuilt-rule-8-19-16-lateral-movement-alerts-from-a-newly-observed-user.asciidoc[]
+include::prebuilt-rule-8-19-16-suspected-lateral-movement-from-compromised-host.asciidoc[]
+include::prebuilt-rule-8-19-16-elastic-defend-and-network-security-alerts-correlation.asciidoc[]
+include::prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-destination-address.asciidoc[]
+include::prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-source-address.asciidoc[]
+include::prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-user-name.asciidoc[]
+include::prebuilt-rule-8-19-16-multiple-alerts-involving-a-user.asciidoc[]
+include::prebuilt-rule-8-19-16-alerts-in-different-att-ck-tactics-by-host.asciidoc[]
+include::prebuilt-rule-8-19-16-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc[]
+include::prebuilt-rule-8-19-16-multiple-external-edr-alerts-by-host.asciidoc[]
+include::prebuilt-rule-8-19-16-multiple-machine-learning-alerts-by-influencer-field.asciidoc[]
+include::prebuilt-rule-8-19-16-newly-observed-high-severity-detection-alert.asciidoc[]
+include::prebuilt-rule-8-19-16-newly-observed-fortigate-alert.asciidoc[]
+include::prebuilt-rule-8-19-16-newly-observed-high-severity-suricata-alert.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc[]
+include::prebuilt-rule-8-19-16-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc[]
+include::prebuilt-rule-8-19-16-entra-id-federated-identity-credential-issuer-modified.asciidoc[]
+include::prebuilt-rule-8-19-16-entra-id-unusual-cloud-device-registration.asciidoc[]
+include::prebuilt-rule-8-19-16-high-mean-of-process-arguments-in-an-rdp-session.asciidoc[]
+include::prebuilt-rule-8-19-16-high-mean-of-rdp-session-duration.asciidoc[]
+include::prebuilt-rule-8-19-16-unusual-remote-file-size.asciidoc[]
+include::prebuilt-rule-8-19-16-high-variance-in-rdp-session-duration.asciidoc[]
+include::prebuilt-rule-8-19-16-unusual-remote-file-directory.asciidoc[]
+include::prebuilt-rule-8-19-16-unusual-remote-file-extension.asciidoc[]
+include::prebuilt-rule-8-19-16-spike-in-number-of-connections-made-from-a-source-ip.asciidoc[]
+include::prebuilt-rule-8-19-16-spike-in-number-of-connections-made-to-a-destination-ip.asciidoc[]
+include::prebuilt-rule-8-19-16-spike-in-number-of-processes-in-an-rdp-session.asciidoc[]
+include::prebuilt-rule-8-19-16-spike-in-remote-file-transfers.asciidoc[]
+include::prebuilt-rule-8-19-16-unusual-time-or-day-for-an-rdp-session.asciidoc[]
+include::prebuilt-rule-8-19-16-deprecated-m365-exchange-dlp-policy-deleted.asciidoc[]
+include::prebuilt-rule-8-19-16-deprecated-m365-teams-external-access-enabled.asciidoc[]
+include::prebuilt-rule-8-19-16-deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc[]
+include::prebuilt-rule-8-19-16-deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc[]
+include::prebuilt-rule-8-19-16-m365-identity-unusual-sso-authentication-errors-for-user.asciidoc[]
+include::prebuilt-rule-8-19-16-deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish.asciidoc[]
+include::prebuilt-rule-8-19-16-deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc[]
+include::prebuilt-rule-8-19-16-deprecated-m365-teams-guest-access-enabled.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-okta-brute-force-device-token-rotation.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-okta-credential-stuffing-single-source.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-okta-password-spray-single-source.asciidoc[]
+include::prebuilt-rule-8-19-16-okta-user-assigned-administrator-role.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-linux-tunneling-and-or-port-forwarding.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc[]
+include::prebuilt-rule-8-19-16-system-information-discovery-via-dmidecode-from-parent-shell.asciidoc[]
+include::prebuilt-rule-8-19-16-kernel-module-load-via-built-in-utility.asciidoc[]
+include::prebuilt-rule-8-19-16-accepted-default-telnet-port-connection.asciidoc[]
+include::prebuilt-rule-8-19-16-clearing-windows-console-history.asciidoc[]
+include::prebuilt-rule-8-19-16-powershell-script-block-logging-disabled.asciidoc[]
+include::prebuilt-rule-8-19-16-deprecated-encoded-executable-stored-in-the-registry.asciidoc[]
+include::prebuilt-rule-8-19-16-disabling-lsa-protection-via-registry-modification.asciidoc[]
+include::prebuilt-rule-8-19-16-program-files-directory-masquerading.asciidoc[]
+include::prebuilt-rule-8-19-16-suspicious-net-reflection-via-powershell.asciidoc[]
+include::prebuilt-rule-8-19-16-powershell-suspicious-payload-encoded-and-compressed.asciidoc[]
+include::prebuilt-rule-8-19-16-powershell-script-with-windows-defender-tampering-capabilities.asciidoc[]
+include::prebuilt-rule-8-19-16-powershell-script-with-encryption-decryption-capabilities.asciidoc[]
+include::prebuilt-rule-8-19-16-deprecated-potential-powershell-obfuscated-script.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc[]
+include::prebuilt-rule-8-19-16-dynamic-iex-reconstruction-via-method-string-access.asciidoc[]
+include::prebuilt-rule-8-19-16-powershell-obfuscation-via-negative-index-string-reversal.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-reverse-keywords.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-string-concatenation.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-string-reordering.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-special-character-overuse.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-process-injection-via-powershell.asciidoc[]
+include::prebuilt-rule-8-19-16-suspicious-execution-from-a-mounted-device.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-timestomp-in-executable-files.asciidoc[]
+include::prebuilt-rule-8-19-16-execution-via-windows-subsystem-for-linux.asciidoc[]
+include::prebuilt-rule-8-19-16-powershell-share-enumeration-script.asciidoc[]
+include::prebuilt-rule-8-19-16-powershell-suspicious-discovery-related-windows-api-functions.asciidoc[]
+include::prebuilt-rule-8-19-16-suspicious-command-prompt-network-connection.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-powershell-hacktool-script-by-author.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-powershell-hacktool-script-by-function-names.asciidoc[]
+include::prebuilt-rule-8-19-16-potential-malicious-powershell-based-on-alert-correlation.asciidoc[]
+include::prebuilt-rule-8-19-16-suspicious-portable-executable-encoded-in-powershell-script.asciidoc[]
+include::prebuilt-rule-8-19-16-powershell-psreflect-script.asciidoc[]
+include::prebuilt-rule-8-19-16-command-and-scripting-interpreter-via-windows-scripts.asciidoc[]
+include::prebuilt-rule-8-19-16-suspicious-windows-powershell-arguments.asciidoc[]
+include::prebuilt-rule-8-19-16-deprecated-adobe-hijack-persistence.asciidoc[]
+include::prebuilt-rule-8-19-16-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc[]
+include::prebuilt-rule-8-19-16-dmsa-account-creation-by-an-unusual-user.asciidoc[]
+include::prebuilt-rule-8-19-16-powershell-script-with-token-impersonation-capabilities.asciidoc[]
+include::prebuilt-rule-8-19-16-deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc[]
diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rules-8-19-16-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rules-8-19-16-summary.asciidoc
new file mode 100644
index 0000000000..4bd961a991
--- /dev/null
+++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rules-8-19-16-summary.asciidoc
@@ -0,0 +1,234 @@
+[[prebuilt-rule-8-19-16-prebuilt-rules-8-19-16-summary]]
+[role="xpack"]
+== Update v8.19.16
+
+This section lists all updates associated with version 8.19.16 of the Fleet integration *Prebuilt Security Detection Rules*.
+
+
+[width="100%",options="header"]
+|==============================================
+|Rule |Description |Status |Version
+
+|<<prebuilt-rule-8-19-16-elastic-defend-alert-followed-by-telemetry-loss, Elastic Defend Alert Followed by Telemetry Loss>> | Detects when an Elastic Defend endpoint alert is generated on a host and is not followed by any subsequent endpoint telemetry (process, network, registry, library, or DNS events) within a short time window. This behavior may indicate endpoint security evasion, agent tampering, sensor disablement, service termination, system crash, or malicious interference with telemetry collection following detection. | new | 1 
+
+|<<prebuilt-rule-8-19-16-fortigate-ssl-vpn-login-followed-by-siem-alert-by-user, FortiGate SSL VPN Login Followed by SIEM Alert by User>> | Detects when a FortiGate SSL VPN login event is followed by any SIEM detection alert for the same user name within a short time window. This correlation can indicate abuse of VPN access for malicious activity, credential compromise used from a VPN session, or initial access via VPN followed by post-compromise behavior. | new | 1 
+
+|<<prebuilt-rule-8-19-16-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. | new | 2 
+
+|<<prebuilt-rule-8-19-16-aws-guardduty-member-account-manipulation, AWS GuardDuty Member Account Manipulation>> | Detects attempts to disassociate or manipulate Amazon GuardDuty member accounts within an AWS organization. In multi-account GuardDuty deployments, a delegated administrator account aggregates findings from member accounts. Adversaries may attempt to disassociate member accounts, delete member relationships, stop monitoring members, or delete pending invitations to break this centralized visibility. These actions can be precursors to or alternatives for deleting GuardDuty detectors entirely, allowing attackers to operate undetected in member accounts while the administrator account loses visibility. This rule identifies successful API calls that manipulate GuardDuty member relationships, which are rare in normal operations and warrant immediate investigation. | new | 1 
+
+|<<prebuilt-rule-8-19-16-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. | new | 1 
+
+|<<prebuilt-rule-8-19-16-aws-iam-oidc-provider-created-by-rare-user, AWS IAM OIDC Provider Created by Rare User>> | Detects when an uncommon user or role creates an OpenID Connect (OIDC) Identity Provider in AWS IAM. OIDC providers enable web identity federation, allowing users authenticated by external identity providers (such as Google, GitHub, or custom OIDC-compliant providers) to assume IAM roles and access AWS resources. Adversaries who have gained administrative access may create rogue OIDC providers to establish persistent, federated access that survives credential rotation. This technique allows attackers to assume roles using tokens from an IdP they control. While OIDC provider creation is benign in some environments, it should still be validated against authorized infrastructure changes. | new | 1 
+
+|<<prebuilt-rule-8-19-16-aws-iam-saml-provider-created, AWS IAM SAML Provider Created>> | Detects the creation of a new SAML Identity Provider (IdP) in AWS IAM. SAML providers enable federated authentication between AWS and external identity providers, allowing users to access AWS resources using credentials from the external IdP. Adversaries who have gained administrative access may create rogue SAML providers to establish persistent, federated access to AWS accounts that survives credential rotation. This technique allows attackers to assume roles and access resources by forging SAML assertions from an IdP they control. Creating a SAML provider is a rare administrative action that should be closely monitored and validated against authorized infrastructure changes. | new | 1 
+
+|<<prebuilt-rule-8-19-16-aws-sensitive-iam-operations-performed-via-cloudshell, AWS Sensitive IAM Operations Performed via CloudShell>> | Identifies sensitive AWS IAM operations performed via AWS CloudShell based on the user agent string. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. While convenient for administrators, CloudShell access from compromised console sessions can enable attackers to perform privileged operations without installing tools or using programmatic credentials. This rule detects high-risk actions such as creating IAM users, access keys, roles, or attaching policies when initiated from CloudShell, which may indicate post-compromise credential harvesting or privilege escalation activity. | new | 1 
+
+|<<prebuilt-rule-8-19-16-entra-id-service-principal-federated-credential-authentication-by-unusual-client, Entra ID Service Principal Federated Credential Authentication by Unusual Client>> | Identifies when a service principal authenticates using a federated identity credential for the first time in the historical window. This indicates that Entra ID validated a JWT token potentially against an external OIDC identity provider and issued an access token. While legitimate for CI/CD workflows (GitHub Actions, Azure DevOps), adversaries may abuse this by configuring rogue identity providers (BYOIDP) to authenticate as compromised applications. First-time federated credential usage for a service principal warrants investigation to determine if the external identity provider is legitimate. | new | 1 
+
+|<<prebuilt-rule-8-19-16-potential-okta-brute-force-multi-source, Potential Okta Brute Force (Multi-Source)>> | Detects potential brute force attacks against a single Okta user account from multiple source IPs, indicating attackers rotating through proxy infrastructure to evade IP-based detection. | new | 2 
+
+|<<prebuilt-rule-8-19-16-potential-okta-password-spray-multi-source, Potential Okta Password Spray (Multi-Source)>> | Detects potential password spray attacks where multiple source IPs target multiple Okta user accounts within a time window, indicating coordinated attacks using IP rotation to evade single-source detection. | new | 2 
+
+|<<prebuilt-rule-8-19-16-okta-successful-login-after-credential-attack, Okta Successful Login After Credential Attack>> | Correlates Okta credential attack alerts with subsequent successful authentication for the same user account, identifying potential compromise following brute force, password spray, or credential stuffing attempts. | new | 2 
+
+|<<prebuilt-rule-8-19-16-bpf-program-tampering-via-bpftool, BPF Program Tampering via bpftool>> | Detects execution of bpftool commands used to detach eBPF programs or links, or to delete or modify eBPF maps. These actions can disable, alter, or interfere with kernel-level instrumentation and enforcement mechanisms implemented through eBPF. In environments relying on eBPF-based networking, observability, or security controls, unexpected use of these operations may indicate defense evasion or runtime tampering. | new | 1 
+
+|<<prebuilt-rule-8-19-16-kernel-instrumentation-discovery-via-kprobes-and-tracefs, Kernel Instrumentation Discovery via kprobes and tracefs>> | Detects common utilities accessing kprobes and tracing-related paths in debugfs/tracefs, which may indicate discovery of kernel instrumentation hooks. Adversaries can enumerate these locations to understand or prepare for eBPF, kprobe, or tracepoint-based activity. This behavior can also be benign during troubleshooting, performance analysis, or observability tooling validation. | new | 1 
+
+|<<prebuilt-rule-8-19-16-bpf-program-or-map-load-via-bpftool, BPF Program or Map Load via bpftool>> | Detects execution of bpftool commands used to load, attach, run, or pin eBPF programs, as well as create or update eBPF maps and links. These operations interact directly with the Linux eBPF subsystem and can modify kernel-level behavior. While commonly used by legitimate networking or observability tooling, unexpected or interactive usage may indicate eBPF-based rootkit activity, policy tampering, or unauthorized kernel instrumentation. | new | 1 
+
+|<<prebuilt-rule-8-19-16-kernel-module-load-from-unusual-location, Kernel Module Load from Unusual Location>> | This rule detects the loading of a kernel module from an unusual location. Threat actors may use this technique to maintain persistence on a system by loading a kernel module into the kernel namespace. This behavior is strongly related to the presence of a rootkit on the system. | new | 1 
+
+|<<prebuilt-rule-8-19-16-potential-powershell-obfuscated-script-via-high-entropy, Potential PowerShell Obfuscated Script via High Entropy>> | Identifies PowerShell script blocks with high entropy and non-uniform character distributions. Attackers may obfuscate PowerShell scripts using encoding, encryption, or compression techniques to evade signature-based detections and hinder manual analysis by security analysts. | new | 1 
+
+|<<prebuilt-rule-8-19-16-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. | new | 1 
+
+|<<prebuilt-rule-8-19-16-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. | update | 3 
+
+|<<prebuilt-rule-8-19-16-fortigate-socks-traffic-from-an-unusual-process, FortiGate SOCKS Traffic from an Unusual Process>> | This detection correlates FortiGate's application control SOCKS events with Elastic Defend network event to identify the source process performing SOCKS traffic. Adversaries may use a connection proxy to direct network traffic between systems or act as an intermediary for network communications to a command and control server to avoid direct connections to their infrastructure. | update | 2 
+
+|<<prebuilt-rule-8-19-16-elastic-agent-service-terminated, Elastic Agent Service Terminated>> | Identifies the Elastic endpoint agent has stopped and is no longer running on the host. Adversaries may attempt to disable security monitoring tools in an attempt to evade detection or prevention capabilities during an intrusion. This may also indicate an issue with the agent itself and should be addressed to ensure defensive measures are back in a stable state. | update | 112 
+
+|<<prebuilt-rule-8-19-16-detection-alert-on-a-process-exhibiting-cpu-spike, Detection Alert on a Process Exhibiting CPU Spike>> | This rule correlates security alerts with processes exhibiting unusually high CPU utilization on the same host and process ID within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise. | update | 3 
+
+|<<prebuilt-rule-8-19-16-multiple-alerts-on-a-host-exhibiting-cpu-spike, Multiple Alerts on a Host Exhibiting CPU Spike>> | This rule correlates multiple security alerts from a host exhibiting unusually high CPU utilization within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise. | update | 3 
+
+|<<prebuilt-rule-8-19-16-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. | update | 3 
+
+|<<prebuilt-rule-8-19-16-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. | update | 3 
+
+|<<prebuilt-rule-8-19-16-suspected-lateral-movement-from-compromised-host, Suspected Lateral Movement from Compromised Host>> | Detects potential lateral movement or post-compromise activity by correlating alerts where the host.ip of one alert matches the source.ip of a subsequent alert. This behavior may indicate a compromised host being used to authenticate to another system or resource, including cloud services. | update | 4 
+
+|<<prebuilt-rule-8-19-16-elastic-defend-and-network-security-alerts-correlation, Elastic Defend and Network Security Alerts Correlation>> | This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto Networks (PANW) and Fortinet Fortigate by host.ip and source.ip. This may indicate that this host is compromised and triggering multi-datasource alerts. | update | 6 
+
+|<<prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-destination-address, Alerts From Multiple Integrations by Destination Address>> | This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same destination.ip are triggered. Analysts can use this to prioritize triage and response, as these IP address is more likely to be related to a compromise. | update | 3 
+
+|<<prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-source-address, Alerts From Multiple Integrations by Source Address>> | This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same source.ip are triggered. Analysts can use this to prioritize triage and response, as these IP addresses are more likely to be related to a compromise. | update | 3 
+
+|<<prebuilt-rule-8-19-16-alerts-from-multiple-integrations-by-user-name, Alerts From Multiple Integrations by User Name>> | This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same user.name are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. | update | 3 
+
+|<<prebuilt-rule-8-19-16-multiple-alerts-involving-a-user, Multiple Alerts Involving a User>> | This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. | update | 7 
+
+|<<prebuilt-rule-8-19-16-alerts-in-different-att-ck-tactics-by-host, Alerts in Different ATT&CK Tactics by Host>> | This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered and where the accumulated risk score is higher than a defined threshold. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. | update | 3 
+
+|<<prebuilt-rule-8-19-16-multiple-alerts-in-same-att-ck-tactic-by-host, Multiple Alerts in Same ATT&CK Tactic by Host>> | This rule correlates multiple security alerts associated with the same ATT&CK tactic on a single host within a defined time window. By requiring alerts from multiple distinct detection rules, this detection helps identify hosts exhibiting concentrated malicious behavior, which may indicate an active intrusion or post-compromise activity. The rule is intended to assist analysts in prioritizing triage toward hosts with higher likelihood of compromise rather than signaling a single discrete event. | update | 3 
+
+|<<prebuilt-rule-8-19-16-multiple-external-edr-alerts-by-host, Multiple External EDR Alerts by Host>> | This rule uses alert data to determine when multiple external EDR alerts involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. | update | 3 
+
+|<<prebuilt-rule-8-19-16-multiple-machine-learning-alerts-by-influencer-field, Multiple Machine Learning Alerts by Influencer Field>> | This rule uses alerts data to determine when multiple unique machine learning jobs involving the same influencer field are triggered. Analysts can use this to prioritize triage and response machine learning alerts. | update | 3 
+
+|<<prebuilt-rule-8-19-16-newly-observed-high-severity-detection-alert, Newly Observed High Severity Detection Alert>> | This rule detects Elastic SIEM high severity detection alerts that are observed for the first time in the previous 5 days of alert history. It highlights low-volume, newly observed alerts tied to a specific detection rule, analysts can use this to prioritize triage and response. | update | 4 
+
+|<<prebuilt-rule-8-19-16-newly-observed-fortigate-alert, Newly Observed FortiGate Alert>> | This rule detects FortiGate alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. | update | 3 
+
+|<<prebuilt-rule-8-19-16-newly-observed-high-severity-suricata-alert, Newly Observed High Severity Suricata Alert>> | This rule detects Suricata high severity alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. | update | 3 
+
+|<<prebuilt-rule-8-19-16-potential-aws-s3-bucket-ransomware-note-uploaded, Potential AWS S3 Bucket Ransomware Note Uploaded>> | Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the PutObject S3 API call with an object name commonly associated with ransomware notes. The keywords detected here rarely overlap with common file names and have been attributed to ransomware notes with high-confidence. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims. | update | 10 
+
+|<<prebuilt-rule-8-19-16-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client, Entra ID Sharepoint or OneDrive Accessed by Unusual Client>> | Identifies when an application accesses SharePoint Online or OneDrive for Business for the first time in the tenant within a specified timeframe. This detects successful OAuth phishing campaigns, illicit consent grants, or compromised third-party applications gaining initial access to file storage. Adversaries often use malicious OAuth applications or phishing techniques to gain consent from users, allowing persistent access to organizational data repositories without traditional credential theft. | update | 4 
+
+|<<prebuilt-rule-8-19-16-entra-id-federated-identity-credential-issuer-modified, Entra ID Federated Identity Credential Issuer Modified>> | Detects when the issuer URL of a federated identity credential is changed on an Entra ID application. Adversaries may modify the issuer to point to an attacker-controlled identity provider, enabling them to authenticate as the application's service principal and gain persistent access to Azure resources. This technique allows bypassing traditional authentication controls by federating trust with a malicious external identity provider. | update | 8 
+
+|<<prebuilt-rule-8-19-16-entra-id-unusual-cloud-device-registration, Entra ID Unusual Cloud Device Registration>> | Detects a sequence of events in Microsoft Entra ID indicative of suspicious cloud-based device registration via automated tooling like ROADtools or similar frameworks. This behavior involves adding a device via the Device Registration Service, followed by the assignment of registered users and owners — a pattern consistent with techniques used to establish persistence or acquire a Primary Refresh Token (PRT). ROADtools and similar tooling leave distinct telemetry signatures such as the `Microsoft.OData.Client` user agent. These sequences are uncommon in typical user behavior and may reflect abuse of device trust for session hijacking or silent token replay. | update | 3 
+
+|<<prebuilt-rule-8-19-16-high-mean-of-process-arguments-in-an-rdp-session, High Mean of Process Arguments in an RDP Session>> | A machine learning job has detected unusually high number of process arguments in an RDP session. Executing sophisticated attacks such as lateral movement can involve the use of complex commands, obfuscation mechanisms, redirection and piping, which in turn increases the number of arguments in a command. | update | 8 
+
+|<<prebuilt-rule-8-19-16-high-mean-of-rdp-session-duration, High Mean of RDP Session Duration>> | A machine learning job has detected unusually high mean of RDP session duration. Long RDP sessions can be used to evade detection mechanisms via session persistence, and might be used to perform tasks such as lateral movement, that might require uninterrupted access to a compromised machine. | update | 8 
+
+|<<prebuilt-rule-8-19-16-unusual-remote-file-size, Unusual Remote File Size>> | A machine learning job has detected an unusually high file size shared by a remote host indicating potential lateral movement activity. One of the primary goals of attackers after gaining access to a network is to locate and exfiltrate valuable information. Instead of multiple small transfers that can raise alarms, attackers might choose to bundle data into a single large file transfer. | update | 8 
+
+|<<prebuilt-rule-8-19-16-high-variance-in-rdp-session-duration, High Variance in RDP Session Duration>> | A machine learning job has detected unusually high variance of RDP session duration. Long RDP sessions can be used to evade detection mechanisms via session persistence, and might be used to perform tasks such as lateral movement, that might require uninterrupted access to a compromised machine. | update | 8 
+
+|<<prebuilt-rule-8-19-16-unusual-remote-file-directory, Unusual Remote File Directory>> | An anomaly detection job has detected a remote file transfer on an unusual directory indicating a potential lateral movement activity on the host. Many Security solutions monitor well-known directories for suspicious activities, so attackers might use less common directories to bypass monitoring. | update | 8 
+
+|<<prebuilt-rule-8-19-16-unusual-remote-file-extension, Unusual Remote File Extension>> | An anomaly detection job has detected a remote file transfer with a rare extension, which could indicate potential lateral movement activity on the host. | update | 8 
+
+|<<prebuilt-rule-8-19-16-spike-in-number-of-connections-made-from-a-source-ip, Spike in Number of Connections Made from a Source IP>> | A machine learning job has detected a high count of destination IPs establishing an RDP connection with a single source IP. Once an attacker has gained access to one system, they might attempt to access more in the network in search of valuable assets, data, or further access points. | update | 8 
+
+|<<prebuilt-rule-8-19-16-spike-in-number-of-connections-made-to-a-destination-ip, Spike in Number of Connections Made to a Destination IP>> | A machine learning job has detected a high count of source IPs establishing an RDP connection with a single destination IP. Attackers might use multiple compromised systems to attack a target to ensure redundancy in case a source IP gets detected and blocked. | update | 8 
+
+|<<prebuilt-rule-8-19-16-spike-in-number-of-processes-in-an-rdp-session, Spike in Number of Processes in an RDP Session>> | A machine learning job has detected unusually high number of processes started in a single RDP session. Executing a large number of processes remotely on other machines can be an indicator of lateral movement activity. | update | 8 
+
+|<<prebuilt-rule-8-19-16-spike-in-remote-file-transfers, Spike in Remote File Transfers>> | A machine learning job has detected an abnormal volume of remote files shared on the host indicating potential lateral movement activity. One of the primary goals of attackers after gaining access to a network is to locate and exfiltrate valuable information. Attackers might perform multiple small transfers to match normal egress activity in the network, to evade detection. | update | 8 
+
+|<<prebuilt-rule-8-19-16-unusual-time-or-day-for-an-rdp-session, Unusual Time or Day for an RDP Session>> | A machine learning job has detected an RDP session started at an usual time or weekday. An RDP session at an unusual time could be followed by other suspicious activities, so catching this is a good first step in detecting a larger attack. | update | 8 
+
+|<<prebuilt-rule-8-19-16-deprecated-m365-exchange-dlp-policy-deleted, Deprecated - M365 Exchange DLP Policy Deleted>> | Identifies when a Data Loss Prevention (DLP) policy is removed in Microsoft 365. An adversary may remove a DLP policy to evade existing DLP monitoring. | update | 212 
+
+|<<prebuilt-rule-8-19-16-deprecated-m365-teams-external-access-enabled, Deprecated - M365 Teams External Access Enabled>> | Identifies when external access is enabled in Microsoft Teams. External access lets Teams and Skype for Business users communicate with other users that are outside their organization. An adversary may enable external access or add an allowed domain to exfiltrate data or maintain persistence in an environment. | update | 212 
+
+|<<prebuilt-rule-8-19-16-deprecated-m365-security-compliance-potential-ransomware-activity, Deprecated - M365 Security Compliance Potential Ransomware Activity>> | Identifies when Microsoft Cloud App Security flags potential ransomware activity in Microsoft 365. This rule detects events where the Security Compliance Center reports a "Ransomware activity" or "Potential ransomware activity" alert, which may indicate file encryption, mass file modifications, or uploads of ransomware-infected files to cloud services such as SharePoint or OneDrive. | update | 213 
+
+|<<prebuilt-rule-8-19-16-deprecated-m365-security-compliance-unusual-volume-of-file-deletion, Deprecated - M365 Security Compliance Unusual Volume of File Deletion>> | Identifies that a user has deleted an unusually large volume of files as reported by Microsoft Cloud App Security. | update | 212 
+
+|<<prebuilt-rule-8-19-16-m365-identity-unusual-sso-authentication-errors-for-user, M365 Identity Unusual SSO Authentication Errors for User>> | Identifies the first occurrence of SSO, SAML, or federated authentication errors for a user. These errors may indicate token manipulation, SAML assertion tampering, or OAuth phishing attempts. Modern adversaries often target SSO mechanisms through token theft, SAML response manipulation, or exploiting federated authentication weaknesses rather than traditional brute force attacks. | update | 213 
+
+|<<prebuilt-rule-8-19-16-deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish, Deprecated - M365 Security Compliance Email Reported by User as Malware or Phish>> | Detects the occurrence of emails reported as Phishing or Malware by Users. Security Awareness training is essential to stay ahead of scammers and threat actors, as security products can be bypassed, and the user can still receive a malicious message. Educating users to report suspicious messages can help identify gaps in security controls and prevent malware infections and Business Email Compromise attacks. | update | 212 
+
+|<<prebuilt-rule-8-19-16-deprecated-m365-security-compliance-user-restricted-from-sending-email, Deprecated - M365 Security Compliance User Restricted from Sending Email>> | Identifies when a user has been restricted from sending email due to exceeding sending limits of the service policies per the Security Compliance Center. | update | 212 
+
+|<<prebuilt-rule-8-19-16-deprecated-m365-teams-guest-access-enabled, Deprecated - M365 Teams Guest Access Enabled>> | Identifies when guest access is enabled in Microsoft Teams. Guest access in Teams allows people outside the organization to access teams and channels. An adversary may enable guest access to maintain persistence in an environment. | update | 212 
+
+|<<prebuilt-rule-8-19-16-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. | update | 210 
+
+|<<prebuilt-rule-8-19-16-potential-okta-credential-stuffing-single-source, Potential Okta Credential Stuffing (Single Source)>> | Detects potential credential stuffing attacks where a single source IP attempts authentication against many Okta user accounts with minimal attempts per user, indicating the use of breached credential lists. | update | 210 
+
+|<<prebuilt-rule-8-19-16-potential-okta-password-spray-single-source, Potential Okta Password Spray (Single Source)>> | Detects potential password spray attacks where a single source IP attempts authentication against multiple Okta user accounts with repeated attempts per user, indicating common password guessing paced to avoid lockouts. | update | 417 
+
+|<<prebuilt-rule-8-19-16-okta-user-assigned-administrator-role, Okta User Assigned Administrator Role>> | Identifies when an administrator role is assigned to an Okta user or group. Adversaries may assign administrator privileges to compromised accounts to establish persistence, escalate privileges, and maintain long-term access to the environment. This detection monitors for both user-level and group-level administrator privilege grants, which can be used to bypass security controls and perform unauthorized administrative actions. | update | 413 
+
+|<<prebuilt-rule-8-19-16-potential-linux-tunneling-and-or-port-forwarding, Potential Linux Tunneling and/or Port Forwarding>> | This rule monitors for a set of Linux utilities that can be used for tunneling and port forwarding. Attackers can leverage tunneling and port forwarding techniques to bypass network defenses, establish hidden communication channels, and gain unauthorized access to internal resources, facilitating data exfiltration, lateral movement, and remote control. | update | 114 
+
+|<<prebuilt-rule-8-19-16-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option, Potential Linux Tunneling and/or Port Forwarding via SSH Option>> | This rule detects the use of SSH options that may indicate tunneling or port forwarding on Linux systems. This behavior is commonly associated with malicious activity, such as establishing a port forward, proxy or an encrypted tunnel to exfiltrate data. | update | 4 
+
+|<<prebuilt-rule-8-19-16-system-information-discovery-via-dmidecode-from-parent-shell, System Information Discovery via dmidecode from Parent Shell>> | This rule detects the use of dmidecode to gather system information from a Linux host when executed from a parent shell process. Adversaries may use dmidecode to collect detailed hardware and system information, which can aid in further exploitation or lateral movement within a network, or be used as a fingerprint for a compromised system. | update | 2 
+
+|<<prebuilt-rule-8-19-16-kernel-module-load-via-built-in-utility, Kernel Module Load via Built-in Utility>> | Detects the use of the insmod binary to load a Linux kernel object file. Threat actors can use this binary, given they have root privileges, to load a rootkit on a system providing them with complete control and the ability to hide from security products. Manually loading a kernel module in this manner should not be at all common and can indicate suspicious or malicious behavior. | update | 216 
+
+|<<prebuilt-rule-8-19-16-accepted-default-telnet-port-connection, Accepted Default Telnet Port Connection>> | This rule detects network events that may indicate the use of Telnet traffic. Telnet is commonly used by system administrators to remotely control older or embedded systems using the command line shell. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. As a plain-text protocol, it may also expose usernames and passwords to anyone capable of observing the traffic. | update | 111 
+
+|<<prebuilt-rule-8-19-16-clearing-windows-console-history, Clearing Windows Console History>> | Identifies when a user attempts to clear console history. An adversary may clear the command history of a compromised account to conceal the actions undertaken during an intrusion. | update | 318 
+
+|<<prebuilt-rule-8-19-16-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. | update | 315 
+
+|<<prebuilt-rule-8-19-16-deprecated-encoded-executable-stored-in-the-registry, Deprecated - Encoded Executable Stored in the Registry>> | Identifies registry write modifications to hide an encoded portable executable. This could be indicative of adversary defense evasion by avoiding the storing of malicious content directly on disk. | update | 416 
+
+|<<prebuilt-rule-8-19-16-disabling-lsa-protection-via-registry-modification, Disabling Lsa Protection via Registry Modification>> | LSA protecton is provided to prevent nonprotected processes from reading memory and injecting code. This feature provides added security for the credentials that LSA stores and manages. Adversaries may modify the RunAsPPL registry and wait or initiate a system restart to enable Lsass credentials access. | update | 4 
+
+|<<prebuilt-rule-8-19-16-program-files-directory-masquerading, Program Files Directory Masquerading>> | Identifies execution from a directory masquerading as the Windows Program Files directories. These paths are trusted and usually host trusted third party programs. An adversary may leverage masquerading, along with low privileges to bypass detections allowlisting those folders. | update | 319 
+
+|<<prebuilt-rule-8-19-16-suspicious-net-reflection-via-powershell, Suspicious .NET Reflection via PowerShell>> | Detects PowerShell scripts that invoke Reflection.Assembly or Assembly.Load to load .NET assemblies. Attackers use this method to load executables and DLLs without writing to the disk, bypassing security solutions. | update | 321 
+
+|<<prebuilt-rule-8-19-16-powershell-suspicious-payload-encoded-and-compressed, PowerShell Suspicious Payload Encoded and Compressed>> | Identifies PowerShell script block content that combines Base64 decoding with .NET decompression (Deflate/GZip). Attackers use this pattern to deobfuscate and reconstruct payloads in memory to evade defenses. | update | 318 
+
+|<<prebuilt-rule-8-19-16-powershell-script-with-windows-defender-tampering-capabilities, PowerShell Script with Windows Defender Tampering Capabilities>> | Detects PowerShell scripts that uses Set-MpPreference with parameters that disable or weaken Defender. Attackers tamper with antivirus settings to reduce detection and enable follow-on payload execution. | update | 108 
+
+|<<prebuilt-rule-8-19-16-powershell-script-with-encryption-decryption-capabilities, PowerShell Script with Encryption/Decryption Capabilities>> | Identifies PowerShell script block content that uses .NET cryptography APIs for file encryption or decryption. Attackers abuse these routines to encrypt data for impact or decrypt staged payloads to evade defenses. | update | 112 
+
+|<<prebuilt-rule-8-19-16-deprecated-potential-powershell-obfuscated-script, Deprecated - Potential PowerShell Obfuscated Script>> | Identifies scripts that contain patterns and known methods that obfuscate PowerShell code. Attackers can use obfuscation techniques to bypass PowerShell security protections such as Antimalware Scan Interface (AMSI). | update | 109 
+
+|<<prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-invalid-escape-sequences, Potential PowerShell Obfuscation via Invalid Escape Sequences>> | Detects PowerShell scripts with repeated invalid backtick escapes between word characters (letters, digits, underscore, or dash), splitting tokens while preserving execution. Attackers use this obfuscation to fragment keywords and evade pattern-based detection and AMSI. | update | 11 
+
+|<<prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion, Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion>> | Detects PowerShell scripts that uses backtick-escaped characters inside `${}` variable expansion (multiple backticks between word characters) to reconstruct strings at runtime. Attackers use variable-expansion obfuscation to split keywords, hide commands, and evade static analysis and AMSI. | update | 9 
+
+|<<prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-character-array-reconstruction, Potential PowerShell Obfuscation via Character Array Reconstruction>> | Detects PowerShell scripts that reconstructs strings from char[] arrays, index lookups, or repeated ([char]NN)+ concatenation/join logic. Attackers use character-array reconstruction to hide commands, URLs, or payloads and evade static analysis and AMSI. | update | 9 
+
+|<<prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation, Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation>> | Detects PowerShell scripts that builds commands from concatenated string literals inside dynamic invocation constructs like &() or .(). Attackers use concatenated dynamic invocation to obscure execution intent, bypass keyword-based detections, and evade AMSI. | update | 9 
+
+|<<prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-high-numeric-character-proportion, Potential PowerShell Obfuscation via High Numeric Character Proportion>> | Detects long PowerShell script block content with unusually high numeric character density (high digit-to-length ratio), often produced by byte arrays, character-code reconstruction, or embedded encoded blobs. Attackers use numeric-heavy obfuscation to conceal payloads and rebuild them at runtime to avoid static inspection. | update | 11 
+
+|<<prebuilt-rule-8-19-16-potential-dynamic-iex-reconstruction-via-environment-variables, Potential Dynamic IEX Reconstruction via Environment Variables>> | Detects PowerShell scripts that reconstructs IEX (Invoke-Expression) by indexing environment variable strings (for example, $env:VAR[1,2,3]) or related `.name[...]` slices and joining characters at runtime. Attackers use environment-variable slicing to hide dynamic execution and evade keyword-based detections and AMSI. | update | 10 
+
+|<<prebuilt-rule-8-19-16-dynamic-iex-reconstruction-via-method-string-access, Dynamic IEX Reconstruction via Method String Access>> | Detects PowerShell scripts that rebuilds IEX by converting method references to strings (for example, ''.IndexOf.ToString()) and extracting multiple indexed characters (for example, [n,n,n]). Attackers use method-string reconstruction to conceal dynamic execution and bypass static detections and AMSI. | update | 11 
+
+|<<prebuilt-rule-8-19-16-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. | update | 9 
+
+|<<prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-reverse-keywords, Potential PowerShell Obfuscation via Reverse Keywords>> | Detects PowerShell scripts containing reversed keyword strings associated with execution or network activity (for example, ekovni, noisserpxe, daolnwod, tcejbo-wen, tcejboimw, etc.). Attackers reverse keywords and reconstruct them at runtime to hide intent and evade static detection and AMSI. | update | 10 
+
+|<<prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-string-concatenation, Potential PowerShell Obfuscation via String Concatenation>> | Detects PowerShell scripts that repeatedly concatenates multiple quoted string literals with + to assemble commands or tokens at runtime. Attackers use string concatenation to fragment keywords or URLs and evade static analysis and AMSI. | update | 10 
+
+|<<prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-string-reordering, Potential PowerShell Obfuscation via String Reordering>> | Detects PowerShell scripts that uses format placeholders like "{0}{1}" with the -f operator or ::Format to reorder strings at runtime. Attackers use format-based reconstruction to hide commands or payload strings and evade static analysis and AMSI. | update | 12 
+
+|<<prebuilt-rule-8-19-16-potential-powershell-obfuscation-via-special-character-overuse, Potential PowerShell Obfuscation via Special Character Overuse>> | Detects PowerShell scripts dominated by whitespace and special characters with low symbol diversity, a profile often produced by formatting or encoding obfuscation. Attackers use symbol-heavy encoding or formatting (for example, SecureString-style blobs or character-level transforms) to hide payloads and evade static analysis and AMSI. | update | 10 
+
+|<<prebuilt-rule-8-19-16-potential-process-injection-via-powershell, Potential Process Injection via PowerShell>> | Detects PowerShell scripts that combines Win32 APIs for allocation/protection or process access (for example, VirtualAlloc/VirtualProtect/OpenProcess/AdjustTokenPrivileges/LoadLibrary/GetProcAddress) with injection or execution APIs (WriteProcessMemory/CreateRemoteThread/NtCreateThreadEx/QueueUserAPC/ResumeThread). Attackers use these API chains to inject code into remote processes and execute payloads in memory for defense evasion. | update | 217 
+
+|<<prebuilt-rule-8-19-16-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. | update | 212 
+
+|<<prebuilt-rule-8-19-16-potential-timestomp-in-executable-files, Potential Timestomp in Executable Files>> | Identifies the modification of a file creation time for executable files in sensitive system directories. Adversaries may modify file time attributes to blend malicious executables with legitimate system files. Timestomping is a technique that modifies the timestamps of a file often to mimic files that are in trusted directories. | update | 110 
+
+|<<prebuilt-rule-8-19-16-execution-via-windows-subsystem-for-linux, Execution via Windows Subsystem for Linux>> | Detects attempts to execute a program on the host from the Windows Subsystem for Linux. Adversaries may enable and use WSL for Linux to avoid detection. | update | 214 
+
+|<<prebuilt-rule-8-19-16-powershell-share-enumeration-script, PowerShell Share Enumeration Script>> | Detects PowerShell scripts that uses ShareFinder functions (Invoke-ShareFinder/Invoke-ShareFinderThreaded) or Windows share enumeration APIs (shi1_netname/shi1_remark with NetShareEnum/NetApiBufferFree). Attackers use share enumeration to map accessible network shares for collection, lateral movement, or ransomware targeting. | update | 115 
+
+|<<prebuilt-rule-8-19-16-powershell-suspicious-discovery-related-windows-api-functions, PowerShell Suspicious Discovery Related Windows API Functions>> | Detects PowerShell scripts that references native Windows API functions commonly used for discovery of users, groups, shares, sessions, domain trusts, and service security. Attackers use these APIs for situational awareness and targeting prior to lateral movement or collection. | update | 319 
+
+|<<prebuilt-rule-8-19-16-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. | update | 213 
+
+|<<prebuilt-rule-8-19-16-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 | 109 
+
+|<<prebuilt-rule-8-19-16-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. | update | 220 
+
+|<<prebuilt-rule-8-19-16-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 | 5 
+
+|<<prebuilt-rule-8-19-16-suspicious-portable-executable-encoded-in-powershell-script, Suspicious Portable Executable Encoded in Powershell Script>> | Detects PowerShell scripts that includes a base64-encoded portable executable (PE) header, indicating an embedded binary payload. Attackers embed PEs in scripts to load payloads in memory and avoid writing executables to disk. | update | 216 
+
+|<<prebuilt-rule-8-19-16-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. | update | 317 
+
+|<<prebuilt-rule-8-19-16-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. | update | 208 
+
+|<<prebuilt-rule-8-19-16-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. | update | 211 
+
+|<<prebuilt-rule-8-19-16-deprecated-adobe-hijack-persistence, Deprecated - Adobe Hijack Persistence>> | Detects writing executable files that will be automatically launched by Adobe on launch. | update | 419 
+
+|<<prebuilt-rule-8-19-16-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. | update | 3 
+
+|<<prebuilt-rule-8-19-16-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. | update | 3 
+
+|<<prebuilt-rule-8-19-16-powershell-script-with-token-impersonation-capabilities, PowerShell Script with Token Impersonation Capabilities>> | Detects PowerShell scripts that references token manipulation and impersonation APIs such as CreateProcessWithTokenW, DuplicateToken/ImpersonateLoggedOnUser, or AdjustTokenPrivileges (SeDebugPrivilege). Attackers abuse token impersonation to elevate privileges and bypass access controls. | update | 118 
+
+|<<prebuilt-rule-8-19-16-deprecated-suspicious-printspooler-service-executable-file-creation, Deprecated - Suspicious PrintSpooler Service Executable File Creation>> | Detects attempts to exploit privilege escalation vulnerabilities related to the Print Spooler service. For more information refer to the following CVE's - CVE-2020-1048, CVE-2020-1337 and CVE-2020-1300 and verify that the impacted system is patched. | update | 320 
+
+|==============================================
diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc
index b22dbee687..dd7ce0419a 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-16-prebuilt-rules-8-19-16-summary, 8.19.16>> | 24 Feb 2026 | 18 | 93 | 
+This release includes new rules for Windows, Linux, Okta, Azure, Fortinet and AWS. New rules for Windows include detection for execution and defense evasion. New rules for Linux include detection for persistence, defense evasion and discovery. New rules for Okta include detection for credential access. New rules for Fortinet include detection for initial access. New rules for Azure include detection for initial access. New rules for AWS include detection for persistence, defense evasion and discovery. Additionally, significant rule tuning for Windows, Okta, Azure, Linux, Microsoft 365 and AWS rules has been added for better rule efficacy and performance.
+
+
 |<<prebuilt-rule-8-19-15-prebuilt-rules-8-19-15-summary, 8.19.15>> | 10 Feb 2026 | 53 | 36 | 
 This release includes new rules for MacOS, Windows, Linux, Fortinet and AWS. New rules for MacOS command and control, persistence, execution, discovery, lateral movement and collection New rules for Windows include detection for command and control and initial access. New rules for Linux include detection for command and control and execution. New rules for Fortinet include detection for persistence, collection, defense evasion and initial access. New rules for AWS include detection for defense evasion. Rules that consistently demonstrated low true-positive rates across data sources have been deprecated. Additionally, significant rule tuning for Windows, Linux, Kubernetes, MacOS, Microsoft 365 and AWS rules has been added for better rule efficacy and performance.
 
@@ -88,3 +92,4 @@ include::downloadable-packages/8-19-12/prebuilt-rules-8-19-12-summary.asciidoc[l
 include::downloadable-packages/8-19-13/prebuilt-rules-8-19-13-summary.asciidoc[leveloffset=+1]
 include::downloadable-packages/8-19-14/prebuilt-rules-8-19-14-summary.asciidoc[leveloffset=+1]
 include::downloadable-packages/8-19-15/prebuilt-rules-8-19-15-summary.asciidoc[leveloffset=+1]
+include::downloadable-packages/8-19-16/prebuilt-rules-8-19-16-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 9685fbcb97..b41b884d31 100644
--- a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc
+++ b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc
@@ -110,6 +110,8 @@ and their rule type is `machine_learning`.
 
 |<<aws-guardduty-detector-deletion, AWS GuardDuty Detector Deletion>> |Detects the deletion of an Amazon GuardDuty detector. GuardDuty provides continuous monitoring for malicious or unauthorized activity across AWS accounts. Deleting the detector disables this visibility, stopping all threat detection and removing existing findings. Adversaries may delete GuardDuty detectors to impair security monitoring and evade detection during or after an intrusion. This rule identifies successful "DeleteDetector" API calls and can indicate a deliberate defense evasion attempt. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS GuardDuty], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |211
 
+|<<aws-guardduty-member-account-manipulation, AWS GuardDuty Member Account Manipulation>> |Detects attempts to disassociate or manipulate Amazon GuardDuty member accounts within an AWS organization. In multi-account GuardDuty deployments, a delegated administrator account aggregates findings from member accounts. Adversaries may attempt to disassociate member accounts, delete member relationships, stop monitoring members, or delete pending invitations to break this centralized visibility. These actions can be precursors to or alternatives for deleting GuardDuty detectors entirely, allowing attackers to operate undetected in member accounts while the administrator account loses visibility. This rule identifies successful API calls that manipulate GuardDuty member relationships, which are rare in normal operations and warrant immediate investigation. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS GuardDuty], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1
+
 |<<aws-iam-api-calls-via-temporary-session-tokens, AWS IAM API Calls via Temporary Session Tokens>> |Detects sensitive AWS IAM API operations executed using temporary session credentials (access key IDs beginning with "ASIA"). Temporary credentials are commonly issued through sts:GetSessionToken, sts:AssumeRole, or AWS SSO logins and are meant for short-term use. It is unusual for legitimate users or automated processes to perform privileged IAM actions (e.g., creating users, updating policies, or enabling/disabling MFA) with session tokens. This behavior may indicate credential theft, session hijacking, or the abuse of a privileged role’s temporary credentials. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Data Source: AWS STS], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |6
 
 |<<aws-iam-administratoraccess-policy-attached-to-group, AWS IAM AdministratorAccess Policy Attached to Group>> |An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM AttachGroupPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user group. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |8
@@ -136,12 +138,16 @@ and their rule type is `machine_learning`.
 
 |<<aws-iam-login-profile-added-to-user, AWS IAM Login Profile Added to User>> |Identifies when an AWS IAM login profile is added to a user. Adversaries may add a login profile to an IAM user who typically does not have one and is used only for programmatic access. This can be used to maintain access to the account even if the original access key is rotated or disabled. This is a building block rule and does not generate alerts on its own. It is meant to be used for correlation with other rules to detect suspicious activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Rule Type: BBR] |None |4
 
+|<<aws-iam-oidc-provider-created-by-rare-user, AWS IAM OIDC Provider Created by Rare User>> |Detects when an uncommon user or role creates an OpenID Connect (OIDC) Identity Provider in AWS IAM. OIDC providers enable web identity federation, allowing users authenticated by external identity providers (such as Google, GitHub, or custom OIDC-compliant providers) to assume IAM roles and access AWS resources. Adversaries who have gained administrative access may create rogue OIDC providers to establish persistent, federated access that survives credential rotation. This technique allows attackers to assume roles using tokens from an IdP they control. While OIDC provider creation is benign in some environments, it should still be validated against authorized infrastructure changes. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |1
+
 |<<aws-iam-principal-enumeration-via-updateassumerolepolicy, AWS IAM Principal Enumeration via UpdateAssumeRolePolicy>> |Detects repeated failed attempts to update an IAM role’s trust policy in an AWS account, consistent with role and user enumeration techniques. In this technique, an attacker who controls credentials in the current account repeatedly calls UpdateAssumeRolePolicy on a single role, cycling through guessed cross-account role or user ARNs as the principal. When those principals are invalid, IAM returns MalformedPolicyDocumentException, producing a burst of failed UpdateAssumeRolePolicy events. This rule alerts on that brute-force pattern originating from this account, which may indicate that the account is being used as attack infrastructure or that offensive tooling (such as Pacu) is running here. Note: this rule does not detect other accounts enumerating roles, because those API calls are logged in the caller’s account, not the target account. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Discovery], [Tactic: Credential Access] |None |214
 
 |<<aws-iam-roles-anywhere-profile-creation, AWS IAM Roles Anywhere Profile Creation>> |Detects the creation of a new AWS IAM Roles Anywhere profile. Roles Anywhere allows workloads or external systems to assume IAM roles from outside AWS by authenticating via trusted certificate authorities (trust anchors). Adversaries who have established persistence through a rogue trust anchor may create or modify profiles to link them with highly privileged roles, enabling long-term external access to the AWS environment. This rule identifies successful "CreateProfile" API calls and helps detect potentially unauthorized or risky external access configurations. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |7
 
 |<<aws-iam-roles-anywhere-trust-anchor-created-with-external-ca, AWS IAM Roles Anywhere Trust Anchor Created with External CA>> |Detects the creation of an AWS IAM Roles Anywhere Trust Anchor that uses an external certificate authority (CA) rather than an AWS-managed Certificate Manager Private CA (ACM PCA). While Roles Anywhere enables secure, short-term credential issuance for workloads outside AWS, adversaries can exploit this feature by registering their own external CA as a trusted root. This allows them to generate valid client certificates that persistently authenticate to AWS roles from any location, even after key rotation or credential revocation events. This rule helps detect persistence or unauthorized federation attempts by flagging trust anchors configured with non-AWS CAs. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |7
 
+|<<aws-iam-saml-provider-created, AWS IAM SAML Provider Created>> |Detects the creation of a new SAML Identity Provider (IdP) in AWS IAM. SAML providers enable federated authentication between AWS and external identity providers, allowing users to access AWS resources using credentials from the external IdP. Adversaries who have gained administrative access may create rogue SAML providers to establish persistent, federated access to AWS accounts that survives credential rotation. This technique allows attackers to assume roles and access resources by forging SAML assertions from an IdP they control. Creating a SAML provider is a rare administrative action that should be closely monitored and validated against authorized infrastructure changes. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |1
+
 |<<aws-iam-saml-provider-updated, AWS IAM SAML Provider Updated>> |Detects when an AWS IAM SAML provider is updated, which manages federated authentication between AWS and external identity providers (IdPs). Adversaries with administrative access may modify a SAML provider’s metadata or certificate to redirect authentication flows, enable unauthorized federation, or escalate privileges through identity trust manipulation. Because SAML providers underpin single sign-on (SSO) access for users and applications, unauthorized modifications may allow persistent or covert access even after credentials are revoked. Monitoring  "UpdateSAMLProvider" API activity is critical to detect potential compromise of federated trust relationships. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |212
 
 |<<aws-iam-user-addition-to-group, AWS IAM User Addition to Group>> |Identifies the addition of a user to a specified group in AWS Identity and Access Management (IAM). Any user added to a group automatically gains the permissions that are assigned to the group. If the target group carries elevated or admin privileges, this action can instantly grant high-risk permissions useful for credential misuse, lateral movement, or privilege escalation. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Tactic: Persistence], [Resources: Investigation Guide] |None |213
@@ -220,6 +226,8 @@ and their rule type is `machine_learning`.
 
 |<<aws-ssm-command-document-created-by-rare-user, AWS SSM Command Document Created by Rare User>> |Identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, data exfiltration and more. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SSM], [Data Source: AWS Systems Manager], [Resources: Investigation Guide], [Use Case: Threat Detection], [Tactic: Execution] |None |5
 
+|<<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 |1
+
 |<<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 |5
 
 |<<aws-ssm-sendcommand-execution-by-rare-user, AWS SSM `SendCommand` Execution by Rare User>> |Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as RunShellScript, RunPowerShellScript or custom documents. While legitimate users may employ these commands for management tasks, they can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells for further access to compromised instances. This is a New Terms rule that looks for the first instance of this behavior by a user or role. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SSM], [Data Source: AWS Systems Manager], [Use Case: Log Auditing], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |215
@@ -242,6 +250,8 @@ and their rule type is `machine_learning`.
 
 |<<aws-secrets-manager-rapid-secrets-retrieval, AWS Secrets Manager Rapid Secrets Retrieval>> |Identifies rapid secret retrieval activity from AWS Secrets Manager using the GetSecretValue or BatchGetSecretValue API actions. Adversaries who compromise an IAM user, instance role, or temporary credentials may attempt to enumerate or exfiltrate secrets in bulk to escalate privileges, move laterally, or gain persistence. This rule detects 20 or more unique secret retrievals by the same user identity within a short time window, which may indicate credential compromise or automated secret harvesting. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Secrets Manager], [Tactic: Credential Access], [Resources: Investigation Guide] |None |6
 
+|<<aws-sensitive-iam-operations-performed-via-cloudshell, AWS Sensitive IAM Operations Performed via CloudShell>> |Identifies sensitive AWS IAM operations performed via AWS CloudShell based on the user agent string. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. While convenient for administrators, CloudShell access from compromised console sessions can enable attackers to perform privileged operations without installing tools or using programmatic credentials. This rule detects high-risk actions such as creating IAM users, access keys, roles, or attaching policies when initiated from CloudShell, which may indicate post-compromise credential harvesting or privilege escalation activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Tactic: Persistence], [Tactic: Privilege Escalation], [Use Case: Threat Detection], [Resources: Investigation Guide] |None |1
+
 |<<aws-service-quotas-multi-region-getservicequota-requests, AWS Service Quotas Multi-Region GetServiceQuota Requests>> |Identifies when a single AWS principal makes GetServiceQuota API calls for the EC2 service quota L-1216C47A, across more than 10 AWS regions within a 30-second window. This quota represents the vCPU limit for on-demand EC2 instances. Adversaries commonly enumerate this quota across regions to assess capacity for large-scale instance deployment, including cryptocurrency mining, malware hosting, or command-and-control infrastructure. This behavior may indicate cloud infrastructure discovery using compromised credentials or a compromised workload. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Service Quotas], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |8
 
 |<<aws-sign-in-console-login-with-federated-user, AWS Sign-In Console Login with Federated User>> |Identifies when a federated user logs into the AWS Management Console. Federated users are typically given temporary credentials to access AWS services. If a federated user logs into the AWS Management Console without using MFA, it may indicate a security risk, as MFA adds an additional layer of security to the authentication process. However, CloudTrail does not record whether a Federated User utilized MFA as part of authentication — that MFA decision often occurs at a third-party IdP (e.g., Okta, Azure AD, Google). As a result, CloudTrail fields such as MFAUsed / mfaAuthenticated appear as “No/false” for federated console logins even if IdP MFA was required. This alert should be correlated with IdP authentication logs to verify whether MFA was enforced for the session. Increase priority if you find a related "GetSigninToken" event whose source IP / ASN / geo or user-agent differs from the subsequent "ConsoleLogin" (possible token relay/abuse). Same-IP/UA pairs within a short window are more consistent with expected operator behavior and can be triaged with lower severity. |[Domain: Cloud], [Data Source: Amazon Web Services], [Data Source: AWS], [Data Source: AWS Sign-In], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |6
@@ -262,7 +272,7 @@ and their rule type is `machine_learning`.
 
 |<<abnormally-large-dns-response, Abnormally Large DNS Response>> |Specially crafted DNS requests can manipulate a known overflow vulnerability in some Windows DNS servers, resulting in Remote Code Execution (RCE) or a Denial of Service (DoS) from crashing the service. |[Use Case: Threat Detection], [Tactic: Lateral Movement], [Resources: Investigation Guide], [Use Case: Vulnerability] |None |107
 
-|<<accepted-default-telnet-port-connection, Accepted Default Telnet Port Connection>> |This rule detects network events that may indicate the use of Telnet traffic. Telnet is commonly used by system administrators to remotely control older or embedded systems using the command line shell. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. As a plain-text protocol, it may also expose usernames and passwords to anyone capable of observing the traffic. |[Domain: Endpoint], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Lateral Movement], [Tactic: Initial Access], [Data Source: PAN-OS], [Data Source: Fortinet], [Data Source: SonicWall], [Data Source: Suricata], [Resources: Investigation Guide] |None |110
+|<<accepted-default-telnet-port-connection, Accepted Default Telnet Port Connection>> |This rule detects network events that may indicate the use of Telnet traffic. Telnet is commonly used by system administrators to remotely control older or embedded systems using the command line shell. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. As a plain-text protocol, it may also expose usernames and passwords to anyone capable of observing the traffic. |[Domain: Endpoint], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Lateral Movement], [Tactic: Initial Access], [Data Source: PAN-OS], [Data Source: Fortinet], [Data Source: SonicWall], [Data Source: Suricata], [Resources: Investigation Guide] |None |111
 
 |<<access-control-list-modification-via-setfacl, Access Control List Modification via setfacl>> |This rule detects Linux Access Control List (ACL) modification via the setfacl command. Attackers may use the setfacl utility to modify file and directory permissions in order to evade detection and maintain persistence on a compromised system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |107
 
@@ -294,21 +304,17 @@ and their rule type is `machine_learning`.
 
 |<<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 |412
 
-|<<administrator-role-assigned-to-an-okta-user, Administrator Role Assigned to an Okta User>> |Identifies when an administrator role is assigned to an Okta user. An adversary may attempt to assign an administrator role to an Okta user in order to assign additional permissions to a user account and maintain access to their target's environment. |[Data Source: Okta], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |412
-
-|<<adobe-hijack-persistence, Adobe Hijack Persistence>> |Detects writing executable files that will be automatically launched by Adobe on launch. |[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: SentinelOne], [Data Source: Microsoft Defender for Endpoint], [Data Source: Crowdstrike] |None |418
-
 |<<adversary-behavior-detected-elastic-endgame, Adversary Behavior - Detected - Elastic Endgame>> |Elastic Endgame detected an Adversary Behavior. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. |[Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |106
 
 |<<agent-spoofing-multiple-hosts-using-same-agent, Agent Spoofing - Multiple Hosts Using Same Agent>> |Detects when multiple hosts are using the same agent ID. This could occur in the event of an agent being taken over and used to inject illegitimate documents into an instance as an attempt to spoof events in order to masquerade actual activity to evade detection. |[Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |106
 
-|<<alerts-from-multiple-integrations-by-destination-address, Alerts From Multiple Integrations by Destination Address>> |This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same destination.ip are triggered. Analysts can use this to prioritize triage and response, as these IP address is more likely to be related to a compromise. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |2
+|<<alerts-from-multiple-integrations-by-destination-address, Alerts From Multiple Integrations by Destination Address>> |This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same destination.ip are triggered. Analysts can use this to prioritize triage and response, as these IP address is more likely to be related to a compromise. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |3
 
-|<<alerts-from-multiple-integrations-by-source-address, Alerts From Multiple Integrations by Source Address>> |This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same source.ip are triggered. Analysts can use this to prioritize triage and response, as these IP addresses are more likely to be related to a compromise. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |2
+|<<alerts-from-multiple-integrations-by-source-address, Alerts From Multiple Integrations by Source Address>> |This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same source.ip are triggered. Analysts can use this to prioritize triage and response, as these IP addresses are more likely to be related to a compromise. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |3
 
-|<<alerts-from-multiple-integrations-by-user-name, Alerts From Multiple Integrations by User Name>> |This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same user.name are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |2
+|<<alerts-from-multiple-integrations-by-user-name, Alerts From Multiple Integrations by User Name>> |This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same user.name are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |3
 
-|<<alerts-in-different-att-ck-tactics-by-host, Alerts in Different ATT&CK Tactics by Host>> |This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered and where the accumulated risk score is higher than a defined threshold. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |2
+|<<alerts-in-different-att-ck-tactics-by-host, Alerts in Different ATT&CK Tactics by Host>> |This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered and where the accumulated risk score is higher than a defined threshold. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |3
 
 |<<alternate-data-stream-creation-execution-at-volume-root-directory, Alternate Data Stream Creation/Execution at Volume Root Directory>> |Identifies the creation of an Alternate Data Stream (ADS) at a volume root directory, which can indicate the attempt to hide tools and malware, as ADSs created in this directory are not displayed by system utilities. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |204
 
@@ -470,6 +476,10 @@ and their rule type is `machine_learning`.
 
 |<<azure-vnet-network-watcher-deleted, Azure VNet Network Watcher Deleted>> |Identifies the deletion of a Network Watcher in Azure. Network Watchers are used to monitor, diagnose, view metrics, and enable or disable logs for resources in an Azure virtual network. An adversary may delete a Network Watcher in an attempt to evade defenses. |[Domain: Cloud], [Data Source: Azure], [Use Case: Network Security Monitoring], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |107
 
+|<<bpf-program-tampering-via-bpftool, BPF Program Tampering via bpftool>> |Detects execution of bpftool commands used to detach eBPF programs or links, or to delete or modify eBPF maps. These actions can disable, alter, or interfere with kernel-level instrumentation and enforcement mechanisms implemented through eBPF. In environments relying on eBPF-based networking, observability, or security controls, unexpected use of these operations may indicate defense evasion or runtime tampering. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Threat: Rootkit], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |1
+
+|<<bpf-program-or-map-load-via-bpftool, BPF Program or Map Load via bpftool>> |Detects execution of bpftool commands used to load, attach, run, or pin eBPF programs, as well as create or update eBPF maps and links. These operations interact directly with the Linux eBPF subsystem and can modify kernel-level behavior. While commonly used by legitimate networking or observability tooling, unexpected or interactive usage may indicate eBPF-based rootkit activity, policy tampering, or unauthorized kernel instrumentation. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Threat: Rootkit], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |1
+
 |<<bpf-filter-applied-using-tc, BPF filter applied using TC>> |Detects when the tc (transmission control) binary is utilized to set a BPF (Berkeley Packet Filter) on a network interface. Tc is used to configure Traffic Control in the Linux kernel. It can shape, schedule, police and drop traffic. A threat actor can utilize tc to set a bpf filter on an interface for the purpose of manipulating the incoming traffic. This technique is not at all common and should indicate abnormal, suspicious or malicious activity. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Threat: TripleCross], [Data Source: Auditd Manager], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |214
 
 |<<backup-deletion-with-wbadmin, Backup Deletion with Wbadmin>> |Detects use of wbadmin.exe to delete backup catalogs, system state backups, or other backup data. Ransomware and other malware may do this to prevent system recovery. |[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 for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |318
@@ -500,7 +510,7 @@ and their rule type is `machine_learning`.
 
 |<<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 |218
 
-|<<clearing-windows-console-history, Clearing Windows Console History>> |Identifies when a user attempts to clear console history. An adversary may clear the command history of a compromised account to conceal the actions undertaken during an intrusion. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |317
+|<<clearing-windows-console-history, Clearing Windows Console History>> |Identifies when a user attempts to clear console history. An adversary may clear the command history of a compromised account to conceal the actions undertaken during an intrusion. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |318
 
 |<<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 for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |319
 
@@ -518,11 +528,9 @@ and their rule type is `machine_learning`.
 
 |<<command-obfuscation-via-unicode-modifier-letters, Command Obfuscation via Unicode Modifier Letters>> |Identifies the presence of unicode modifier letters in the process command_line. Adversaries sometimes replace ASCII characters with visually similar Unicode modifier letters or combining marks to evade simple string-based detections. |[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 for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |1
 
-|<<command-prompt-network-connection, Command Prompt Network Connection>> |Identifies cmd.exe making a network connection. Adversaries could abuse cmd.exe to download or execute malware from a remote URL. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne] |None |212
-
 |<<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 for Endpoint], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |313
 
-|<<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 for Endpoint], [Data Source: Elastic Endgame], [Data Source: Crowdstrike] |None |207
+|<<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 for Endpoint], [Data Source: Elastic Endgame], [Data Source: Crowdstrike] |None |208
 
 |<<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 |118
 
@@ -530,7 +538,7 @@ and their rule type is `machine_learning`.
 
 |<<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 for Endpoint], [Data Source: SentinelOne] |None |312
 
-|<<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], [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 |2
+|<<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 |3
 
 |<<connection-to-commonly-abused-free-ssl-certificate-providers, Connection to Commonly Abused Free SSL Certificate Providers>> |Identifies unusual processes connecting to domains using known free SSL certificates. Adversaries may employ a known encryption algorithm to conceal command and control traffic. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Sysmon], [Resources: Investigation Guide] |None |210
 
@@ -544,6 +552,8 @@ and their rule type is `machine_learning`.
 
 |<<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], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |317
 
+|<<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 |2
+
 |<<creation-of-hidden-files-and-directories-via-commandline, Creation of Hidden Files and Directories via CommandLine>> |Users can mark specific files as hidden simply by putting a "." as the first character in the file or folder name. Adversaries can use this to their advantage to hide files and folders on the system for persistence and defense evasion. This rule looks for hidden files or folders in common writable directories. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |116
 
 |<<creation-of-hidden-launch-agent-or-daemon, Creation of Hidden Launch Agent or Daemon>> |Identifies the creation of a hidden launch agent or daemon. An adversary may establish persistence by installing a new launch agent or daemon which executes at login. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |112
@@ -614,15 +624,45 @@ 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 |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. |[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 |2
+|<<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
 
 |<<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 for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |314
 
+|<<deprecated-adobe-hijack-persistence, Deprecated - Adobe Hijack Persistence>> |Detects writing executable files that will be automatically launched by Adobe on launch. |[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: SentinelOne], [Data Source: Microsoft Defender for Endpoint], [Data Source: Crowdstrike] |None |419
+
 |<<deprecated-eggshell-backdoor-execution, Deprecated - EggShell Backdoor Execution>> |Identifies the execution of and EggShell Backdoor. EggShell is a known post exploitation tool for macOS and Linux. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |107
 
+|<<deprecated-encoded-executable-stored-in-the-registry, Deprecated - Encoded Executable Stored in the Registry>> |Identifies registry write modifications to hide an encoded portable executable. This could be indicative of adversary defense evasion by avoiding the storing of malicious content directly on disk. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender for Endpoint], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |416
+
+|<<deprecated-m365-exchange-dlp-policy-deleted, Deprecated - M365 Exchange DLP Policy Deleted>> |Identifies when a Data Loss Prevention (DLP) policy is removed in Microsoft 365. An adversary may remove a DLP policy to evade existing DLP monitoring. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |212
+
+|<<deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish, Deprecated - M365 Security Compliance Email Reported by User as Malware or Phish>> |Detects the occurrence of emails reported as Phishing or Malware by Users. Security Awareness training is essential to stay ahead of scammers and threat actors, as security products can be bypassed, and the user can still receive a malicious message. Educating users to report suspicious messages can help identify gaps in security controls and prevent malware infections and Business Email Compromise attacks. |[Domain: Cloud], [Data Source: Microsoft 365], [Tactic: Initial Access], [Resources: Investigation Guide] |None |212
+
+|<<deprecated-m365-security-compliance-potential-ransomware-activity, Deprecated - M365 Security Compliance Potential Ransomware Activity>> |Identifies when Microsoft Cloud App Security flags potential ransomware activity in Microsoft 365. This rule detects events where the Security Compliance Center reports a "Ransomware activity" or "Potential ransomware activity" alert, which may indicate file encryption, mass file modifications, or uploads of ransomware-infected files to cloud services such as SharePoint or OneDrive. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |213
+
+|<<deprecated-m365-security-compliance-unusual-volume-of-file-deletion, Deprecated - M365 Security Compliance Unusual Volume of File Deletion>> |Identifies that a user has deleted an unusually large volume of files as reported by Microsoft Cloud App Security. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Impact], [Resources: Investigation Guide] |None |212
+
+|<<deprecated-m365-security-compliance-user-restricted-from-sending-email, Deprecated - M365 Security Compliance User Restricted from Sending Email>> |Identifies when a user has been restricted from sending email due to exceeding sending limits of the service policies per the Security Compliance Center. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Impact], [Resources: Investigation Guide] |None |212
+
+|<<deprecated-m365-teams-external-access-enabled, Deprecated - M365 Teams External Access Enabled>> |Identifies when external access is enabled in Microsoft Teams. External access lets Teams and Skype for Business users communicate with other users that are outside their organization. An adversary may enable external access or add an allowed domain to exfiltrate data or maintain persistence in an environment. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |212
+
+|<<deprecated-m365-teams-guest-access-enabled, Deprecated - M365 Teams Guest Access Enabled>> |Identifies when guest access is enabled in Microsoft Teams. Guest access in Teams allows people outside the organization to access teams and channels. An adversary may enable guest access to maintain persistence in an environment. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |212
+
+|<<deprecated-microsoft-exchange-transport-agent-install-script, Deprecated - Microsoft Exchange Transport Agent Install Script>> |Identifies the use of Cmdlets and methods related to Microsoft Exchange Transport Agents install. Adversaries may leverage malicious Microsoft Exchange Transport Agents to execute tasks in response to adversary-defined criteria, establishing persistence. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: PowerShell Logs], [Rule Type: BBR] |None |110
+
+|<<deprecated-potential-powershell-obfuscated-script, Deprecated - Potential PowerShell Obfuscated Script>> |Identifies scripts that contain patterns and known methods that obfuscate PowerShell code. Attackers can use obfuscation techniques to bypass PowerShell security protections such as Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |109
+
+|<<deprecated-powershell-script-with-discovery-capabilities, Deprecated - PowerShell Script with Discovery Capabilities>> |Identifies the use of Cmdlets and methods related to discovery activities. Attackers can use these to perform various situational awareness related activities, like enumerating users, shares, sessions, domain trusts, groups, etc. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Tactic: Discovery], [Data Source: PowerShell Logs], [Rule Type: BBR] |None |214
+
+|<<deprecated-powershell-script-with-remote-execution-capabilities-via-winrm, Deprecated - PowerShell Script with Remote Execution Capabilities via WinRM>> |Identifies the use of Cmdlets and methods related to remote execution activities using WinRM. Attackers can abuse WinRM to perform lateral movement using built-in tools. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Execution], [Data Source: PowerShell Logs], [Rule Type: BBR] |None |212
+
 |<<deprecated-sudo-heap-based-buffer-overflow-attempt, Deprecated - Sudo Heap-Based Buffer Overflow Attempt>> |Identifies the attempted use of a heap-based buffer overflow vulnerability for the Sudo binary in Unix-like systems (CVE-2021-3156). Successful exploitation allows an unprivileged user to escalate to the root user. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |108
 
-|<<detection-alert-on-a-process-exhibiting-cpu-spike, Detection Alert on a Process Exhibiting CPU Spike>> |This rule correlates security alerts with processes exhibiting unusually high CPU utilization on the same host and process ID within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Endpoint], [Tactic: Impact] |None |2
+|<<deprecated-suspicious-printspooler-service-executable-file-creation, Deprecated - Suspicious PrintSpooler Service Executable File Creation>> |Detects attempts to exploit privilege escalation vulnerabilities related to the Print Spooler service. For more information refer to the following CVE's - CVE-2020-1048, CVE-2020-1337 and CVE-2020-1300 and verify that the impacted system is patched. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |320
+
+|<<deprecated-unusual-discovery-activity-by-user, Deprecated - Unusual Discovery Activity by User>> |This rule leverages alert data from various Discovery building block rules to alert on signals with unusual unique host.id and user.id entries. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: Higher-Order Rule], [Rule Type: BBR] |None |3
+
+|<<detection-alert-on-a-process-exhibiting-cpu-spike, Detection Alert on a Process Exhibiting CPU Spike>> |This rule correlates security alerts with processes exhibiting unusually high CPU utilization on the same host and process ID within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Endpoint], [Tactic: Impact] |None |3
 
 |<<directory-creation-in-bin-directory, Directory Creation in /bin directory>> |This rule identifies the creation of directories in the /bin directory. The /bin directory contains essential binary files that are required for the system to function properly. The creation of directories in this location could be an attempt to hide malicious files or executables, as these /bin directories usually just contain binaries. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |106
 
@@ -630,7 +670,7 @@ and their rule type is `machine_learning`.
 
 |<<disable-windows-firewall-rules-via-netsh, Disable Windows Firewall Rules via Netsh>> |Identifies use of the netsh.exe to disable or weaken the local firewall. Attackers will use this command line tool to disable the firewall during troubleshooting or to enable network mobility. |[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 for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |315
 
-|<<disabling-lsa-protection-via-registry-modification, Disabling Lsa Protection via Registry Modification>> |LSA protecton is provided to prevent nonprotected processes from reading memory and injecting code. This feature provides added security for the credentials that LSA stores and manages. Adversaries may modify the RunAsPPL registry and wait or initiate a system restart to enable Lsass credentials access. |[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 for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |3
+|<<disabling-lsa-protection-via-registry-modification, Disabling Lsa Protection via Registry Modification>> |LSA protecton is provided to prevent nonprotected processes from reading memory and injecting code. This feature provides added security for the credentials that LSA stores and manages. Adversaries may modify the RunAsPPL registry and wait or initiate a system restart to enable Lsass credentials access. |[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 for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |4
 
 |<<disabling-user-account-control-via-registry-modification, Disabling User Account Control via Registry Modification>> |User Account Control (UAC) can help mitigate the impact of malware on Windows hosts. With UAC, apps and tasks always run in the security context of a non-administrator account, unless an administrator specifically authorizes administrator-level access to the system. This rule identifies registry value changes to bypass User Access Control (UAC) protection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |315
 
@@ -640,7 +680,7 @@ and their rule type is `machine_learning`.
 
 |<<discovery-of-domain-groups, Discovery of Domain Groups>> |Identifies the execution of Linux built-in commands related to account or group enumeration. Adversaries may use account and group information to orient themselves before deciding how to act. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike] |None |5
 
-|<<discovery-of-internet-capabilities-via-built-in-tools, Discovery of Internet Capabilities via Built-in Tools>> |Identifies the use of built-in tools attackers can use to check for Internet connectivity on compromised systems. These results may be used to determine communication capabilities with C2 servers, or to identify routes, redirectors, and proxy servers. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend] |None |104
+|<<discovery-of-internet-capabilities-via-built-in-tools, Discovery of Internet Capabilities via Built-in Tools>> |Identifies the use of built-in tools attackers can use to check for Internet connectivity on compromised systems. These results may be used to determine communication capabilities with C2 servers, or to identify routes, redirectors, and proxy servers. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR], [Data Source: Elastic Defend] |None |105
 
 |<<docker-release-file-creation, Docker Release File Creation>> |This rule detects the creation of files named release_agent or notify_on_release, which are commonly associated with the abuse of Linux cgroup release mechanisms. In Docker or containerized environments, this behavior may indicate an attempt to exploit privilege escalation vulnerabilities such as CVE-2022-0492, where attackers use the release_agent feature to execute code on the host from within a container. |[Domain: Endpoint], [Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |3
 
@@ -660,7 +700,7 @@ and their rule type is `machine_learning`.
 
 |<<dylib-injection-via-process-environment-variables, Dylib Injection via Process Environment Variables>> |Detects the use of process environment variables (DYLD_INSERT_LIBRARIES or LD_PRELOAD) to inject a shared library into a binary at or prior to execution. A threat actor may use this technique to load a malicious shared library for persistence, privilege escalation, and defense evasion. This activity is uncommon and typically indicates malicious behavior. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1
 
-|<<dynamic-iex-reconstruction-via-method-string-access, Dynamic IEX Reconstruction via Method String Access>> |Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command by accessing and indexing the string representation of method references. This obfuscation technique uses constructs like ''.IndexOf.ToString() to expose method metadata as a string, then extracts specific characters through indexed access and joins them to form IEX, bypassing static keyword detection and evading defenses such as AMSI. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |10
+|<<dynamic-iex-reconstruction-via-method-string-access, Dynamic IEX Reconstruction via Method String Access>> |Detects PowerShell scripts that rebuilds IEX by converting method references to strings (for example, ''.IndexOf.ToString()) and extracting multiple indexed characters (for example, [n,n,n]). Attackers use method-string reconstruction to conceal dynamic execution and bypass static detections and AMSI. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |11
 
 |<<dynamic-linker-ld-so-creation, Dynamic Linker (ld.so) Creation>> |This rule detects the creation of the dynamic linker (ld.so). The dynamic linker is used to load shared libraries needed by an executable. Attackers may attempt to replace the dynamic linker with a malicious version to execute arbitrary code. |[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 |106
 
@@ -676,11 +716,13 @@ and their rule type is `machine_learning`.
 
 |<<egress-connection-from-entrypoint-in-container, Egress Connection from Entrypoint in Container>> |This rule identifies a sequence of events where a process named "entrypoint.sh" is started in a container, followed by a network connection attempt. This sequence indicates a potential egress connection from an entrypoint in a container. An entrypoint is a command or script specified in the Dockerfile and executed when the container starts. Attackers can use this technique to establish a foothold in the environment, escape from a container to the host, or establish persistence. |[Domain: Endpoint], [Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6
 
-|<<elastic-agent-service-terminated, Elastic Agent Service Terminated>> |Identifies the Elastic endpoint agent has stopped and is no longer running on the host. Adversaries may attempt to disable security monitoring tools in an attempt to evade detection or prevention capabilities during an intrusion. This may also indicate an issue with the agent itself and should be addressed to ensure defensive measures are back in a stable state. |[Domain: Endpoint], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |111
+|<<elastic-agent-service-terminated, Elastic Agent Service Terminated>> |Identifies the Elastic endpoint agent has stopped and is no longer running on the host. Adversaries may attempt to disable security monitoring tools in an attempt to evade detection or prevention capabilities during an intrusion. This may also indicate an issue with the agent itself and should be addressed to ensure defensive measures are back in a stable state. |[Domain: Endpoint], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |112
+
+|<<elastic-defend-alert-followed-by-telemetry-loss, Elastic Defend Alert Followed by Telemetry Loss>> |Detects when an Elastic Defend endpoint alert is generated on a host and is not followed by any subsequent endpoint telemetry (process, network, registry, library, or DNS events) within a short time window. This behavior may indicate endpoint security evasion, agent tampering, sensor disablement, service termination, system crash, or malicious interference with telemetry collection following detection. |[Domain: Endpoint], [Data Source: Elastic Defend], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |1
 
 |<<elastic-defend-and-email-alerts-correlation, Elastic Defend and Email Alerts Correlation>> |This rule correlates any Elastic Defend alert with an email security related alert by target user name. This may indicate the successful execution of a phishing attack. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Check Point Harmony Email & Collaboration], [Domain: Email], [Domain: Endpoint] |None |3
 
-|<<elastic-defend-and-network-security-alerts-correlation, Elastic Defend and Network Security Alerts Correlation>> |This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto Networks (PANW) and Fortinet Fortigate by host.ip and source.ip. This may indicate that this host is compromised and triggering multi-datasource alerts. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Fortinet], [Data Source: PAN-OS] |None |5
+|<<elastic-defend-and-network-security-alerts-correlation, Elastic Defend and Network Security Alerts Correlation>> |This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto Networks (PANW) and Fortinet Fortigate by host.ip and source.ip. This may indicate that this host is compromised and triggering multi-datasource alerts. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Fortinet], [Data Source: PAN-OS] |None |6
 
 |<<elastic-security-external-alerts, Elastic Security External Alerts>> |Generates a detection alert for each Elastic Security alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Elastic Security alerts in the app. |[Data Source: Elastic Security], [Use Case: Threat Detection], [Resources: Investigation Guide], [Promotion: External Alerts] |None |2
 
@@ -688,15 +730,13 @@ and their rule type is `machine_learning`.
 
 |<<enable-host-network-discovery-via-netsh, Enable Host Network Discovery via Netsh>> |Identifies use of the netsh.exe program to enable host discovery via the network. Attackers can use this command-line tool to weaken the host firewall settings. |[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 for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |314
 
-|<<encoded-executable-stored-in-the-registry, Encoded Executable Stored in the Registry>> |Identifies registry write modifications to hide an encoded portable executable. This could be indicative of adversary defense evasion by avoiding the storing of malicious content directly on disk. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender for Endpoint], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |415
-
 |<<encrypting-files-with-winrar-or-7z, Encrypting Files with WinRar or 7z>> |Identifies the use of WinRAR or 7-Zip to create encrypted archives. Adversaries often compress and encrypt data in preparation for exfiltration. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne] |None |218
 
 |<<endpoint-security-elastic-defend, Endpoint Security (Elastic Defend)>> |Generates a detection alert each time an Elastic Defend alert is received. Enabling this rule allows you to immediately begin investigating your Endpoint alerts. |[Data Source: Elastic Defend], [Resources: Investigation Guide] |None |108
 
 |<<entra-id-adrs-token-request-by-microsoft-authentication-broker, Entra ID ADRS Token Request by Microsoft Authentication Broker>> |Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session. |[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: Persistence], [Resources: Investigation Guide] |None |2
 
-|<<entra-id-actor-token-user-impersonation-abuse, Entra ID Actor Token User Impersonation Abuse>> |Identifies potential abuse of actor tokens in Microsoft Entra ID audit logs. Actor tokens are undocumented backend mechanisms used by Microsoft for service-to-service (S2S) operations, allowing services to perform actions on behalf of users. These tokens appear in logs with the service's display name but the impersonated user's UPN. While some legitimate Microsoft operations use actor tokens, unexpected usage may indicate exploitation of CVE-2025-55241, which allowed unauthorized access to Azure AD Graph API across tenants before being patched by Microsoft. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |4
+|<<entra-id-actor-token-user-impersonation-abuse, Entra ID Actor Token User Impersonation Abuse>> |Identifies potential abuse of actor tokens in Microsoft Entra ID audit logs. Actor tokens are undocumented backend mechanisms used by Microsoft for service-to-service (S2S) operations, allowing services to perform actions on behalf of users. These tokens appear in logs with the service's display name but the impersonated user's UPN. While some legitimate Microsoft operations use actor tokens, unexpected usage may indicate exploitation of CVE-2025-55241, which allowed unauthorized access to Azure AD Graph API across tenants before being patched by Microsoft. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |5
 
 |<<entra-id-application-credential-modified, Entra ID Application Credential Modified>> |Identifies when a new credential is added to an application in Azure. An application may use a certificate or secret string to prove its identity when requesting a token. Multiple certificates and secrets can be added for an application and an adversary may abuse this by creating an additional authentication method to evade defenses or persist in an environment. |[Domain: Cloud], [Data Source: Azure], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |107
 
@@ -704,14 +744,14 @@ and their rule type is `machine_learning`.
 
 |<<entra-id-conditional-access-policy-cap-modified, Entra ID Conditional Access Policy (CAP) Modified>> |Identifies a modification to a conditional access policy (CAP) in Microsoft Entra ID. Adversaries may modify existing CAPs to loosen access controls and maintain persistence in the environment with a compromised identity or entity. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |108
 
-|<<entra-id-device-registration-detected-roadtools, Entra ID Device Registration Detected (ROADtools)>> |Detects a sequence of events in Microsoft Entra ID indicative of a suspicious cloud-based device registration, potentially using ROADtools. This behavior involves adding a device via the Device Registration Service, followed by the assignment of registered users and owners — a pattern consistent with techniques used to establish persistence or acquire a Primary Refresh Token (PRT). ROADtools, a popular red team toolkit, often leaves distinct telemetry signatures such as the `Microsoft.OData.Client` user agent and specific OS version values. These sequences are uncommon in typical user behavior and may reflect abuse of device trust for session hijacking or silent token replay. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |2
-
 |<<entra-id-elevated-access-to-user-access-administrator, Entra ID Elevated Access to User Access Administrator>> |Identifies when a user has elevated their access to User Access Administrator for their Azure Resources. The User Access Administrator role allows users to manage user access to Azure resources, including the ability to assign roles and permissions. Adversaries may target an Entra ID Global Administrator or other privileged role to elevate their access to User Access Administrator, which can lead to further privilege escalation and unauthorized access to sensitive resources. This is a New Terms rule that only signals if the user principal name has not been seen doing this activity in the last 14 days. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |3
 
 |<<entra-id-external-authentication-methods-eam-modified, Entra ID External Authentication Methods (EAM) Modified>> |Identifies when an external authentication method (EAM) is added or modified in Entra ID. EAM may allow adversaries to bypass multi-factor authentication (MFA) requirements, potentially leading to unauthorized access to user accounts and sensitive resources by using bring-your-own IdP (BYOIDP) methods. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Graph], [Data Source: Microsoft Graph Activity Logs], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Persistence] |None |2
 
 |<<entra-id-external-guest-user-invited, Entra ID External Guest User Invited>> |Identifies an invitation to an external user in Azure Active Directory (AD). Azure AD is extended to include collaboration, allowing you to invite people from outside your organization to be guest users in your cloud account. Unless there is a business need to provision guest access, it is best practice avoid creating guest users. Guest users could potentially be overlooked indefinitely leading to a potential vulnerability. |[Domain: Cloud], [Data Source: Azure], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |107
 
+|<<entra-id-federated-identity-credential-issuer-modified, Entra ID Federated Identity Credential Issuer Modified>> |Detects when the issuer URL of a federated identity credential is changed on an Entra ID application. Adversaries may modify the issuer to point to an attacker-controlled identity provider, enabling them to authenticate as the application's service principal and gain persistent access to Azure resources. This technique allows bypassing traditional authentication controls by federating trust with a malicious external identity provider. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |8
+
 |<<entra-id-global-administrator-role-assigned, Entra ID Global Administrator Role Assigned>> |In Microsoft Entra ID, permissions to manage resources are assigned using roles. The Global Administrator is a role that enables users to have access to all administrative features in Microsoft Entra ID and services that use Microsoft Entra ID identities like the Microsoft 365 Defender portal, the Microsoft 365 compliance center, Exchange, SharePoint Online, and Skype for Business Online. Attackers can add users as Global Administrators to maintain access and manage all subscriptions and their settings and resources. They can also elevate privilege to User Access Administrator to pivot into Azure resources. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |106
 
 |<<entra-id-global-administrator-role-assigned-pim-user, Entra ID Global Administrator Role Assigned (PIM User)>> |Identifies an Azure Active Directory (AD) Global Administrator role addition to a Privileged Identity Management (PIM) user account. PIM is a service that enables you to manage, control, and monitor access to important resources in an organization. Users who are assigned to the Global administrator role can read and modify any administrative setting in your Azure AD organization. |[Domain: Cloud], [Data Source: Azure], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |107
@@ -746,8 +786,6 @@ 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 |4
 
-|<<entra-id-oidc-discovery-url-modified, Entra ID OIDC Discovery URL Modified>> |Detects a change to the OpenID Connect (OIDC) discovery URL in the Entra ID Authentication Methods Policy. This behavior may indicate an attempt to federate Entra ID with an attacker-controlled identity provider, enabling bypass of multi-factor authentication (MFA) and unauthorized access through bring-your-own IdP (BYOIDP) methods. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |7
-
 |<<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 |109
 
 |<<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 |109
@@ -768,7 +806,9 @@ and their rule type is `machine_learning`.
 
 |<<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 |108
 
-|<<entra-id-sharepoint-accessed-by-unusual-user-and-microsoft-authentication-broker-client, Entra ID SharePoint Accessed by Unusual User and Microsoft Authentication Broker Client>> |This rule detects non-interactive authentication activity against SharePoint Online (`Office 365 SharePoint Online`) by a user principal via the `Microsoft Authentication Broker` application. The session leverages a refresh token or Primary Refresh Token (PRT) without interactive sign-in, often used in OAuth phishing or token replay scenarios. |[Domain: Cloud], [Use Case: Identity and Access Audit], [Tactic: Collection], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Resources: Investigation Guide] |None |3
+|<<entra-id-service-principal-federated-credential-authentication-by-unusual-client, Entra ID Service Principal Federated Credential Authentication by Unusual Client>> |Identifies when a service principal authenticates using a federated identity credential for the first time in the historical window. This indicates that Entra ID validated a JWT token potentially against an external OIDC identity provider and issued an access token. While legitimate for CI/CD workflows (GitHub Actions, Azure DevOps), adversaries may abuse this by configuring rogue identity providers (BYOIDP) to authenticate as compromised applications. First-time federated credential usage for a service principal warrants investigation to determine if the external identity provider is legitimate. |[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], [Tactic: Defense Evasion], [Tactic: Persistence], [Resources: Investigation Guide] |None |1
+
+|<<entra-id-sharepoint-or-onedrive-accessed-by-unusual-client, Entra ID Sharepoint or OneDrive Accessed by Unusual Client>> |Identifies when an application accesses SharePoint Online or OneDrive for Business for the first time in the tenant within a specified timeframe. This detects successful OAuth phishing campaigns, illicit consent grants, or compromised third-party applications gaining initial access to file storage. Adversaries often use malicious OAuth applications or phishing techniques to gain consent from users, allowing persistent access to organizational data repositories without traditional credential theft. |[Domain: Cloud], [Domain: Identity], [Domain: Storage], [Use Case: Identity and Access Audit], [Tactic: Collection], [Tactic: Initial Access], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Resources: Investigation Guide] |None |4
 
 |<<entra-id-sign-in-bloodhound-suite-user-agent-detected, Entra ID Sign-in BloodHound Suite User-Agent Detected>> |Identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services. These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access relationships within Microsoft Entra ID (Azure AD) and Microsoft 365. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure Activity Logs], [Data Source: Graph API], [Data Source: Graph API Activity Logs], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |2
 
@@ -776,6 +816,8 @@ and their rule type is `machine_learning`.
 
 |<<entra-id-sign-in-teamfiltration-user-agent-detected, Entra ID Sign-in TeamFiltration User-Agent Detected>> |Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |2
 
+|<<entra-id-unusual-cloud-device-registration, Entra ID Unusual Cloud Device Registration>> |Detects a sequence of events in Microsoft Entra ID indicative of suspicious cloud-based device registration via automated tooling like ROADtools or similar frameworks. This behavior involves adding a device via the Device Registration Service, followed by the assignment of registered users and owners — a pattern consistent with techniques used to establish persistence or acquire a Primary Refresh Token (PRT). ROADtools and similar tooling leave distinct telemetry signatures such as the `Microsoft.OData.Client` user agent. These sequences are uncommon in typical user behavior and may reflect abuse of device trust for session hijacking or silent token replay. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Audit Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |3
+
 |<<entra-id-user-added-as-registered-application-owner, Entra ID User Added as Registered Application Owner>> |Identifies when a user is added as an owner for an Azure application. An adversary may add a user account as an owner for an Azure application in order to grant additional permissions and modify the application's configuration using another account. |[Domain: Cloud], [Data Source: Azure], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |107
 
 |<<entra-id-user-added-as-service-principal-owner, Entra ID User Added as Service Principal Owner>> |Identifies when a user is added as an owner for an Azure service principal. The service principal object defines what the application can do in the specific tenant, who can access the application, and what resources the app can access. A service principal object is created when an application is given permission to access resources in a tenant. An adversary may add a user account as an owner for a service principal and use that account in order to define what an application can do in the Azure AD tenant. |[Domain: Cloud], [Data Source: Azure], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |107
@@ -830,7 +872,7 @@ and their rule type is `machine_learning`.
 
 |<<execution-of-a-downloaded-windows-script, Execution of a Downloaded Windows Script>> |Identifies the creation of a Windows script downloaded from the internet followed by the execution of a scripting utility. Adversaries may use Windows script files for initial access and execution. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |5
 
-|<<execution-of-an-unsigned-service, Execution of an Unsigned Service>> |This rule identifies the execution of unsigned executables via service control manager (SCM). Adversaries may abuse SCM to execute malware or escalate privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Defense Evasion], [Rule Type: BBR], [Data Source: Elastic Defend] |None |107
+|<<execution-of-an-unsigned-service, Execution of an Unsigned Service>> |This rule identifies the execution of unsigned executables via service control manager (SCM). Adversaries may abuse SCM to execute malware or escalate privileges. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Defense Evasion], [Rule Type: BBR], [Data Source: Elastic Defend] |None |108
 
 |<<execution-via-electron-child-process-node-js-module, Execution via Electron Child Process Node.js Module>> |Identifies attempts to execute a child process from within the context of an Electron application using the child_process Node.js module. Adversaries may abuse this technique to inherit permissions from parent processes. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |110
 
@@ -848,7 +890,7 @@ and their rule type is `machine_learning`.
 
 |<<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 for Endpoint], [Data Source: Crowdstrike], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |108
 
-|<<execution-via-windows-subsystem-for-linux, Execution via Windows Subsystem for Linux>> |Detects attempts to execute a program on the host from 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: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide], [Data Source: Sysmon] |None |213
+|<<execution-via-windows-subsystem-for-linux, Execution via Windows Subsystem for Linux>> |Detects attempts to execute a program on the host from 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: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide], [Data Source: Sysmon] |None |214
 
 |<<execution-via-local-sxs-shared-module, Execution via local SxS Shared Module>> |Identifies the creation, change, or deletion of a DLL module within a Windows SxS local folder. Adversaries may abuse shared modules to execute malicious payloads by instructing the Windows module loader to load DLLs from arbitrary local paths. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |312
 
@@ -872,8 +914,6 @@ and their rule type is `machine_learning`.
 
 |<<file-compressed-or-archived-into-common-format-by-unsigned-process, File Compressed or Archived into Common Format by Unsigned Process>> |Detects files being compressed or archived into common formats by unsigned processes. This is a common technique used to obfuscate files to evade detection or to staging data for exfiltration. |[Data Source: Elastic Defend], [Domain: Endpoint], [OS: macOS], [OS: Windows], [Tactic: Collection], [Rule Type: BBR] |None |6
 
-|<<file-creation-time-changed, File Creation Time Changed>> |Identifies modification of a file creation time. Adversaries may modify file time attributes to blend malicious content with existing files. Timestomping is a technique that modifies the timestamps of a file often to mimic files that are in trusted directories. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Sysmon], [Resources: Investigation Guide] |None |109
-
 |<<file-creation-by-cups-or-foomatic-rip-child, File Creation by Cups or Foomatic-rip Child>> |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 file creation events executed by child processes of foomatic-rip. 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: SentinelOne], [Resources: Investigation Guide] |None |106
 
 |<<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 |4
@@ -952,6 +992,10 @@ and their rule type is `machine_learning`.
 
 |<<fortigate-overly-permissive-firewall-policy-created, FortiGate Overly Permissive Firewall Policy Created>> |This rule detects the creation or modification of a FortiGate firewall policy that permits all sources, all destinations, and all services. An overly permissive policy effectively bypasses all firewall protections. Threat actors exploiting CVE-2026-24858 have been observed creating such policies to allow unrestricted traffic flow through compromised FortiGate devices. |[Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Domain: Network], [Data Source: Fortinet], [Data Source: Fortinet FortiGate] |None |1
 
+|<<fortigate-socks-traffic-from-an-unusual-process, FortiGate SOCKS Traffic from an Unusual Process>> |This detection correlates FortiGate's application control SOCKS events with Elastic Defend network event to identify the source process performing SOCKS traffic. Adversaries may use a connection proxy to direct network traffic between systems or act as an intermediary for network communications to a command and control server to avoid direct connections to their infrastructure. |[Domain: Endpoint], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Fortinet], [Resources: Investigation Guide] |None |2
+
+|<<fortigate-ssl-vpn-login-followed-by-siem-alert-by-user, FortiGate SSL VPN Login Followed by SIEM Alert by User>> |Detects when a FortiGate SSL VPN login event is followed by any SIEM detection alert for the same user name within a short time window. This correlation can indicate abuse of VPN access for malicious activity, credential compromise used from a VPN session, or initial access via VPN followed by post-compromise behavior. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Tactic: Initial Access], [Data Source: Fortinet], [Resources: Investigation Guide] |None |1
+
 |<<fortigate-sso-login-followed-by-administrator-account-creation, FortiGate SSO Login Followed by Administrator Account Creation>> |This rule detects a FortiCloud SSO login followed by administrator account creation on the same FortiGate device within 15 minutes. This sequence is a high-confidence indicator of the FG-IR-26-060 attack pattern, where threat actors authenticate via SAML-based SSO bypass and immediately create local administrator accounts for persistence. |[Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Domain: Network], [Domain: Identity], [Data Source: Fortinet], [Data Source: Fortinet FortiGate] |None |1
 
 |<<fortigate-super-admin-account-creation, FortiGate Super Admin Account Creation>> |This rule detects the creation of an administrator account on a FortiGate device. Administrator account creation on these devices should be infrequent and tightly controlled. In the FG-IR-26-060 campaign, threat actors created super_admin accounts immediately after gaining initial access via FortiCloud SSO bypass to establish persistence. |[Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Domain: Network], [Domain: Identity], [Data Source: Fortinet], [Data Source: Fortinet FortiGate] |None |1
@@ -1114,9 +1158,9 @@ and their rule type is `machine_learning`.
 
 |<<high-command-line-entropy-detected-for-privileged-commands, High Command Line Entropy Detected for Privileged Commands>> |A machine learning job has identified an unusually high median command line entropy for privileged commands executed by a user, suggesting possible privileged access activity through command lines. High entropy often indicates that the commands may be obfuscated or deliberately complex, which can be a sign of suspicious or unauthorized use of privileged access. |[Use Case: Privileged Access Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |3
 
-|<<high-mean-of-process-arguments-in-an-rdp-session, High Mean of Process Arguments in an RDP Session>> |A machine learning job has detected unusually high number of process arguments in an RDP session. Executing sophisticated attacks such as lateral movement can involve the use of complex commands, obfuscation mechanisms, redirection and piping, which in turn increases the number of arguments in a command. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |7
+|<<high-mean-of-process-arguments-in-an-rdp-session, High Mean of Process Arguments in an RDP Session>> |A machine learning job has detected unusually high number of process arguments in an RDP session. Executing sophisticated attacks such as lateral movement can involve the use of complex commands, obfuscation mechanisms, redirection and piping, which in turn increases the number of arguments in a command. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |8
 
-|<<high-mean-of-rdp-session-duration, High Mean of RDP Session Duration>> |A machine learning job has detected unusually high mean of RDP session duration. Long RDP sessions can be used to evade detection mechanisms via session persistence, and might be used to perform tasks such as lateral movement, that might require uninterrupted access to a compromised machine. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |7
+|<<high-mean-of-rdp-session-duration, High Mean of RDP Session Duration>> |A machine learning job has detected unusually high mean of RDP session duration. Long RDP sessions can be used to evade detection mechanisms via session persistence, and might be used to perform tasks such as lateral movement, that might require uninterrupted access to a compromised machine. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |8
 
 |<<high-number-of-cloned-github-repos-from-pat, High Number of Cloned GitHub Repos From PAT>> |Detects a high number of unique private repo clone events originating from a single personal access token within a short time period. |[Domain: Cloud], [Use Case: Threat Detection], [Use Case: UEBA], [Tactic: Execution], [Data Source: Github], [Resources: Investigation Guide] |None |207
 
@@ -1124,8 +1168,6 @@ and their rule type is `machine_learning`.
 
 |<<high-number-of-egress-network-connections-from-unusual-executable, High Number of Egress Network Connections from Unusual Executable>> |This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other malicious activity. 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: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |10
 
-|<<high-number-of-okta-device-token-cookies-generated-for-authentication, High Number of Okta Device Token Cookies Generated for Authentication>> |Detects when an Okta client address has a certain threshold of Okta user authentication events with multiple device token hashes generated for single user authentication. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |209
-
 |<<high-number-of-okta-user-password-reset-or-unlock-attempts, High Number of Okta User Password Reset or Unlock Attempts>> |Identifies a high number of Okta user password reset or account unlock attempts. An adversary may attempt to obtain unauthorized access to Okta user accounts using these methods and attempt to blend in with normal activity in their target's environment and evade detection. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |415
 
 |<<high-number-of-process-terminations, High Number of Process Terminations>> |This rule identifies a high number (10) of process terminations via pkill from the same host within a short time period. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike] |None |116
@@ -1134,7 +1176,7 @@ and their rule type is `machine_learning`.
 
 |<<high-number-of-protected-branch-force-pushes-by-user, High Number of Protected Branch Force Pushes by User>> |Detects a high number of force push actions to protected branches by a single user within a short time frame. Adversaries may perform force pushes to overwrite commit history on protected branches, potentially leading to data loss or disruption of development workflows. |[Domain: Cloud], [Use Case: Threat Detection], [Tactic: Impact], [Tactic: Exfiltration], [Data Source: Github], [Resources: Investigation Guide] |None |2
 
-|<<high-variance-in-rdp-session-duration, High Variance in RDP Session Duration>> |A machine learning job has detected unusually high variance of RDP session duration. Long RDP sessions can be used to evade detection mechanisms via session persistence, and might be used to perform tasks such as lateral movement, that might require uninterrupted access to a compromised machine. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |7
+|<<high-variance-in-rdp-session-duration, High Variance in RDP Session Duration>> |A machine learning job has detected unusually high variance of RDP session duration. Long RDP sessions can be used to evade detection mechanisms via session persistence, and might be used to perform tasks such as lateral movement, that might require uninterrupted access to a compromised machine. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |8
 
 |<<host-detected-with-suspicious-windows-process-es, Host Detected with Suspicious Windows Process(es)>> |A machine learning job combination has identified a host with one or more suspicious Windows processes that exhibit unusually high malicious probability scores.These process(es) have been classified as malicious in several ways. The process(es) were predicted to be malicious by the ProblemChild supervised ML model. If the anomaly contains a cluster of suspicious processes, each process has the same host name, and the aggregate score of the event cluster was calculated to be unusually high by an unsupervised ML model. Such a cluster often contains suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules. |[Use Case: Living off the Land Attack Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |110
 
@@ -1210,9 +1252,13 @@ and their rule type is `machine_learning`.
 
 |<<kernel-driver-load-by-non-root-user, Kernel Driver Load by non-root User>> |Detects the loading of a Linux kernel module by a non-root user through system calls. Threat actors may leverage Linux kernel modules to load a rootkit on a system providing them with complete control and the ability to hide from security products. As other rules monitor for the addition of Linux kernel modules through system utilities or .ko files, this rule covers the gap that evasive rootkits leverage by monitoring for kernel module additions on the lowest level through auditd_manager. |[Data Source: Auditd Manager], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |7
 
+|<<kernel-instrumentation-discovery-via-kprobes-and-tracefs, Kernel Instrumentation Discovery via kprobes and tracefs>> |Detects common utilities accessing kprobes and tracing-related paths in debugfs/tracefs, which may indicate discovery of kernel instrumentation hooks. Adversaries can enumerate these locations to understand or prepare for eBPF, kprobe, or tracepoint-based activity. This behavior can also be benign during troubleshooting, performance analysis, or observability tooling validation. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |1
+
 |<<kernel-load-or-unload-via-kexec-detected, Kernel Load or Unload via Kexec Detected>> |This detection rule identifies the usage of kexec, helping to uncover unauthorized kernel replacements and potential compromise of the system's integrity. Kexec is a Linux feature that enables the loading and execution of a different kernel without going through the typical boot process. Malicious actors can abuse kexec to bypass security measures, escalate privileges, establish persistence or hide their activities by loading a malicious kernel, enabling them to tamper with the system's trusted state, allowing e.g. a VM Escape. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |112
 
-|<<kernel-module-load-via-insmod, Kernel Module Load via insmod>> |Detects the use of the insmod binary to load a Linux kernel object file. Threat actors can use this binary, given they have root privileges, to load a rootkit on a system providing them with complete control and the ability to hide from security products. Manually loading a kernel module in this manner should not be at all common and can indicate suspcious or malicious behavior. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Threat: Rootkit], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |215
+|<<kernel-module-load-from-unusual-location, Kernel Module Load from Unusual Location>> |This rule detects the loading of a kernel module from an unusual location. Threat actors may use this technique to maintain persistence on a system by loading a kernel module into the kernel namespace. This behavior is strongly related to the presence of a rootkit on the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Threat: Rootkit], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1
+
+|<<kernel-module-load-via-built-in-utility, Kernel Module Load via Built-in Utility>> |Detects the use of the insmod binary to load a Linux kernel object file. Threat actors can use this binary, given they have root privileges, to load a rootkit on a system providing them with complete control and the ability to hide from security products. Manually loading a kernel module in this manner should not be at all common and can indicate suspicious or malicious behavior. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Threat: Rootkit], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |216
 
 |<<kernel-module-removal, Kernel Module Removal>> |Kernel modules are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system. This rule identifies attempts to remove a kernel module. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |215
 
@@ -1304,9 +1350,9 @@ and their rule type is `machine_learning`.
 
 |<<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 for Endpoint], [Resources: Investigation Guide] |None |16
 
-|<<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 |2
+|<<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 |2
+|<<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 for Endpoint], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |312
 
@@ -1354,8 +1400,6 @@ and their rule type is `machine_learning`.
 
 |<<m365-exchange-dkim-signing-configuration-disabled, M365 Exchange DKIM Signing Configuration Disabled>> |Identifies when a DomainKeys Identified Mail (DKIM) signing configuration is disabled in Microsoft 365. With DKIM in Microsoft 365, messages that are sent from Exchange Online will be cryptographically signed. This will allow the receiving email system to validate that the messages were generated by a server that the organization authorized and were not spoofed. |[Domain: Cloud], [Data Source: Microsoft 365], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |211
 
-|<<m365-exchange-dlp-policy-deleted, M365 Exchange DLP Policy Deleted>> |Identifies when a Data Loss Prevention (DLP) policy is removed in Microsoft 365. An adversary may remove a DLP policy to evade existing DLP monitoring. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |211
-
 |<<m365-exchange-email-safe-attachment-rule-disabled, M365 Exchange Email Safe Attachment Rule Disabled>> |Identifies when a safe attachment rule is disabled in Microsoft 365. Safe attachment rules can extend malware protections to include routing all messages and attachments without a known malware signature to a special hypervisor environment. An adversary or insider threat may disable a safe attachment rule to exfiltrate data or evade defenses. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |211
 
 |<<m365-exchange-email-safe-link-policy-disabled, M365 Exchange Email Safe Link Policy Disabled>> |Identifies when a Safe Link policy is disabled in Microsoft 365. Safe Link policies for Office applications extend phishing protection to documents that contain hyperlinks, even after they have been delivered to a user. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Identity and Access Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |211
@@ -1384,8 +1428,6 @@ and their rule type is `machine_learning`.
 
 |<<m365-exchange-management-group-role-assigned, M365 Exchange Management Group Role Assigned>> |Identifies when a new role is assigned to a management group in Microsoft 365. An adversary may attempt to add a role in order to maintain persistence in an environment. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |211
 
-|<<m365-identity-excessive-sso-login-errors-reported, M365 Identity Excessive SSO Login Errors Reported>> |Identifies accounts with a high number of single sign-on (SSO) logon errors. Excessive logon errors may indicate an attempt to brute force a password or SSO token. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |212
-
 |<<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 |213
 
 |<<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 |8
@@ -1400,6 +1442,8 @@ and their rule type is `machine_learning`.
 
 |<<m365-identity-oauth-phishing-via-first-party-microsoft-application, M365 Identity OAuth Phishing via First-Party Microsoft Application>> |Detects potentially suspicious OAuth authorization activity in Microsoft 365 where first-party Microsoft applications from the FOCI (Family of Client IDs) group request access to Microsoft Graph or legacy Azure AD resources. Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing these resources are flagged, as they are commonly abused in phishing campaigns like ConsentFix. Additionally, any FOCI family application accessing the deprecated Windows Azure Active Directory resource is flagged since this API is rarely used legitimately and attackers target it for stealth. First-party apps are trusted by default in all tenants and cannot be blocked, making them ideal for OAuth phishing attacks. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Initial Access] |None |3
 
+|<<m365-identity-unusual-sso-authentication-errors-for-user, M365 Identity Unusual SSO Authentication Errors for User>> |Identifies the first occurrence of SSO, SAML, or federated authentication errors for a user. These errors may indicate token manipulation, SAML assertion tampering, or OAuth phishing attempts. Modern adversaries often target SSO mechanisms through token theft, SAML response manipulation, or exploiting federated authentication weaknesses rather than traditional brute force attacks. |[Domain: Identity], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |213
+
 |<<m365-identity-user-account-lockouts, M365 Identity User Account Lockouts>> |Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Resources: Investigation Guide] |None |7
 
 |<<m365-identity-user-brute-force-attempted, M365 Identity User Brute Force Attempted>> |Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |417
@@ -1408,22 +1452,10 @@ and their rule type is `machine_learning`.
 
 |<<m365-onedrive-malware-file-upload, M365 OneDrive Malware File Upload>> |Identifies the occurence of files uploaded to OneDrive being detected as Malware by the file scanning engine. Attackers can use File Sharing and Organization Repositories to spread laterally within the company and amplify their access. Users can inadvertently share these files without knowing their maliciousness, giving adversaries opportunity to gain initial access to other endpoints in the environment. |[Domain: Cloud], [Data Source: Microsoft 365], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |211
 
-|<<m365-security-compliance-email-reported-by-user-as-malware-or-phish, M365 Security Compliance Email Reported by User as Malware or Phish>> |Detects the occurrence of emails reported as Phishing or Malware by Users. Security Awareness training is essential to stay ahead of scammers and threat actors, as security products can be bypassed, and the user can still receive a malicious message. Educating users to report suspicious messages can help identify gaps in security controls and prevent malware infections and Business Email Compromise attacks. |[Domain: Cloud], [Data Source: Microsoft 365], [Tactic: Initial Access], [Resources: Investigation Guide] |None |211
-
-|<<m365-security-compliance-potential-ransomware-activity, M365 Security Compliance Potential Ransomware Activity>> |Identifies when Microsoft Cloud App Security flags potential ransomware activity in Microsoft 365. This rule detects events where the Security Compliance Center reports a "Ransomware activity" or "Potential ransomware activity" alert, which may indicate file encryption, mass file modifications, or uploads of ransomware-infected files to cloud services such as SharePoint or OneDrive. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |212
-
-|<<m365-security-compliance-unusual-volume-of-file-deletion, M365 Security Compliance Unusual Volume of File Deletion>> |Identifies that a user has deleted an unusually large volume of files as reported by Microsoft Cloud App Security. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Impact], [Resources: Investigation Guide] |None |211
-
-|<<m365-security-compliance-user-restricted-from-sending-email, M365 Security Compliance User Restricted from Sending Email>> |Identifies when a user has been restricted from sending email due to exceeding sending limits of the service policies per the Security Compliance Center. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Impact], [Resources: Investigation Guide] |None |211
-
 |<<m365-sharepoint-malware-file-detected, M365 SharePoint Malware File Detected>> |Identifies the occurence of files uploaded to SharePoint being detected as Malware by the file scanning engine. Attackers can use File Sharing and Organization Repositories to spread laterally within the company and amplify their access. Users can inadvertently share these files without knowing their maliciousness, giving adversaries opportunities to gain initial access to other endpoints in the environment. |[Domain: Cloud], [Data Source: Microsoft 365], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |211
 
 |<<m365-teams-custom-application-interaction-enabled, M365 Teams Custom Application Interaction Enabled>> |Identifies when custom applications are allowed in Microsoft Teams. If an organization requires applications other than those available in the Teams app store, custom applications can be developed as packages and uploaded. An adversary may abuse this behavior to establish persistence in an environment. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |212
 
-|<<m365-teams-external-access-enabled, M365 Teams External Access Enabled>> |Identifies when external access is enabled in Microsoft Teams. External access lets Teams and Skype for Business users communicate with other users that are outside their organization. An adversary may enable external access or add an allowed domain to exfiltrate data or maintain persistence in an environment. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |211
-
-|<<m365-teams-guest-access-enabled, M365 Teams Guest Access Enabled>> |Identifies when guest access is enabled in Microsoft Teams. Guest access in Teams allows people outside the organization to access teams and channels. An adversary may enable guest access to maintain persistence in an environment. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |211
-
 |<<m365-threat-intelligence-signal, M365 Threat Intelligence Signal>> |Identifies a Microsoft 365 audit log generated for Threat Intelligence signals by Microsoft Defender for Office 365. Signals generated may relate to services such as Exchange Online, SharePoint Online, OneDrive for Business and others. |[Domain: Cloud], [Domain: SaaS], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Data Source: Microsoft Defender], [Data Source: Microsoft Defender Threat Intelligence], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide], [Rule Type: BBR] |None |2
 
 |<<m365-or-entra-id-identity-sign-in-from-a-suspicious-source, M365 or Entra ID Identity Sign-in from a Suspicious Source>> |This rule correlate Entra-ID or Microsoft 365 mail successful sign-in events with network security alerts by source address. Adversaries may trigger some network security alerts such as reputation or other anomalies before accessing cloud resources. |[Domain: Cloud], [Domain: SaaS], [Data Source: Azure], [Data Source: Entra ID], [Data Source: Entra ID Sign-in Logs], [Data Source: Microsoft 365], [Data Source: Microsoft 365 Audit Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide], [Rule Type: Higher-Order Rule] |None |6
@@ -1490,8 +1522,6 @@ 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 for Endpoint], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |311
 
-|<<microsoft-exchange-transport-agent-install-script, Microsoft Exchange Transport Agent Install Script>> |Identifies the use of Cmdlets and methods related to Microsoft Exchange Transport Agents install. Adversaries may leverage malicious Microsoft Exchange Transport Agents to execute tasks in response to adversary-defined criteria, establishing persistence. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: PowerShell Logs], [Rule Type: BBR] |None |109
-
 |<<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 for Endpoint], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |313
 
 |<<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], [Data Source: Azure], [Data Source: Microsoft Graph], [Data Source: Microsoft Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide] |None |3
@@ -1540,13 +1570,13 @@ and their rule type is `machine_learning`.
 
 |<<multi-base64-decoding-attempt-from-suspicious-location, Multi-Base64 Decoding Attempt from Suspicious Location>> |This rule detects the execution of multiple base64 decoding commands to decode data. multi-decoded data is suspicious, and may be used by attackers to obfuscate malicious payloads or commands. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2
 
-|<<multiple-alerts-involving-a-user, Multiple Alerts Involving a User>> |This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |6
+|<<multiple-alerts-involving-a-user, Multiple Alerts Involving a User>> |This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |7
 
 |<<multiple-alerts-in-different-att-ck-tactics-on-a-single-host, Multiple Alerts in Different ATT&CK Tactics on a Single Host>> |This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |6
 
-|<<multiple-alerts-in-same-att-ck-tactic-by-host, Multiple Alerts in Same ATT&CK Tactic by Host>> |This rule correlates multiple security alerts associated with the same ATT&CK tactic on a single host within a defined time window. By requiring alerts from multiple distinct detection rules, this detection helps identify hosts exhibiting concentrated malicious behavior, which may indicate an active intrusion or post-compromise activity. The rule is intended to assist analysts in prioritizing triage toward hosts with higher likelihood of compromise rather than signaling a single discrete event. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |2
+|<<multiple-alerts-in-same-att-ck-tactic-by-host, Multiple Alerts in Same ATT&CK Tactic by Host>> |This rule correlates multiple security alerts associated with the same ATT&CK tactic on a single host within a defined time window. By requiring alerts from multiple distinct detection rules, this detection helps identify hosts exhibiting concentrated malicious behavior, which may indicate an active intrusion or post-compromise activity. The rule is intended to assist analysts in prioritizing triage toward hosts with higher likelihood of compromise rather than signaling a single discrete event. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |3
 
-|<<multiple-alerts-on-a-host-exhibiting-cpu-spike, Multiple Alerts on a Host Exhibiting CPU Spike>> |This rule correlates multiple security alerts from a host exhibiting unusually high CPU utilization within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Endpoint], [Tactic: Impact] |None |2
+|<<multiple-alerts-on-a-host-exhibiting-cpu-spike, Multiple Alerts on a Host Exhibiting CPU Spike>> |This rule correlates multiple security alerts from a host exhibiting unusually high CPU utilization within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Endpoint], [Tactic: Impact] |None |3
 
 |<<multiple-cloud-secrets-accessed-by-source-address, Multiple Cloud Secrets Accessed by Source Address>> |This rule detects authenticated sessions accessing secret stores across multiple cloud providers from the same source address within a short period of time. Adversaries with access to compromised credentials or session tokens may attempt to retrieve secrets from services such as AWS Secrets Manager, Google Secret Manager, or Azure Key Vault in rapid succession to expand their access or exfiltrate sensitive information. |[Domain: Cloud], [Domain: IAM], [Domain: Storage], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Secrets Manager], [Data Source: Azure], [Data Source: Azure Activity Logs], [Data Source: GCP], [Data Source: Google Cloud Platform], [Tactic: Credential Access], [Resources: Investigation Guide] |None |4
 
@@ -1556,20 +1586,18 @@ and their rule type is `machine_learning`.
 
 |<<multiple-elastic-defend-alerts-from-a-single-process-tree, Multiple Elastic Defend Alerts from a Single Process Tree>> |Detects multiple Elastic Defend EDR alerts originating from the same process tree, indicating coordinated malicious activity. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |2
 
-|<<multiple-external-edr-alerts-by-host, Multiple External EDR Alerts by Host>> |This rule uses alert data to determine when multiple external EDR alerts involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Endpoint] |None |2
+|<<multiple-external-edr-alerts-by-host, Multiple External EDR Alerts by Host>> |This rule uses alert data to determine when multiple external EDR alerts involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Endpoint] |None |3
 
 |<<multiple-logon-failure-followed-by-logon-success, Multiple Logon Failure Followed by Logon Success>> |Identifies multiple logon failures followed by a successful one from the same source address. 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 |116
 
 |<<multiple-logon-failure-from-the-same-source-address, Multiple Logon Failure from the same Source Address>> |Identifies multiple consecutive logon failures 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 |117
 
-|<<multiple-machine-learning-alerts-by-influencer-field, Multiple Machine Learning Alerts by Influencer Field>> |This rule uses alerts data to determine when multiple unique machine learning jobs involving the same influencer field are triggered. Analysts can use this to prioritize triage and response machine learning alerts. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Rule Type: Machine Learning] |None |2
+|<<multiple-machine-learning-alerts-by-influencer-field, Multiple Machine Learning Alerts by Influencer Field>> |This rule uses alerts data to determine when multiple unique machine learning jobs involving the same influencer field are triggered. Analysts can use this to prioritize triage and response machine learning alerts. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Rule Type: Machine Learning] |None |3
 
 |<<multiple-okta-sessions-detected-for-a-single-user, Multiple Okta Sessions Detected for a Single User>> |Detects when a user has started multiple Okta sessions with the same user account and different session IDs. This may indicate that an attacker has stolen the user's session cookie and is using it to access the user's account from a different location. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |210
 
 |<<multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy, Multiple Okta User Auth Events with Same Device Token Hash Behind a Proxy>> |Detects when Okta user authentication events are reported for multiple users with the same device token hash behind a proxy. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |210
 
-|<<multiple-okta-user-authentication-events-with-client-address, Multiple Okta User Authentication Events with Client Address>> |Detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |209
-
 |<<multiple-okta-user-authentication-events-with-same-device-token-hash, Multiple Okta User Authentication Events with Same Device Token Hash>> |Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |209
 
 |<<multiple-vault-web-credentials-read, Multiple Vault Web Credentials Read>> |Windows Credential Manager allows you to create, view, or delete saved credentials for signing into websites, connected applications, and networks. An adversary may abuse this to list or dump credentials stored in the Credential Manager for saved usernames and passwords. This may also be performed in preparation of lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |116
@@ -1646,11 +1674,11 @@ and their rule type is `machine_learning`.
 
 |<<newly-observed-elastic-defend-behavior-alert, Newly Observed Elastic Defend Behavior Alert>> |This rule detects Elastic Defend behavior alerts that are observed for the first time today when compared against the previous 5 days of alert history. It highlights low-volume, newly observed alerts tied to a specific detection rule, analysts can use this to prioritize triage and response. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |3
 
-|<<newly-observed-fortigate-alert, Newly Observed FortiGate Alert>> |This rule detects FortiGate alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Network], [Data Source: Fortinet] |None |2
+|<<newly-observed-fortigate-alert, Newly Observed FortiGate Alert>> |This rule detects FortiGate alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Network], [Data Source: Fortinet] |None |3
 
-|<<newly-observed-high-severity-detection-alert, Newly Observed High Severity Detection Alert>> |This rule detects Elastic SIEM high severity detection alerts that are observed for the first time in the previous 5 days of alert history. It highlights low-volume, newly observed alerts tied to a specific detection rule, analysts can use this to prioritize triage and response. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |3
+|<<newly-observed-high-severity-detection-alert, Newly Observed High Severity Detection Alert>> |This rule detects Elastic SIEM high severity detection alerts that are observed for the first time in the previous 5 days of alert history. It highlights low-volume, newly observed alerts tied to a specific detection rule, analysts can use this to prioritize triage and response. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |4
 
-|<<newly-observed-high-severity-suricata-alert, Newly Observed High Severity Suricata Alert>> |This rule detects Suricata high severity alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Network], [Data Source: Suricata] |None |2
+|<<newly-observed-high-severity-suricata-alert, Newly Observed High Severity Suricata Alert>> |This rule detects Suricata high severity alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Network], [Data Source: Suricata] |None |3
 
 |<<newly-observed-palo-alto-network-alert, Newly Observed Palo Alto Network Alert>> |This rule detects Palo Alto Network alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Network], [Data Source: PAN-OS] |None |2
 
@@ -1664,9 +1692,9 @@ and their rule type is `machine_learning`.
 
 |<<office-test-registry-persistence, Office Test Registry Persistence>> |Identifies the modification of the Microsoft Office "Office Test" Registry key, a registry location that can be used to specify a DLL which will be executed every time an MS Office application is started. Attackers can abuse this to gain persistence on a compromised host. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Data Source: Sysmon], [Resources: Investigation Guide] |None |107
 
-|<<okta-aitm-session-cookie-replay, Okta AiTM Session Cookie Replay>> |Detects potential Adversary-in-the-Middle (AiTM) session cookie replay attacks against Okta. This rule identifies when an Okta session is used from multiple IP addresses or with suspicious non-browser user agents after initial authentication. AiTM attacks capture session cookies via phishing proxies (e.g., Evilginx, Modlishka) and replay them from attacker infrastructure, bypassing MFA. The detection correlates session start events with subsequent policy evaluations or SSO attempts that occur from different IPs or programmatic user agents. |[Domain: Identity], [Use Case: Identity and Access Audit], [Data Source: Okta], [Data Source: Okta System Logs], [Tactic: Credential Access], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |2
+|<<okta-admin-console-login-failure, Okta Admin Console Login Failure>> |Identifies failed login attempts to the Okta Admin Console. Adversaries may attempt to gain unauthorized access to administrator portals during reconnaissance or privilege escalation phases. Repeated failures may indicate brute force attacks, credential spraying, or attempts to use compromised credentials. Monitoring Admin Console access failures provides visibility into potential account takeover attempts targeting administrative accounts. |[Domain: Identity], [Use Case: Identity and Access Audit], [Data Source: Okta], [Data Source: Okta System Logs], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide], [Rule Type: BBR] |None |1
 
-|<<okta-brute-force-or-password-spraying-attack, Okta Brute Force or Password Spraying Attack>> |Identifies a high number of failed Okta user authentication attempts from a single IP address, which could be indicative of a brute force or password spraying attack. An adversary may attempt a brute force or password spraying attack to obtain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Tactic: Credential Access], [Data Source: Okta], [Resources: Investigation Guide] |None |415
+|<<okta-aitm-session-cookie-replay, Okta AiTM Session Cookie Replay>> |Detects potential Adversary-in-the-Middle (AiTM) session cookie replay attacks against Okta. This rule identifies when an Okta session is used from multiple IP addresses or with suspicious non-browser user agents after initial authentication. AiTM attacks capture session cookies via phishing proxies (e.g., Evilginx, Modlishka) and replay them from attacker infrastructure, bypassing MFA. The detection correlates session start events with subsequent policy evaluations or SSO attempts that occur from different IPs or programmatic user agents. |[Domain: Identity], [Use Case: Identity and Access Audit], [Data Source: Okta], [Data Source: Okta System Logs], [Tactic: Credential Access], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |2
 
 |<<okta-fastpass-phishing-detection, Okta FastPass Phishing Detection>> |Detects when Okta FastPass prevents a user from authenticating to a phishing website. |[Tactic: Initial Access], [Use Case: Identity and Access Audit], [Data Source: Okta], [Resources: Investigation Guide] |None |310
 
@@ -1674,8 +1702,12 @@ and their rule type is `machine_learning`.
 
 |<<okta-sign-in-events-via-third-party-idp, Okta Sign-In Events via Third-Party IdP>> |Detects sign-in events where authentication is carried out via a third-party Identity Provider (IdP) that has not been seen before. Adversaries may add an unauthorized IdP to an Okta tenant to gain persistent access. This rule uses New Terms detection to only alert when a previously unseen IdP is used for authentication, reducing noise from legitimate federated identity providers while highlighting potentially rogue IdP additions. |[Domain: Identity], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Data Source: Okta], [Resources: Investigation Guide] |None |211
 
+|<<okta-successful-login-after-credential-attack, Okta Successful Login After Credential Attack>> |Correlates Okta credential attack alerts with subsequent successful authentication for the same user account, identifying potential compromise following brute force, password spray, or credential stuffing attempts. |[Domain: Identity], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Data Source: Okta], [Data Source: Okta System Logs], [Tactic: Credential Access], [Tactic: Initial Access], [Resources: Investigation Guide], [Rule Type: Higher-Order Rule] |None |2
+
 |<<okta-threatinsight-threat-suspected-promotion, Okta ThreatInsight Threat Suspected Promotion>> |Okta ThreatInsight is a feature that provides valuable debug data regarding authentication and authorization processes, which is logged in the system. Within this data, there is a specific field called threat_suspected, which represents Okta's internal evaluation of the authentication or authorization workflow. When this field is set to True, it suggests the presence of potential credential access techniques, such as password-spraying, brute-forcing, replay attacks, and other similar threats. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Resources: Investigation Guide] |None |412
 
+|<<okta-user-assigned-administrator-role, Okta User Assigned Administrator Role>> |Identifies when an administrator role is assigned to an Okta user or group. Adversaries may assign administrator privileges to compromised accounts to establish persistence, escalate privileges, and maintain long-term access to the environment. This detection monitors for both user-level and group-level administrator privilege grants, which can be used to bypass security controls and perform unauthorized administrative actions. |[Domain: Identity], [Data Source: Okta], [Data Source: Okta System Logs], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |413
+
 |<<okta-user-session-impersonation, Okta User Session Impersonation>> |A user has initiated a session impersonation granting them access to the environment with the permissions of the user they are impersonating. This would likely indicate Okta administrative access and should only ever occur if requested and expected. |[Use Case: Identity and Access Audit], [Tactic: Credential Access], [Data Source: Okta], [Resources: Investigation Guide] |None |414
 
 |<<okta-user-sessions-started-from-different-geolocations, Okta User Sessions Started from Different Geolocations>> |Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Initial Access], [Resources: Investigation Guide] |None |310
@@ -1766,7 +1798,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-adidns-poisoning-via-wildcard-record-creation, Potential ADIDNS Poisoning via Wildcard Record Creation>> |Active Directory Integrated DNS (ADIDNS) is one of the core components of AD DS, leveraging AD's access control and replication to maintain domain consistency. It stores DNS zones as AD objects, a feature that, while robust, introduces some security issues, such as wildcard records, mainly because of the default permission (Any authenticated users) to create DNS-named records. Attackers can create wildcard records to redirect traffic that doesn't explicitly match records contained in the zone, becoming the Man-in-the-Middle and being able to abuse DNS similarly to LLMNR/NBNS spoofing. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |107
 
-|<<potential-aws-s3-bucket-ransomware-note-uploaded, Potential AWS S3 Bucket Ransomware Note Uploaded>> |Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the PutObject S3 API call with an object name commonly associated with ransomware notes. The keywords detected here rarely overlap with common file names and have been attributed to ransomware notes with high-confidence. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |9
+|<<potential-aws-s3-bucket-ransomware-note-uploaded, Potential AWS S3 Bucket Ransomware Note Uploaded>> |Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the PutObject S3 API call with an object name commonly associated with ransomware notes. The keywords detected here rarely overlap with common file names and have been attributed to ransomware notes with high-confidence. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |10
 
 |<<potential-abuse-of-resources-by-high-token-count-and-large-response-sizes, Potential Abuse of Resources by High Token Count and Large Response Sizes>> |Detects potential resource exhaustion or data breach attempts by monitoring for users who consistently generate high input token counts, submit numerous requests, and receive large responses. This behavior could indicate an attempt to overload the system or extract an unusually large amount of data, possibly revealing sensitive information or causing service disruptions. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: Amazon Web Services], [Data Source: AWS S3], [Use Case: Potential Overload], [Use Case: Resource Exhaustion], [Mitre Atlas: LLM04], [Resources: Investigation Guide] |None |7
 
@@ -1852,7 +1884,7 @@ and their rule type is `machine_learning`.
 
 |<<potential-docker-escape-via-nsenter, Potential Docker Escape via Nsenter>> |This rule identifies a UID change event via "nsenter". The "nsenter" command is used to enter a namespace, which is a way to isolate processes and resources. Attackers can use "nsenter" to escape from a container to the host, which can lead to privilege escalation and lateral movement. |[Domain: Endpoint], [Domain: Container], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |5
 
-|<<potential-dynamic-iex-reconstruction-via-environment-variables, Potential Dynamic IEX Reconstruction via Environment Variables>> |Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command at runtime using indexed slices of environment variables. This technique leverages character access and join operations to build execution logic dynamically, bypassing static keyword detection and evading defenses such as AMSI. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |9
+|<<potential-dynamic-iex-reconstruction-via-environment-variables, Potential Dynamic IEX Reconstruction via Environment Variables>> |Detects PowerShell scripts that reconstructs IEX (Invoke-Expression) by indexing environment variable strings (for example, $env:VAR[1,2,3]) or related `.name[...]` slices and joining characters at runtime. Attackers use environment-variable slicing to hide dynamic execution and evade keyword-based detections and AMSI. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |10
 
 |<<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 |5
 
@@ -1934,17 +1966,17 @@ and their rule type is `machine_learning`.
 
 |<<potential-linux-ransomware-note-creation-detected, Potential Linux Ransomware Note Creation Detected>> |This rule identifies a sequence of a mass file encryption event in conjunction with the creation of a .txt file with a file name containing ransomware keywords executed by the same process in a 1 second timespan. Ransomware is a type of malware that encrypts a victim's files or systems and demands payment (usually in cryptocurrency) in exchange for the decryption key. One important indicator of a ransomware attack is the mass encryption of the file system, after which a new file extension is added to the file. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Impact], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |15
 
-|<<potential-linux-tunneling-and-or-port-forwarding, Potential Linux Tunneling and/or Port Forwarding>> |This rule monitors for a set of Linux utilities that can be used for tunneling and port forwarding. Attackers can leverage tunneling and port forwarding techniques to bypass network defenses, establish hidden communication channels, and gain unauthorized access to internal resources, facilitating data exfiltration, lateral movement, and remote control. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Auditd Manager], [Resources: Investigation Guide] |None |113
+|<<potential-linux-tunneling-and-or-port-forwarding, Potential Linux Tunneling and/or Port Forwarding>> |This rule monitors for a set of Linux utilities that can be used for tunneling and port forwarding. Attackers can leverage tunneling and port forwarding techniques to bypass network defenses, establish hidden communication channels, and gain unauthorized access to internal resources, facilitating data exfiltration, lateral movement, and remote control. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Auditd Manager], [Resources: Investigation Guide] |None |114
 
 |<<potential-linux-tunneling-and-or-port-forwarding-via-command-line, Potential Linux Tunneling and/or Port Forwarding via Command Line>> |This rule monitors for potential tunneling and/or port forwarding activity on Linux systems via command line utilities. Attackers may use various tools to create covert communication channels, allowing them to bypass network security measures and maintain persistent access to compromised systems. By leveraging these utilities, attackers can tunnel traffic through legitimate protocols, making detection more challenging. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Data Source: Auditd Manager], [Resources: Investigation Guide] |None |1
 
-|<<potential-linux-tunneling-and-or-port-forwarding-via-ssh-option, Potential Linux Tunneling and/or Port Forwarding via SSH Option>> |This rule detects the use of SSH options that may indicate tunneling or port forwarding on Linux systems. This behavior is commonly associated with malicious activity, such as establishing a port forward, proxy or an encrypted tunnel to exfiltrate data. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |3
+|<<potential-linux-tunneling-and-or-port-forwarding-via-ssh-option, Potential Linux Tunneling and/or Port Forwarding via SSH Option>> |This rule detects the use of SSH options that may indicate tunneling or port forwarding on Linux systems. This behavior is commonly associated with malicious activity, such as establishing a port forward, proxy or an encrypted tunnel to exfiltrate data. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |4
 
 |<<potential-local-ntlm-relay-via-http, Potential Local NTLM Relay via HTTP>> |Identifies attempt to coerce a local NTLM authentication via HTTP using the Windows Printer Spooler service as a target. An adversary may use this primitive in combination with other techniques to elevate privileges on a compromised system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |315
 
 |<<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 a successful SMB relay attack. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Active Directory], [Use Case: Active Directory Monitoring], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |2
 
-|<<potential-malicious-powershell-based-on-alert-correlation, Potential Malicious PowerShell Based on Alert Correlation>> |Identifies PowerShell script blocks associated with multiple distinct detections, indicating likely malicious behavior. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Rule Type: Higher-Order Rule], [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-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 |10
 
@@ -1980,8 +2012,20 @@ 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 |13
 
+|<<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 for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |1
+
+|<<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 |210
+
+|<<potential-okta-brute-force-multi-source, Potential Okta Brute Force (Multi-Source)>> |Detects potential brute force attacks against a single Okta user account from multiple source IPs, indicating attackers rotating through proxy infrastructure to evade IP-based detection. |[Domain: Identity], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Data Source: Okta], [Data Source: Okta System Logs], [Tactic: Credential Access], [Resources: Investigation Guide] |None |2
+
+|<<potential-okta-credential-stuffing-single-source, Potential Okta Credential Stuffing (Single Source)>> |Detects potential credential stuffing attacks where a single source IP attempts authentication against many Okta user accounts with minimal attempts per user, indicating the use of breached credential lists. |[Domain: Identity], [Use Case: Identity and Access Audit], [Data Source: Okta], [Data Source: Okta System Logs], [Tactic: Credential Access], [Resources: Investigation Guide] |None |210
+
 |<<potential-okta-mfa-bombing-via-push-notifications, Potential Okta MFA Bombing via Push Notifications>> |Detects when an attacker abuses the Multi-Factor authentication mechanism by repeatedly issuing login requests until the user eventually accepts the Okta push notification. An adversary may attempt to bypass the Okta MFA policies configured for an organization to obtain unauthorized access. |[Domain: Identity], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Data Source: Okta], [Data Source: Okta System Logs], [Resources: Investigation Guide] |None |211
 
+|<<potential-okta-password-spray-multi-source, Potential Okta Password Spray (Multi-Source)>> |Detects potential password spray attacks where multiple source IPs target multiple Okta user accounts within a time window, indicating coordinated attacks using IP rotation to evade single-source detection. |[Domain: Identity], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Data Source: Okta], [Data Source: Okta System Logs], [Tactic: Credential Access], [Resources: Investigation Guide] |None |2
+
+|<<potential-okta-password-spray-single-source, Potential Okta Password Spray (Single Source)>> |Detects potential password spray attacks where a single source IP attempts authentication against multiple Okta user accounts with repeated attempts per user, indicating common password guessing paced to avoid lockouts. |[Domain: Identity], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Data Source: Okta], [Data Source: Okta System Logs], [Resources: Investigation Guide] |None |417
+
 |<<potential-openssh-backdoor-logging-activity, Potential OpenSSH Backdoor Logging Activity>> |Identifies a Secure Shell (SSH) client or server process creating a known SSH backdoor log file. Adversaries may modify SSH related binaries for persistence or credential access via patching sensitive functions to enable unauthorized access or to log SSH credentials for exfiltration. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Credential Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |214
 
 |<<potential-outgoing-rdp-connection-by-unusual-process, Potential Outgoing RDP Connection by Unusual Process>> |Adversaries may attempt to connect to a remote system over Windows Remote Desktop Protocol (RDP) to achieve lateral movement. Adversaries may avoid using the Microsoft Terminal Services Client (mstsc.exe) binary to establish an RDP connection to evade detection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Rule Type: BBR] |None |6
@@ -2006,31 +2050,31 @@ 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 |11
 
-|<<potential-powershell-hacktool-script-by-author, Potential PowerShell HackTool Script by Author>> |Detects known PowerShell offensive tooling author's name in PowerShell scripts. Attackers commonly use out-of-the-box offensive tools without modifying the code, which may still contain the author artifacts. This rule identifies common author handles found in popular PowerShell scripts used for red team exercises. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |108
+|<<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-function-names, Potential PowerShell HackTool Script by Function Names>> |Detects known PowerShell offensive tooling functions names in PowerShell scripts. Attackers commonly use out-of-the-box offensive tools without modifying the code. This rule aim is to take advantage of that. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |219
+|<<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 |220
 
-|<<potential-powershell-obfuscated-script, Potential PowerShell Obfuscated Script>> |Identifies scripts that contain patterns and known methods that obfuscate PowerShell code. Attackers can use obfuscation techniques to bypass PowerShell security protections such as Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |108
+|<<potential-powershell-obfuscated-script-via-high-entropy, Potential PowerShell Obfuscated Script via High Entropy>> |Identifies PowerShell script blocks with high entropy and non-uniform character distributions. Attackers may obfuscate PowerShell scripts using encoding, encryption, or compression techniques to evade signature-based detections and hinder manual analysis by security analysts. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |1
 
-|<<potential-powershell-obfuscation-via-backtick-escaped-variable-expansion, Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion>> |Identifies PowerShell scripts that use backtick-escaped characters inside ${} variable expansion as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |8
+|<<potential-powershell-obfuscation-via-backtick-escaped-variable-expansion, Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion>> |Detects PowerShell scripts that uses backtick-escaped characters inside `${}` variable expansion (multiple backticks between word characters) to reconstruct strings at runtime. Attackers use variable-expansion obfuscation to split keywords, hide commands, 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 |9
 
-|<<potential-powershell-obfuscation-via-character-array-reconstruction, Potential PowerShell Obfuscation via Character Array Reconstruction>> |Identifies PowerShell scripts that use character arrays and runtime string reconstruction as a form of obfuscation. This technique breaks strings into individual characters, often using constructs like char[] with index-based access or joining logic. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |8
+|<<potential-powershell-obfuscation-via-character-array-reconstruction, Potential PowerShell Obfuscation via Character Array Reconstruction>> |Detects PowerShell scripts that reconstructs strings from char[] arrays, index lookups, or repeated ([char]NN)+ concatenation/join logic. Attackers use character-array reconstruction to hide commands, URLs, 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 |9
 
-|<<potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation, Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation>> |Identifies PowerShell scripts that use concatenated strings within dynamic command invocation (&() or .()) as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |8
+|<<potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation, Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation>> |Detects PowerShell scripts that builds commands from concatenated string literals inside dynamic invocation constructs like &() or .(). Attackers use concatenated dynamic invocation to obscure execution intent, bypass keyword-based detections, and evade AMSI. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |9
 
-|<<potential-powershell-obfuscation-via-high-numeric-character-proportion, Potential PowerShell Obfuscation via High Numeric Character Proportion>> |Identifies PowerShell scripts with a disproportionately high number of numeric characters, often indicating the presence of obfuscated or encoded payloads. This behavior is typical of obfuscation methods involving byte arrays, character code manipulation, or embedded encoded strings used to deliver and execute malicious content. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |10
+|<<potential-powershell-obfuscation-via-high-numeric-character-proportion, Potential PowerShell Obfuscation via High Numeric Character Proportion>> |Detects long PowerShell script block content with unusually high numeric character density (high digit-to-length ratio), often produced by byte arrays, character-code reconstruction, or embedded encoded blobs. Attackers use numeric-heavy obfuscation to conceal payloads and rebuild them at runtime to avoid static inspection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |11
 
-|<<potential-powershell-obfuscation-via-high-special-character-proportion, Potential PowerShell Obfuscation via High Special Character Proportion>> |Identifies PowerShell scripts with an abnormally high proportion of non-alphanumeric characters, often resulting from encoding, string mangling, or dynamic code generation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Rule Type: BBR] |None |8
+|<<potential-powershell-obfuscation-via-high-special-character-proportion, Potential PowerShell Obfuscation via High Special Character Proportion>> |Identifies PowerShell script block content with an unusually high proportion of non-alphanumeric characters, often produced by encoding, string mangling, or dynamic code generation. Attackers use special-character heavy obfuscation to conceal payloads and hinder static analysis and AMSI. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Rule Type: BBR], [Resources: Investigation Guide] |None |9
 
-|<<potential-powershell-obfuscation-via-invalid-escape-sequences, Potential PowerShell Obfuscation via Invalid Escape Sequences>> |Identifies PowerShell scripts that use invalid escape sequences as a form of obfuscation. This technique introduces backticks (`) between characters in a way that does not correspond to valid PowerShell escape sequences, breaking up strings and bypassing pattern-based detections while preserving execution logic. This is designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |10
+|<<potential-powershell-obfuscation-via-invalid-escape-sequences, Potential PowerShell Obfuscation via Invalid Escape Sequences>> |Detects PowerShell scripts with repeated invalid backtick escapes between word characters (letters, digits, underscore, or dash), splitting tokens while preserving execution. Attackers use this obfuscation to fragment keywords and evade pattern-based detection and AMSI. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |11
 
-|<<potential-powershell-obfuscation-via-reverse-keywords, Potential PowerShell Obfuscation via Reverse Keywords>> |Identifies PowerShell scripts that use reversed strings as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |9
+|<<potential-powershell-obfuscation-via-reverse-keywords, Potential PowerShell Obfuscation via Reverse Keywords>> |Detects PowerShell scripts containing reversed keyword strings associated with execution or network activity (for example, ekovni, noisserpxe, daolnwod, tcejbo-wen, tcejboimw, etc.). Attackers reverse keywords and reconstruct them at runtime to hide intent and evade static detection and AMSI. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |10
 
-|<<potential-powershell-obfuscation-via-special-character-overuse, Potential PowerShell Obfuscation via Special Character Overuse>> |Identifies PowerShell scripts with an unusually high proportion of whitespace and special characters, often indicative of obfuscation. This behavior is commonly associated with techniques such as SecureString encoding, formatting obfuscation, or character-level manipulation designed to bypass static analysis and AMSI inspection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |9
+|<<potential-powershell-obfuscation-via-special-character-overuse, Potential PowerShell Obfuscation via Special Character Overuse>> |Detects PowerShell scripts dominated by whitespace and special characters with low symbol diversity, a profile often produced by formatting or encoding obfuscation. Attackers use symbol-heavy encoding or formatting (for example, SecureString-style blobs or character-level transforms) to hide 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
 
-|<<potential-powershell-obfuscation-via-string-concatenation, Potential PowerShell Obfuscation via String Concatenation>> |Identifies PowerShell scripts that use string concatenation as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |9
+|<<potential-powershell-obfuscation-via-string-concatenation, Potential PowerShell Obfuscation via String Concatenation>> |Detects PowerShell scripts that repeatedly concatenates multiple quoted string literals with + to assemble commands or tokens at runtime. Attackers use string concatenation to fragment keywords or URLs 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
 
-|<<potential-powershell-obfuscation-via-string-reordering, Potential PowerShell Obfuscation via String Reordering>> |Identifies PowerShell scripts that use string reordering and runtime reconstruction techniques as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |11
+|<<potential-powershell-obfuscation-via-string-reordering, Potential PowerShell Obfuscation via String Reordering>> |Detects PowerShell scripts that uses format placeholders like "{0}{1}" with the -f operator or ::Format to reorder strings at runtime. Attackers use format-based reconstruction to hide commands or payload strings 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 |12
 
 |<<potential-powershell-pass-the-hash-relay-script, Potential PowerShell Pass-the-Hash/Relay Script>> |Detects PowerShell scripts associated with NTLM relay or pass-the-hash tooling and SMB/NTLM negotiation artifacts. Attackers use relay and PtH techniques to authenticate without passwords and pivot to other systems. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |108
 
@@ -2068,7 +2112,7 @@ and their rule type is `machine_learning`.
 
 |<<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
 
-|<<potential-process-injection-via-powershell, Potential Process Injection via PowerShell>> |Detects the use of Windows API functions that are commonly abused by malware and security tools to load malicious code or inject it into remote processes. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |216
+|<<potential-process-injection-via-powershell, Potential Process Injection via PowerShell>> |Detects PowerShell scripts that combines Win32 APIs for allocation/protection or process access (for example, VirtualAlloc/VirtualProtect/OpenProcess/AdjustTokenPrivileges/LoadLibrary/GetProcAddress) with injection or execution APIs (WriteProcessMemory/CreateRemoteThread/NtCreateThreadEx/QueueUserAPC/ResumeThread). Attackers use these API chains to inject code into remote processes and execute payloads in memory for defense evasion. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |217
 
 |<<potential-process-name-stomping-with-prctl, Potential Process Name Stomping with Prctl>> |This rule leverages Auditd data to detect the use of the "prctl" syscall to potentially hide a process by changing its name. The "prctl" syscall is used to control various process attributes. Attackers can use this syscall to change the name of a process to a hidden directory or file, making it harder to detect. The query looks for the "prctl" syscall with the "PR_SET_NAME" argument set to "f" (PR_SET_NAME is used to set the name of a process). |[Data Source: Auditd Manager], [Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |6
 
@@ -2152,6 +2196,8 @@ and their rule type is `machine_learning`.
 
 |<<potential-telnet-authentication-bypass-cve-2026-24061, Potential Telnet Authentication Bypass (CVE-2026-24061)>> |Identifies potential exploitation of a Telnet remote authentication bypass vulnerability (CVE-2026-24061) in GNU Inetutils telnetd. The vulnerability allows unauthenticated access by supplying a crafted `-f <username>` value via the `USER` environment variable, resulting in a login process spawned with elevated privileges. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Lateral Movement], [Resources: Investigation Guide], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne] |None |1
 
+|<<potential-timestomp-in-executable-files, Potential Timestomp in Executable Files>> |Identifies the modification of a file creation time for executable files in sensitive system directories. Adversaries may modify file time attributes to blend malicious executables with legitimate system files. Timestomping is a technique that modifies the timestamps of a file often to mimic files that are in trusted directories. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Sysmon], [Resources: Investigation Guide] |None |110
+
 |<<potential-toolshell-initial-exploit-cve-2025-53770-cve-2025-53771, Potential Toolshell Initial Exploit (CVE-2025-53770 & CVE-2025-53771)>> |Identifies potential exploitation of CVE-2025-53770 and CVE-2025-53771 in IIS web servers on SharePoint sites. Toolshell is an exploit chain that leverages vulnerabilities in SharePoint/IIS to gain unauthorized access and execute commands. This rule detects HTTP requests that match specific patterns indicative of the exploit attempt. |[Domain: Network], [Tactic: Initial Access], [Use Case: Exploit Detection], [Data Source: Network Traffic], [Data Source: Network Traffic HTTP Logs], [Rule Type: BBR] |None |1
 
 |<<potential-traffic-tunneling-using-qemu, Potential Traffic Tunneling using QEMU>> |Identifies the use of the QEMU hardware emulator to potentially tunnel network traffic between Virtual machines. This can be used by attackers to enable routing of network packets that would otherwise not reach their intended destination. |[Domain: Endpoint], [OS: Windows], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender for Endpoint], [Data Source: Windows Security Event Logs], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |1
@@ -2198,37 +2244,33 @@ and their rule type is `machine_learning`.
 
 |<<powershell-minidump-script, PowerShell MiniDump Script>> |Detects PowerShell scripts referencing MiniDumpWriteDump or full-memory minidump types, which can capture process memory. Attackers often use this technique to dump credential-bearing processes like LSASS for credential theft. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |213
 
-|<<powershell-obfuscation-via-negative-index-string-reversal, PowerShell Obfuscation via Negative Index String Reversal>> |Identifies PowerShell scripts that use negative index ranges to reverse the contents of a string or array at runtime as a form of obfuscation. This technique avoids direct use of reversal functions by iterating through array elements in reverse order. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI). |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |8
-
-|<<powershell-psreflect-script, PowerShell PSReflect Script>> |Detects the use of PSReflect in PowerShell scripts. Attackers leverage PSReflect as a library that enables PowerShell to access win32 API functions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |316
-
-|<<powershell-script-block-logging-disabled, PowerShell Script Block Logging Disabled>> |Identifies attempts to disable PowerShell Script Block Logging via registry modification. 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 for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |314
+|<<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 |9
 
-|<<powershell-script-with-archive-compression-capabilities, PowerShell Script with Archive Compression Capabilities>> |Identifies the use of Cmdlets and methods related to archive compression activities. Adversaries will often compress and encrypt data in preparation for exfiltration. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Data Source: PowerShell Logs], [Rule Type: BBR] |None |211
+|<<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-script-with-discovery-capabilities, PowerShell Script with Discovery Capabilities>> |Identifies the use of Cmdlets and methods related to discovery activities. Attackers can use these to perform various situational awareness related activities, like enumerating users, shares, sessions, domain trusts, groups, etc. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Tactic: Discovery], [Data Source: PowerShell Logs], [Rule Type: BBR] |None |213
+|<<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 for Endpoint], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |315
 
-|<<powershell-script-with-encryption-decryption-capabilities, PowerShell Script with Encryption/Decryption Capabilities>> |Identifies the use of Cmdlets and methods related to encryption/decryption of files in PowerShell scripts, which malware and offensive security tools can abuse to encrypt data or decrypt payloads to bypass security solutions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |111
+|<<powershell-script-with-archive-compression-capabilities, PowerShell Script with Archive Compression Capabilities>> |Identifies PowerShell script block content that uses archive compression cmdlets or .NET compression classes (for example, Compress-Archive, ZipFile, GZipStream, DeflateStream) to build compressed artifacts. Attackers compress or package data to stage it for collection or exfiltration. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Data Source: PowerShell Logs], [Rule Type: BBR], [Resources: Investigation Guide] |None |212
 
-|<<powershell-script-with-log-clear-capabilities, PowerShell Script with Log Clear Capabilities>> |Identifies the use of Cmdlets and methods related to Windows event log deletion activities. 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], [Data Source: PowerShell Logs], [Rule Type: BBR] |None |210
+|<<powershell-script-with-encryption-decryption-capabilities, PowerShell Script with Encryption/Decryption Capabilities>> |Identifies PowerShell script block content that uses .NET cryptography APIs for file encryption or decryption. Attackers abuse these routines to encrypt data for impact or decrypt staged payloads to evade defenses. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |112
 
-|<<powershell-script-with-password-policy-discovery-capabilities, PowerShell Script with Password Policy Discovery Capabilities>> |Identifies the use of Cmdlets and methods related to remote execution activities using WinRM. Attackers can abuse WinRM to perform lateral movement using built-in tools. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Tactic: Execution], [Data Source: PowerShell Logs], [Rule Type: BBR] |None |110
+|<<powershell-script-with-log-clear-capabilities, PowerShell Script with Log Clear Capabilities>> |Identifies PowerShell script block content that clears Windows event logs using Clear-EventLog, Remove-EventLog, or EventLogSession/EventLog Clear methods. Attackers clear local logs to evade detection and destroy forensic evidence. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Rule Type: BBR], [Resources: Investigation Guide] |None |211
 
-|<<powershell-script-with-remote-execution-capabilities-via-winrm, PowerShell Script with Remote Execution Capabilities via WinRM>> |Identifies the use of Cmdlets and methods related to remote execution activities using WinRM. Attackers can abuse WinRM to perform lateral movement using built-in tools. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Execution], [Data Source: PowerShell Logs], [Rule Type: BBR] |None |211
+|<<powershell-script-with-password-policy-discovery-capabilities, PowerShell Script with Password Policy Discovery Capabilities>> |Identifies PowerShell script block content that queries Active Directory password policy settings using AD cmdlets, GPP password helpers, or directory searcher attributes. Attackers collect password policy details to tune credential attacks and target weak configurations. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Tactic: Execution], [Data Source: PowerShell Logs], [Rule Type: BBR], [Resources: Investigation Guide] |None |111
 
-|<<powershell-script-with-token-impersonation-capabilities, PowerShell Script with Token Impersonation Capabilities>> |Detects scripts that contain PowerShell functions, structures, or Windows API functions related to token impersonation/theft. Attackers may duplicate then impersonate another user's token to escalate privileges and bypass access controls. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |117
+|<<powershell-script-with-token-impersonation-capabilities, PowerShell Script with Token Impersonation Capabilities>> |Detects PowerShell scripts that references token manipulation and impersonation APIs such as CreateProcessWithTokenW, DuplicateToken/ImpersonateLoggedOnUser, or AdjustTokenPrivileges (SeDebugPrivilege). Attackers abuse token impersonation to elevate privileges and bypass access controls. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |118
 
 |<<powershell-script-with-veeam-credential-access-capabilities, PowerShell Script with Veeam Credential Access Capabilities>> |Identifies PowerShell script block content that queries Veeam credential tables or uses ProtectedStorage to decrypt stored secrets. Attackers abuse Veeam credentials to access backup infrastructure and enable ransomware operations. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |107
 
 |<<powershell-script-with-webcam-video-capture-capabilities, PowerShell Script with Webcam Video Capture Capabilities>> |Detects PowerShell script block content that references webcam capture APIs or video capture device objects. Attackers use webcam recording to surveil victims or collect sensitive footage for extortion. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |110
 
-|<<powershell-script-with-windows-defender-tampering-capabilities, PowerShell Script with Windows Defender Tampering Capabilities>> |Identifies PowerShell scripts containing cmdlets and parameters that attackers can abuse to disable Windows Defender features. Attackers can tamper with antivirus to reduce the risk of detection when executing their payloads. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |107
+|<<powershell-script-with-windows-defender-tampering-capabilities, PowerShell Script with Windows Defender Tampering Capabilities>> |Detects PowerShell scripts that uses Set-MpPreference with parameters that disable or weaken Defender. Attackers tamper with antivirus settings to reduce detection and enable follow-on payload execution. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: PowerShell Logs], [Resources: Investigation Guide] |None |108
 
-|<<powershell-share-enumeration-script, PowerShell Share Enumeration Script>> |Detects scripts that contain PowerShell functions, structures, or Windows API functions related to windows share enumeration activities. Attackers, mainly ransomware groups, commonly identify and inspect network shares, looking for critical information for encryption and/or exfiltration. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Tactic: Collection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |114
+|<<powershell-share-enumeration-script, PowerShell Share Enumeration Script>> |Detects PowerShell scripts that uses ShareFinder functions (Invoke-ShareFinder/Invoke-ShareFinderThreaded) or Windows share enumeration APIs (shi1_netname/shi1_remark with NetShareEnum/NetApiBufferFree). Attackers use share enumeration to map accessible network shares for collection, lateral movement, or ransomware targeting. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Tactic: Collection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |115
 
-|<<powershell-suspicious-discovery-related-windows-api-functions, PowerShell Suspicious Discovery Related Windows API Functions>> |This rule detects the use of discovery-related Windows API functions in PowerShell Scripts. Attackers can use these functions to perform various situational awareness related activities, like enumerating users, shares, sessions, domain trusts, groups, etc. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Tactic: Collection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |318
+|<<powershell-suspicious-discovery-related-windows-api-functions, PowerShell Suspicious Discovery Related Windows API Functions>> |Detects PowerShell scripts that references native Windows API functions commonly used for discovery of users, groups, shares, sessions, domain trusts, and service security. Attackers use these APIs for situational awareness and targeting prior to lateral movement or collection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Tactic: Collection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |319
 
-|<<powershell-suspicious-payload-encoded-and-compressed, PowerShell Suspicious Payload Encoded and Compressed>> |Identifies the use of .NET functionality for decompression and base64 decoding combined in PowerShell scripts, which malware and security tools heavily use to deobfuscate payloads and load them directly in memory to bypass defenses. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |317
+|<<powershell-suspicious-payload-encoded-and-compressed, PowerShell Suspicious Payload Encoded and Compressed>> |Identifies PowerShell script block content that combines Base64 decoding with .NET decompression (Deflate/GZip). Attackers use this pattern to deobfuscate and reconstruct payloads in memory to evade defenses. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |318
 
 |<<powershell-suspicious-script-with-audio-capture-capabilities, PowerShell Suspicious Script with Audio Capture Capabilities>> |Detects PowerShell script block content that invokes microphone capture routines or WinMM audio APIs. Adversaries may use audio recording to surveil users or capture sensitive conversations for theft or extortion. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |216
 
@@ -2298,7 +2340,7 @@ and their rule type is `machine_learning`.
 
 |<<processes-with-trailing-spaces, Processes with Trailing Spaces>> |Identify instances where adversaries include trailing space characters to mimic regular files, disguising their activity to evade default file handling mechanisms. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Resources: Investigation Guide] |None |5
 
-|<<program-files-directory-masquerading, Program Files Directory Masquerading>> |Identifies execution from a directory masquerading as the Windows Program Files directories. These paths are trusted and usually host trusted third party programs. An adversary may leverage masquerading, along with low privileges to bypass detections allowlisting those folders. |[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 for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |318
+|<<program-files-directory-masquerading, Program Files Directory Masquerading>> |Identifies execution from a directory masquerading as the Windows Program Files directories. These paths are trusted and usually host trusted third party programs. An adversary may leverage masquerading, along with low privileges to bypass detections allowlisting those folders. |[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 for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |319
 
 |<<prompt-for-credentials-with-osascript, Prompt for Credentials with Osascript>> |Identifies the use of osascript to execute scripts via standard input that may prompt a user with a rogue dialog for credentials. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |214
 
@@ -2418,8 +2460,6 @@ and their rule type is `machine_learning`.
 
 |<<smtp-on-port-26-tcp, SMTP on Port 26/TCP>> |This rule detects events that may indicate use of SMTP on TCP port 26. This port is commonly used by several popular mail transfer agents to deconflict with the default SMTP port 25. This port has also been used by a malware family called BadPatch for command and control of Windows systems. |[Tactic: Command and Control], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: PAN-OS], [Resources: Investigation Guide] |None |108
 
-|<<socks-traffic-from-an-unusual-process, SOCKS Traffic from an Unusual Process>> |This detection correlates FortiGate's application control SOCKS events with Elastic Defend network event to identify the source process performing SOCKS traffic. Adversaries may use a connection proxy to direct network traffic between systems or act as an intermediary for network communications to a command and control server to avoid direct connections to their infrastructure. |[Domain: Endpoint], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Fortinet], [Resources: Investigation Guide] |None |1
-
 |<<ssh-authorized-keys-file-activity, SSH Authorized Keys File Activity>> |The Secure Shell (SSH) authorized_keys file specifies which users are allowed to log into a server using public key authentication. Adversaries may modify it to maintain persistence on a victim host by adding their own public key(s). |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |210
 
 |<<ssh-authorized-keys-file-deletion, SSH Authorized Keys File Deletion>> |This rule detects the deletion of the authorized_keys or authorized_keys2 files on Linux systems. These files are used to store public keys for SSH authentication. Unauthorized deletion of these files can be an indicator of an attacker removing access to the system, and may be a precursor to further malicious activity. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |5
@@ -2542,15 +2582,15 @@ and their rule type is `machine_learning`.
 
 |<<spike-in-network-traffic-to-a-country, Spike in Network Traffic To a Country>> |A machine learning job detected an unusually large spike in network activity to one destination country in the network logs. This could be due to unusually large amounts of reconnaissance or enumeration traffic. Data exfiltration activity may also produce such a surge in traffic to a destination country that does not normally appear in network traffic or business workflows. Malware instances and persistence mechanisms may communicate with command-and-control (C2) infrastructure in their country of origin, which may be an unusual destination country for the source network. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |109
 
-|<<spike-in-number-of-connections-made-from-a-source-ip, Spike in Number of Connections Made from a Source IP>> |A machine learning job has detected a high count of destination IPs establishing an RDP connection with a single source IP. Once an attacker has gained access to one system, they might attempt to access more in the network in search of valuable assets, data, or further access points. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |7
+|<<spike-in-number-of-connections-made-from-a-source-ip, Spike in Number of Connections Made from a Source IP>> |A machine learning job has detected a high count of destination IPs establishing an RDP connection with a single source IP. Once an attacker has gained access to one system, they might attempt to access more in the network in search of valuable assets, data, or further access points. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |8
 
-|<<spike-in-number-of-connections-made-to-a-destination-ip, Spike in Number of Connections Made to a Destination IP>> |A machine learning job has detected a high count of source IPs establishing an RDP connection with a single destination IP. Attackers might use multiple compromised systems to attack a target to ensure redundancy in case a source IP gets detected and blocked. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |7
+|<<spike-in-number-of-connections-made-to-a-destination-ip, Spike in Number of Connections Made to a Destination IP>> |A machine learning job has detected a high count of source IPs establishing an RDP connection with a single destination IP. Attackers might use multiple compromised systems to attack a target to ensure redundancy in case a source IP gets detected and blocked. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |8
 
-|<<spike-in-number-of-processes-in-an-rdp-session, Spike in Number of Processes in an RDP Session>> |A machine learning job has detected unusually high number of processes started in a single RDP session. Executing a large number of processes remotely on other machines can be an indicator of lateral movement activity. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |7
+|<<spike-in-number-of-processes-in-an-rdp-session, Spike in Number of Processes in an RDP Session>> |A machine learning job has detected unusually high number of processes started in a single RDP session. Executing a large number of processes remotely on other machines can be an indicator of lateral movement activity. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |8
 
 |<<spike-in-privileged-command-execution-by-a-user, Spike in Privileged Command Execution by a User>> |A machine learning job has detected an increase in the execution of privileged commands by a user, suggesting potential privileged access activity. This may indicate an attempt by the user to gain unauthorized access to sensitive or restricted parts of the system. |[Use Case: Privileged Access Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |3
 
-|<<spike-in-remote-file-transfers, Spike in Remote File Transfers>> |A machine learning job has detected an abnormal volume of remote files shared on the host indicating potential lateral movement activity. One of the primary goals of attackers after gaining access to a network is to locate and exfiltrate valuable information. Attackers might perform multiple small transfers to match normal egress activity in the network, to evade detection. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |7
+|<<spike-in-remote-file-transfers, Spike in Remote File Transfers>> |A machine learning job has detected an abnormal volume of remote files shared on the host indicating potential lateral movement activity. One of the primary goals of attackers after gaining access to a network is to locate and exfiltrate valuable information. Attackers might perform multiple small transfers to match normal egress activity in the network, to evade detection. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |8
 
 |<<spike-in-special-logon-events, Spike in Special Logon Events>> |A machine learning job has detected a surge in special logon events for a user, indicating potential privileged access activity. A sudden spike in these events could suggest an attacker or malicious insider gaining elevated access, possibly for lateral movement or privilege escalation. |[Use Case: Privileged Access Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |3
 
@@ -2596,11 +2636,11 @@ and their rule type is `machine_learning`.
 
 |<<suricata-and-elastic-defend-network-correlation, Suricata and Elastic Defend Network Correlation>> |This detection correlates Suricata alerts with Elastic Defend network events to identify the source process performing the network activity. |[Domain: Endpoint], [Domain: Network], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: Suricata], [Resources: Investigation Guide] |None |2
 
-|<<suspected-lateral-movement-from-compromised-host, Suspected Lateral Movement from Compromised Host>> |Detects potential lateral movement or post-compromise activity by correlating alerts where the host.ip of one alert matches the source.ip of a subsequent alert. This behavior may indicate a compromised host being used to authenticate to another system or resource, including cloud services. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |3
+|<<suspected-lateral-movement-from-compromised-host, Suspected Lateral Movement from Compromised Host>> |Detects potential lateral movement or post-compromise activity by correlating alerts where the host.ip of one alert matches the source.ip of a subsequent alert. This behavior may indicate a compromised host being used to authenticate to another system or resource, including cloud services. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |4
 
 |<<suspicious-net-code-compilation, Suspicious .NET Code Compilation>> |Identifies executions of .NET compilers with suspicious parent processes, which can indicate an attacker's attempt to compile code after delivery in order to bypass security mechanisms. |[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 for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |316
 
-|<<suspicious-net-reflection-via-powershell, Suspicious .NET Reflection via PowerShell>> |Detects the use of Reflection.Assembly to load PEs and DLLs in memory in PowerShell scripts. Attackers use this method to load executables and DLLs without writing to the disk, bypassing security solutions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |320
+|<<suspicious-net-reflection-via-powershell, Suspicious .NET Reflection via PowerShell>> |Detects PowerShell scripts that invoke Reflection.Assembly or Assembly.Load to load .NET assemblies. Attackers use this method to load executables and DLLs without writing to the disk, bypassing security solutions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |321
 
 |<<suspicious-proc-maps-discovery, Suspicious /proc/maps Discovery>> |Monitors for /proc/*/maps file reads. The /proc/*/maps file in Linux provides a memory map for a specific process, detailing the memory segments, permissions, and what files are mapped to these segments. Attackers may read a process's memory map to identify memory addresses for code injection or process hijacking. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Tactic: Credential Access], [Data Source: Auditd Manager], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |8
 
@@ -2632,6 +2672,8 @@ and their rule type is `machine_learning`.
 
 |<<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 for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |319
 
+|<<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 |213
+
 |<<suspicious-communication-app-child-process, Suspicious Communication App Child Process>> |Identifies suspicious child processes of communications apps, which can indicate a potential masquerading as the communication app or the exploitation of a vulnerability on the application causing it to execute code. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: SentinelOne], [Data Source: Elastic Endgame] |None |12
 
 |<<suspicious-content-extracted-or-decompressed-via-funzip, Suspicious Content Extracted or Decompressed via Funzip>> |Identifies when suspicious content is extracted from a file and subsequently decompressed using the funzip utility. Malware may execute the tail utility using the "-c" option to read a sequence of bytes from the end of a file. The output from tail can be piped to funzip in order to decompress malicious code before it is executed. This behavior is consistent with malware families such as Bundlore. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |110
@@ -2658,7 +2700,7 @@ and their rule type is `machine_learning`.
 
 |<<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 for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |210
 
-|<<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 |211
+|<<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 |212
 
 |<<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 for Endpoint], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |1
 
@@ -2748,7 +2790,7 @@ and their rule type is `machine_learning`.
 
 |<<suspicious-path-mounted, Suspicious Path Mounted>> |This rule detects suspicious paths mounted on Linux systems. The mount command is used to attach filesystems to the system, and attackers may use it to mount malicious filesystems or directories for data exfiltration or persistence. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |3
 
-|<<suspicious-portable-executable-encoded-in-powershell-script, Suspicious Portable Executable Encoded in Powershell Script>> |Detects the presence of a portable executable (PE) in a PowerShell script by looking for its encoded header. Attackers embed PEs into PowerShell scripts to inject them into memory, avoiding defences by not writing to disk. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |215
+|<<suspicious-portable-executable-encoded-in-powershell-script, Suspicious Portable Executable Encoded in Powershell Script>> |Detects PowerShell scripts that includes a base64-encoded portable executable (PE) header, indicating an embedded binary payload. Attackers embed PEs in scripts to load payloads in memory and avoid writing executables to disk. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: PowerShell Logs] |None |216
 
 |<<suspicious-powershell-engine-imageload, Suspicious PowerShell Engine ImageLoad>> |Identifies the PowerShell engine being invoked by unexpected processes. Rather than executing PowerShell functionality with powershell.exe, some attackers do this to operate more stealthily. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |216
 
@@ -2760,8 +2802,6 @@ and their rule type is `machine_learning`.
 
 |<<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 for Endpoint] |None |116
 
-|<<suspicious-printspooler-service-executable-file-creation, Suspicious PrintSpooler Service Executable File Creation>> |Detects attempts to exploit privilege escalation vulnerabilities related to the Print Spooler service. For more information refer to the following CVE's - CVE-2020-1048, CVE-2020-1337 and CVE-2020-1300 and verify that the impacted system is patched. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender for Endpoint], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |319
-
 |<<suspicious-proc-pseudo-file-system-enumeration, Suspicious Proc Pseudo File System Enumeration>> |This rule monitors for a rapid enumeration of 25 different proc cmd, stat, and exe files, which suggests an abnormal activity pattern. Such behavior could be an indicator of a malicious process scanning or gathering information about running processes, potentially for reconnaissance, privilege escalation, or identifying vulnerable targets. |[Data Source: Auditd Manager], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: BBR] |None |9
 
 |<<suspicious-process-access-via-direct-system-call, Suspicious Process Access via Direct System Call>> |Identifies suspicious process access events from an unknown memory region. Endpoint security solutions usually hook userland Windows APIs in order to decide if the code that is being executed is malicious or not. It's possible to bypass hooked functions by writing malicious functions that call syscalls directly. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Sysmon] |None |314
@@ -2824,7 +2864,7 @@ and their rule type is `machine_learning`.
 
 |<<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 for Endpoint], [Data Source: Elastic Endgame], [Data Source: Crowdstrike] |None |206
 
-|<<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 for Endpoint], [Data Source: Crowdstrike], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |210
+|<<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 for Endpoint], [Data Source: Crowdstrike], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |211
 
 |<<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 for Endpoint], [Data Source: Windows Security Event Logs], [Data Source: Crowdstrike], [Data Source: Sysmon] |None |420
 
@@ -2852,7 +2892,7 @@ and their rule type is `machine_learning`.
 
 |<<system-information-discovery-via-windows-command-shell, System Information Discovery via Windows Command Shell>> |Identifies the execution of discovery commands to enumerate system information, files, and folders using the Windows Command Shell. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Rule Type: BBR], [Data Source: Elastic Endgame], [Data Source: Windows Security Event Logs] |None |118
 
-|<<system-information-discovery-via-dmidecode-from-parent-shell, System Information Discovery via dmidecode from Parent Shell>> |This rule detects the use of dmidecode to gather system information from a Linux host when executed from a parent shell process. Adversaries may use dmidecode to collect detailed hardware and system information, which can aid in further exploitation or lateral movement within a network, or be used as a fingerprint for a compromised system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |1
+|<<system-information-discovery-via-dmidecode-from-parent-shell, System Information Discovery via dmidecode from Parent Shell>> |This rule detects the use of dmidecode to gather system information from a Linux host when executed from a parent shell process. Adversaries may use dmidecode to collect detailed hardware and system information, which can aid in further exploitation or lateral movement within a network, or be used as a fingerprint for a compromised system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |2
 
 |<<system-log-file-deletion, System Log File Deletion>> |Identifies the deletion of sensitive Linux system logs. This may indicate an attempt to evade detection or destroy forensic evidence on a system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |217
 
@@ -2984,8 +3024,6 @@ and their rule type is `machine_learning`.
 
 |<<unusual-dpkg-execution, Unusual DPKG Execution>> |This rule detects the execution of the DPKG command by processes not associated with the DPKG package manager. The DPKG command is used to install, remove, and manage Debian packages on a Linux system. Attackers can abuse the DPKG command to install malicious packages on a system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |7
 
-|<<unusual-discovery-activity-by-user, Unusual Discovery Activity by User>> |This rule leverages alert data from various Discovery building block rules to alert on signals with unusual unique host.id and user.id entries. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: Higher-Order Rule], [Rule Type: BBR] |None |2
-
 |<<unusual-discovery-signal-alert-with-unusual-process-command-line, Unusual Discovery Signal Alert with Unusual Process Command Line>> |This rule leverages alert data from various Discovery building block rules to alert on signals with unusual unique host.id, user.id and process.command_line entries. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |3
 
 |<<unusual-discovery-signal-alert-with-unusual-process-executable, Unusual Discovery Signal Alert with Unusual Process Executable>> |This rule leverages Discovery building block rule alert data to alert on signals with unusual unique host.id, user.id and process.executable entries. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |4
@@ -3116,11 +3154,11 @@ and their rule type is `machine_learning`.
 
 |<<unusual-remote-file-creation, Unusual Remote File Creation>> |This rule leverages the new_terms rule type to detect file creation via a commonly used file transfer service while excluding typical remote file creation activity. This behavior is often linked to lateral movement, potentially indicating an attacker attempting to move within a network. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |5
 
-|<<unusual-remote-file-directory, Unusual Remote File Directory>> |An anomaly detection job has detected a remote file transfer on an unusual directory indicating a potential lateral movement activity on the host. Many Security solutions monitor well-known directories for suspicious activities, so attackers might use less common directories to bypass monitoring. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |7
+|<<unusual-remote-file-directory, Unusual Remote File Directory>> |An anomaly detection job has detected a remote file transfer on an unusual directory indicating a potential lateral movement activity on the host. Many Security solutions monitor well-known directories for suspicious activities, so attackers might use less common directories to bypass monitoring. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |8
 
-|<<unusual-remote-file-extension, Unusual Remote File Extension>> |An anomaly detection job has detected a remote file transfer with a rare extension, which could indicate potential lateral movement activity on the host. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |7
+|<<unusual-remote-file-extension, Unusual Remote File Extension>> |An anomaly detection job has detected a remote file transfer with a rare extension, which could indicate potential lateral movement activity on the host. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |8
 
-|<<unusual-remote-file-size, Unusual Remote File Size>> |A machine learning job has detected an unusually high file size shared by a remote host indicating potential lateral movement activity. One of the primary goals of attackers after gaining access to a network is to locate and exfiltrate valuable information. Instead of multiple small transfers that can raise alarms, attackers might choose to bundle data into a single large file transfer. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |7
+|<<unusual-remote-file-size, Unusual Remote File Size>> |A machine learning job has detected an unusually high file size shared by a remote host indicating potential lateral movement activity. One of the primary goals of attackers after gaining access to a network is to locate and exfiltrate valuable information. Instead of multiple small transfers that can raise alarms, attackers might choose to bundle data into a single large file transfer. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |8
 
 |<<unusual-sshd-child-process, Unusual SSHD Child Process>> |This rule detects the creation of an unusual SSHD child process through the usage of the "new_terms" rule type. Attackers may abuse SSH to maintain persistence on a compromised system, or to establish a backdoor for remote access, potentially resulting in an unusual SSHD child process being created. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |6
 
@@ -3138,7 +3176,7 @@ and their rule type is `machine_learning`.
 
 |<<unusual-sudo-activity, Unusual Sudo Activity>> |Looks for sudo activity from an unusual user context. An unusual sudo user could be due to troubleshooting activity or it could be a sign of credentialed access via compromised accounts. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |107
 
-|<<unusual-time-or-day-for-an-rdp-session, Unusual Time or Day for an RDP Session>> |A machine learning job has detected an RDP session started at an usual time or weekday. An RDP session at an unusual time could be followed by other suspicious activities, so catching this is a good first step in detecting a larger attack. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |7
+|<<unusual-time-or-day-for-an-rdp-session, Unusual Time or Day for an RDP Session>> |A machine learning job has detected an RDP session started at an usual time or weekday. An RDP session at an unusual time could be followed by other suspicious activities, so catching this is a good first step in detecting a larger attack. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |8
 
 |<<unusual-user-privilege-enumeration-via-id, Unusual User Privilege Enumeration via id>> |This rule monitors for a sequence of 20 "id" command executions within 1 second by the same parent process. This behavior is unusual, and may be indicative of the execution of an enumeration script such as LinPEAS or LinEnum. These scripts leverage the "id" command to enumerate the privileges of all users present on the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |9
 
@@ -3282,7 +3320,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 |104
 
-|<<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 |2
+|<<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 |3
 
 |<<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 |119
 
diff --git a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc
index 21771586fd..1cb89c1066 100644
--- a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc
@@ -46,6 +46,7 @@ include::rule-details/aws-efs-file-system-deleted.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[]
+include::rule-details/aws-guardduty-member-account-manipulation.asciidoc[]
 include::rule-details/aws-iam-api-calls-via-temporary-session-tokens.asciidoc[]
 include::rule-details/aws-iam-administratoraccess-policy-attached-to-group.asciidoc[]
 include::rule-details/aws-iam-administratoraccess-policy-attached-to-role.asciidoc[]
@@ -59,9 +60,11 @@ include::rule-details/aws-iam-group-creation.asciidoc[]
 include::rule-details/aws-iam-group-deletion.asciidoc[]
 include::rule-details/aws-iam-login-profile-added-for-root.asciidoc[]
 include::rule-details/aws-iam-login-profile-added-to-user.asciidoc[]
+include::rule-details/aws-iam-oidc-provider-created-by-rare-user.asciidoc[]
 include::rule-details/aws-iam-principal-enumeration-via-updateassumerolepolicy.asciidoc[]
 include::rule-details/aws-iam-roles-anywhere-profile-creation.asciidoc[]
 include::rule-details/aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc[]
+include::rule-details/aws-iam-saml-provider-created.asciidoc[]
 include::rule-details/aws-iam-saml-provider-updated.asciidoc[]
 include::rule-details/aws-iam-user-addition-to-group.asciidoc[]
 include::rule-details/aws-iam-user-created-access-keys-for-another-user.asciidoc[]
@@ -101,6 +104,7 @@ include::rule-details/aws-sns-topic-created-by-rare-user.asciidoc[]
 include::rule-details/aws-sns-topic-message-publish-by-rare-user.asciidoc[]
 include::rule-details/aws-sqs-queue-purge.asciidoc[]
 include::rule-details/aws-ssm-command-document-created-by-rare-user.asciidoc[]
+include::rule-details/aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc[]
 include::rule-details/aws-ssm-session-started-to-ec2-instance.asciidoc[]
 include::rule-details/aws-ssm-sendcommand-execution-by-rare-user.asciidoc[]
 include::rule-details/aws-ssm-sendcommand-with-run-shell-command-parameters.asciidoc[]
@@ -112,6 +116,7 @@ include::rule-details/aws-sts-role-assumption-by-service.asciidoc[]
 include::rule-details/aws-sts-role-assumption-by-user.asciidoc[]
 include::rule-details/aws-sts-role-chaining.asciidoc[]
 include::rule-details/aws-secrets-manager-rapid-secrets-retrieval.asciidoc[]
+include::rule-details/aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc[]
 include::rule-details/aws-service-quotas-multi-region-getservicequota-requests.asciidoc[]
 include::rule-details/aws-sign-in-console-login-with-federated-user.asciidoc[]
 include::rule-details/aws-sign-in-root-password-recovery-requested.asciidoc[]
@@ -138,8 +143,6 @@ include::rule-details/adding-hidden-file-attribute-via-attrib.asciidoc[]
 include::rule-details/adminsdholder-backdoor.asciidoc[]
 include::rule-details/adminsdholder-sdprop-exclusion-added.asciidoc[]
 include::rule-details/administrator-privileges-assigned-to-an-okta-group.asciidoc[]
-include::rule-details/administrator-role-assigned-to-an-okta-user.asciidoc[]
-include::rule-details/adobe-hijack-persistence.asciidoc[]
 include::rule-details/adversary-behavior-detected-elastic-endgame.asciidoc[]
 include::rule-details/agent-spoofing-multiple-hosts-using-same-agent.asciidoc[]
 include::rule-details/alerts-from-multiple-integrations-by-destination-address.asciidoc[]
@@ -226,6 +229,8 @@ include::rule-details/azure-vnet-firewall-front-door-waf-policy-deleted.asciidoc
 include::rule-details/azure-vnet-firewall-policy-deleted.asciidoc[]
 include::rule-details/azure-vnet-full-network-packet-capture-enabled.asciidoc[]
 include::rule-details/azure-vnet-network-watcher-deleted.asciidoc[]
+include::rule-details/bpf-program-tampering-via-bpftool.asciidoc[]
+include::rule-details/bpf-program-or-map-load-via-bpftool.asciidoc[]
 include::rule-details/bpf-filter-applied-using-tc.asciidoc[]
 include::rule-details/backup-deletion-with-wbadmin.asciidoc[]
 include::rule-details/base16-or-base32-encoding-decoding-activity.asciidoc[]
@@ -250,7 +255,6 @@ include::rule-details/command-execution-via-forfiles.asciidoc[]
 include::rule-details/command-execution-via-solarwinds-process.asciidoc[]
 include::rule-details/command-line-obfuscation-via-whitespace-padding.asciidoc[]
 include::rule-details/command-obfuscation-via-unicode-modifier-letters.asciidoc[]
-include::rule-details/command-prompt-network-connection.asciidoc[]
 include::rule-details/command-shell-activity-started-via-rundll32.asciidoc[]
 include::rule-details/command-and-scripting-interpreter-via-windows-scripts.asciidoc[]
 include::rule-details/component-object-model-hijacking.asciidoc[]
@@ -263,6 +267,7 @@ 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/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[]
 include::rule-details/creation-of-hidden-launch-agent-or-daemon.asciidoc[]
 include::rule-details/creation-of-hidden-login-item-via-apple-script.asciidoc[]
@@ -300,8 +305,23 @@ include::rule-details/default-cobalt-strike-team-server-certificate.asciidoc[]
 include::rule-details/delayed-execution-via-ping.asciidoc[]
 include::rule-details/delegated-managed-service-account-modification-by-an-unusual-user.asciidoc[]
 include::rule-details/delete-volume-usn-journal-with-fsutil.asciidoc[]
+include::rule-details/deprecated-adobe-hijack-persistence.asciidoc[]
 include::rule-details/deprecated-eggshell-backdoor-execution.asciidoc[]
+include::rule-details/deprecated-encoded-executable-stored-in-the-registry.asciidoc[]
+include::rule-details/deprecated-m365-exchange-dlp-policy-deleted.asciidoc[]
+include::rule-details/deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish.asciidoc[]
+include::rule-details/deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc[]
+include::rule-details/deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc[]
+include::rule-details/deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc[]
+include::rule-details/deprecated-m365-teams-external-access-enabled.asciidoc[]
+include::rule-details/deprecated-m365-teams-guest-access-enabled.asciidoc[]
+include::rule-details/deprecated-microsoft-exchange-transport-agent-install-script.asciidoc[]
+include::rule-details/deprecated-potential-powershell-obfuscated-script.asciidoc[]
+include::rule-details/deprecated-powershell-script-with-discovery-capabilities.asciidoc[]
+include::rule-details/deprecated-powershell-script-with-remote-execution-capabilities-via-winrm.asciidoc[]
 include::rule-details/deprecated-sudo-heap-based-buffer-overflow-attempt.asciidoc[]
+include::rule-details/deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc[]
+include::rule-details/deprecated-unusual-discovery-activity-by-user.asciidoc[]
 include::rule-details/detection-alert-on-a-process-exhibiting-cpu-spike.asciidoc[]
 include::rule-details/directory-creation-in-bin-directory.asciidoc[]
 include::rule-details/disable-windows-event-and-security-logs-using-built-in-tools.asciidoc[]
@@ -330,12 +350,12 @@ include::rule-details/esxi-discovery-via-grep.asciidoc[]
 include::rule-details/esxi-timestomping-using-touch-command.asciidoc[]
 include::rule-details/egress-connection-from-entrypoint-in-container.asciidoc[]
 include::rule-details/elastic-agent-service-terminated.asciidoc[]
+include::rule-details/elastic-defend-alert-followed-by-telemetry-loss.asciidoc[]
 include::rule-details/elastic-defend-and-email-alerts-correlation.asciidoc[]
 include::rule-details/elastic-defend-and-network-security-alerts-correlation.asciidoc[]
 include::rule-details/elastic-security-external-alerts.asciidoc[]
 include::rule-details/emond-rules-creation-or-modification.asciidoc[]
 include::rule-details/enable-host-network-discovery-via-netsh.asciidoc[]
-include::rule-details/encoded-executable-stored-in-the-registry.asciidoc[]
 include::rule-details/encrypting-files-with-winrar-or-7z.asciidoc[]
 include::rule-details/endpoint-security-elastic-defend.asciidoc[]
 include::rule-details/entra-id-adrs-token-request-by-microsoft-authentication-broker.asciidoc[]
@@ -343,10 +363,10 @@ include::rule-details/entra-id-actor-token-user-impersonation-abuse.asciidoc[]
 include::rule-details/entra-id-application-credential-modified.asciidoc[]
 include::rule-details/entra-id-concurrent-sign-in-with-suspicious-properties.asciidoc[]
 include::rule-details/entra-id-conditional-access-policy-cap-modified.asciidoc[]
-include::rule-details/entra-id-device-registration-detected-roadtools.asciidoc[]
 include::rule-details/entra-id-elevated-access-to-user-access-administrator.asciidoc[]
 include::rule-details/entra-id-external-authentication-methods-eam-modified.asciidoc[]
 include::rule-details/entra-id-external-guest-user-invited.asciidoc[]
+include::rule-details/entra-id-federated-identity-credential-issuer-modified.asciidoc[]
 include::rule-details/entra-id-global-administrator-role-assigned.asciidoc[]
 include::rule-details/entra-id-global-administrator-role-assigned-pim-user.asciidoc[]
 include::rule-details/entra-id-high-risk-sign-in.asciidoc[]
@@ -364,7 +384,6 @@ include::rule-details/entra-id-oauth-phishing-via-first-party-microsoft-applicat
 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-oidc-discovery-url-modified.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[]
@@ -375,10 +394,12 @@ 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-service-principal-created.asciidoc[]
 include::rule-details/entra-id-service-principal-credentials-created-by-unusual-user.asciidoc[]
-include::rule-details/entra-id-sharepoint-accessed-by-unusual-user-and-microsoft-authentication-broker-client.asciidoc[]
+include::rule-details/entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc[]
+include::rule-details/entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc[]
 include::rule-details/entra-id-sign-in-bloodhound-suite-user-agent-detected.asciidoc[]
 include::rule-details/entra-id-sign-in-brute-force-attempted-microsoft-365.asciidoc[]
 include::rule-details/entra-id-sign-in-teamfiltration-user-agent-detected.asciidoc[]
+include::rule-details/entra-id-unusual-cloud-device-registration.asciidoc[]
 include::rule-details/entra-id-user-added-as-registered-application-owner.asciidoc[]
 include::rule-details/entra-id-user-added-as-service-principal-owner.asciidoc[]
 include::rule-details/entra-id-user-reported-suspicious-activity.asciidoc[]
@@ -427,7 +448,6 @@ include::rule-details/external-ip-address-discovery-via-curl.asciidoc[]
 include::rule-details/external-ip-lookup-from-non-browser-process.asciidoc[]
 include::rule-details/external-user-added-to-google-workspace-group.asciidoc[]
 include::rule-details/file-compressed-or-archived-into-common-format-by-unsigned-process.asciidoc[]
-include::rule-details/file-creation-time-changed.asciidoc[]
 include::rule-details/file-creation-by-cups-or-foomatic-rip-child.asciidoc[]
 include::rule-details/file-creation-in-var-log-via-suspicious-process.asciidoc[]
 include::rule-details/file-creation-execution-and-self-deletion-in-suspicious-directory.asciidoc[]
@@ -467,6 +487,8 @@ include::rule-details/fortigate-administrator-login-from-multiple-ip-addresses.a
 include::rule-details/fortigate-configuration-file-downloaded.asciidoc[]
 include::rule-details/fortigate-forticloud-sso-login-from-unusual-source.asciidoc[]
 include::rule-details/fortigate-overly-permissive-firewall-policy-created.asciidoc[]
+include::rule-details/fortigate-socks-traffic-from-an-unusual-process.asciidoc[]
+include::rule-details/fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc[]
 include::rule-details/fortigate-sso-login-followed-by-administrator-account-creation.asciidoc[]
 include::rule-details/fortigate-super-admin-account-creation.asciidoc[]
 include::rule-details/forwarded-google-workspace-security-alert.asciidoc[]
@@ -553,7 +575,6 @@ include::rule-details/high-mean-of-rdp-session-duration.asciidoc[]
 include::rule-details/high-number-of-cloned-github-repos-from-pat.asciidoc[]
 include::rule-details/high-number-of-closed-pull-requests-by-user.asciidoc[]
 include::rule-details/high-number-of-egress-network-connections-from-unusual-executable.asciidoc[]
-include::rule-details/high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc[]
 include::rule-details/high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc[]
 include::rule-details/high-number-of-process-terminations.asciidoc[]
 include::rule-details/high-number-of-process-and-or-service-terminations.asciidoc[]
@@ -596,8 +617,10 @@ include::rule-details/kerberos-pre-authentication-disabled-for-user.asciidoc[]
 include::rule-details/kerberos-traffic-from-unusual-process.asciidoc[]
 include::rule-details/kernel-driver-load.asciidoc[]
 include::rule-details/kernel-driver-load-by-non-root-user.asciidoc[]
+include::rule-details/kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc[]
 include::rule-details/kernel-load-or-unload-via-kexec-detected.asciidoc[]
-include::rule-details/kernel-module-load-via-insmod.asciidoc[]
+include::rule-details/kernel-module-load-from-unusual-location.asciidoc[]
+include::rule-details/kernel-module-load-via-built-in-utility.asciidoc[]
 include::rule-details/kernel-module-removal.asciidoc[]
 include::rule-details/kernel-object-file-creation.asciidoc[]
 include::rule-details/kernel-seeking-activity.asciidoc[]
@@ -668,7 +691,6 @@ include::rule-details/local-scheduled-task-creation.asciidoc[]
 include::rule-details/m365-exchange-anti-phish-policy-deleted.asciidoc[]
 include::rule-details/m365-exchange-anti-phish-rule-modification.asciidoc[]
 include::rule-details/m365-exchange-dkim-signing-configuration-disabled.asciidoc[]
-include::rule-details/m365-exchange-dlp-policy-deleted.asciidoc[]
 include::rule-details/m365-exchange-email-safe-attachment-rule-disabled.asciidoc[]
 include::rule-details/m365-exchange-email-safe-link-policy-disabled.asciidoc[]
 include::rule-details/m365-exchange-federated-domain-created-or-modified.asciidoc[]
@@ -683,7 +705,6 @@ include::rule-details/m365-exchange-mailbox-items-accessed-excessively.asciidoc[
 include::rule-details/m365-exchange-malware-filter-policy-deleted.asciidoc[]
 include::rule-details/m365-exchange-malware-filter-rule-modified.asciidoc[]
 include::rule-details/m365-exchange-management-group-role-assigned.asciidoc[]
-include::rule-details/m365-identity-excessive-sso-login-errors-reported.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-impossible-travel-location.asciidoc[]
@@ -691,18 +712,13 @@ include::rule-details/m365-identity-oauth-flow-by-first-party-microsoft-app-from
 include::rule-details/m365-identity-oauth-flow-by-user-sign-in-to-device-registration.asciidoc[]
 include::rule-details/m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user.asciidoc[]
 include::rule-details/m365-identity-oauth-phishing-via-first-party-microsoft-application.asciidoc[]
+include::rule-details/m365-identity-unusual-sso-authentication-errors-for-user.asciidoc[]
 include::rule-details/m365-identity-user-account-lockouts.asciidoc[]
 include::rule-details/m365-identity-user-brute-force-attempted.asciidoc[]
 include::rule-details/m365-onedrive-excessive-file-downloads-with-oauth-token.asciidoc[]
 include::rule-details/m365-onedrive-malware-file-upload.asciidoc[]
-include::rule-details/m365-security-compliance-email-reported-by-user-as-malware-or-phish.asciidoc[]
-include::rule-details/m365-security-compliance-potential-ransomware-activity.asciidoc[]
-include::rule-details/m365-security-compliance-unusual-volume-of-file-deletion.asciidoc[]
-include::rule-details/m365-security-compliance-user-restricted-from-sending-email.asciidoc[]
 include::rule-details/m365-sharepoint-malware-file-detected.asciidoc[]
 include::rule-details/m365-teams-custom-application-interaction-enabled.asciidoc[]
-include::rule-details/m365-teams-external-access-enabled.asciidoc[]
-include::rule-details/m365-teams-guest-access-enabled.asciidoc[]
 include::rule-details/m365-threat-intelligence-signal.asciidoc[]
 include::rule-details/m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc[]
 include::rule-details/mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc[]
@@ -736,7 +752,6 @@ include::rule-details/microsoft-build-engine-using-an-alternate-name.asciidoc[]
 include::rule-details/microsoft-entra-id-exccessive-account-lockouts-detected.asciidoc[]
 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-transport-agent-install-script.asciidoc[]
 include::rule-details/microsoft-exchange-worker-spawning-suspicious-processes.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[]
@@ -775,7 +790,6 @@ include::rule-details/multiple-logon-failure-from-the-same-source-address.asciid
 include::rule-details/multiple-machine-learning-alerts-by-influencer-field.asciidoc[]
 include::rule-details/multiple-okta-sessions-detected-for-a-single-user.asciidoc[]
 include::rule-details/multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc[]
-include::rule-details/multiple-okta-user-authentication-events-with-client-address.asciidoc[]
 include::rule-details/multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc[]
 include::rule-details/multiple-vault-web-credentials-read.asciidoc[]
 include::rule-details/multiple-vulnerabilities-by-asset-via-wiz.asciidoc[]
@@ -823,12 +837,14 @@ include::rule-details/node-js-pre-or-post-install-script-execution.asciidoc[]
 include::rule-details/nping-process-activity.asciidoc[]
 include::rule-details/nullsessionpipe-registry-modification.asciidoc[]
 include::rule-details/office-test-registry-persistence.asciidoc[]
+include::rule-details/okta-admin-console-login-failure.asciidoc[]
 include::rule-details/okta-aitm-session-cookie-replay.asciidoc[]
-include::rule-details/okta-brute-force-or-password-spraying-attack.asciidoc[]
 include::rule-details/okta-fastpass-phishing-detection.asciidoc[]
 include::rule-details/okta-multiple-os-names-detected-for-a-single-dt-hash.asciidoc[]
 include::rule-details/okta-sign-in-events-via-third-party-idp.asciidoc[]
+include::rule-details/okta-successful-login-after-credential-attack.asciidoc[]
 include::rule-details/okta-threatinsight-threat-suspected-promotion.asciidoc[]
+include::rule-details/okta-user-assigned-administrator-role.asciidoc[]
 include::rule-details/okta-user-session-impersonation.asciidoc[]
 include::rule-details/okta-user-sessions-started-from-different-geolocations.asciidoc[]
 include::rule-details/ollama-api-accessed-from-external-network.asciidoc[]
@@ -981,7 +997,13 @@ include::rule-details/potential-network-scan-detected.asciidoc[]
 include::rule-details/potential-network-scan-executed-from-host.asciidoc[]
 include::rule-details/potential-network-share-discovery.asciidoc[]
 include::rule-details/potential-network-sweep-detected.asciidoc[]
+include::rule-details/potential-notepad-markdown-rce-exploitation.asciidoc[]
+include::rule-details/potential-okta-brute-force-device-token-rotation.asciidoc[]
+include::rule-details/potential-okta-brute-force-multi-source.asciidoc[]
+include::rule-details/potential-okta-credential-stuffing-single-source.asciidoc[]
 include::rule-details/potential-okta-mfa-bombing-via-push-notifications.asciidoc[]
+include::rule-details/potential-okta-password-spray-multi-source.asciidoc[]
+include::rule-details/potential-okta-password-spray-single-source.asciidoc[]
 include::rule-details/potential-openssh-backdoor-logging-activity.asciidoc[]
 include::rule-details/potential-outgoing-rdp-connection-by-unusual-process.asciidoc[]
 include::rule-details/potential-pass-the-hash-pth-attempt.asciidoc[]
@@ -996,7 +1018,7 @@ include::rule-details/potential-port-monitor-or-print-processor-registration-abu
 include::rule-details/potential-port-scanning-activity-from-compromised-host.asciidoc[]
 include::rule-details/potential-powershell-hacktool-script-by-author.asciidoc[]
 include::rule-details/potential-powershell-hacktool-script-by-function-names.asciidoc[]
-include::rule-details/potential-powershell-obfuscated-script.asciidoc[]
+include::rule-details/potential-powershell-obfuscated-script-via-high-entropy.asciidoc[]
 include::rule-details/potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc[]
 include::rule-details/potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc[]
 include::rule-details/potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc[]
@@ -1067,6 +1089,7 @@ include::rule-details/potential-suspicious-file-edit.asciidoc[]
 include::rule-details/potential-system-tampering-via-file-modification.asciidoc[]
 include::rule-details/potential-thc-tool-downloaded.asciidoc[]
 include::rule-details/potential-telnet-authentication-bypass-cve-2026-24061.asciidoc[]
+include::rule-details/potential-timestomp-in-executable-files.asciidoc[]
 include::rule-details/potential-toolshell-initial-exploit-cve-2025-53770-cve-2025-53771.asciidoc[]
 include::rule-details/potential-traffic-tunneling-using-qemu.asciidoc[]
 include::rule-details/potential-unauthorized-access-via-wildcard-injection-detected.asciidoc[]
@@ -1094,11 +1117,9 @@ include::rule-details/powershell-obfuscation-via-negative-index-string-reversal.
 include::rule-details/powershell-psreflect-script.asciidoc[]
 include::rule-details/powershell-script-block-logging-disabled.asciidoc[]
 include::rule-details/powershell-script-with-archive-compression-capabilities.asciidoc[]
-include::rule-details/powershell-script-with-discovery-capabilities.asciidoc[]
 include::rule-details/powershell-script-with-encryption-decryption-capabilities.asciidoc[]
 include::rule-details/powershell-script-with-log-clear-capabilities.asciidoc[]
 include::rule-details/powershell-script-with-password-policy-discovery-capabilities.asciidoc[]
-include::rule-details/powershell-script-with-remote-execution-capabilities-via-winrm.asciidoc[]
 include::rule-details/powershell-script-with-token-impersonation-capabilities.asciidoc[]
 include::rule-details/powershell-script-with-veeam-credential-access-capabilities.asciidoc[]
 include::rule-details/powershell-script-with-webcam-video-capture-capabilities.asciidoc[]
@@ -1200,7 +1221,6 @@ include::rule-details/sip-provider-modification.asciidoc[]
 include::rule-details/smb-windows-file-sharing-activity-to-the-internet.asciidoc[]
 include::rule-details/smb-connections-via-lolbin-or-untrusted-process.asciidoc[]
 include::rule-details/smtp-on-port-26-tcp.asciidoc[]
-include::rule-details/socks-traffic-from-an-unusual-process.asciidoc[]
 include::rule-details/ssh-authorized-keys-file-activity.asciidoc[]
 include::rule-details/ssh-authorized-keys-file-deletion.asciidoc[]
 include::rule-details/ssh-key-generated-via-ssh-keygen.asciidoc[]
@@ -1307,6 +1327,7 @@ include::rule-details/suspicious-certutil-commands.asciidoc[]
 include::rule-details/suspicious-child-execution-via-web-server.asciidoc[]
 include::rule-details/suspicious-child-process-of-adobe-acrobat-reader-update-service.asciidoc[]
 include::rule-details/suspicious-cmd-execution-via-wmi.asciidoc[]
+include::rule-details/suspicious-command-prompt-network-connection.asciidoc[]
 include::rule-details/suspicious-communication-app-child-process.asciidoc[]
 include::rule-details/suspicious-content-extracted-or-decompressed-via-funzip.asciidoc[]
 include::rule-details/suspicious-crontab-creation-or-modification.asciidoc[]
@@ -1371,7 +1392,6 @@ include::rule-details/suspicious-powershell-script.asciidoc[]
 include::rule-details/suspicious-print-spooler-file-deletion.asciidoc[]
 include::rule-details/suspicious-print-spooler-point-and-print-dll.asciidoc[]
 include::rule-details/suspicious-print-spooler-spl-file-created.asciidoc[]
-include::rule-details/suspicious-printspooler-service-executable-file-creation.asciidoc[]
 include::rule-details/suspicious-proc-pseudo-file-system-enumeration.asciidoc[]
 include::rule-details/suspicious-process-access-via-direct-system-call.asciidoc[]
 include::rule-details/suspicious-process-creation-calltrace.asciidoc[]
@@ -1483,7 +1503,6 @@ include::rule-details/unusual-country-for-an-aws-command.asciidoc[]
 include::rule-details/unusual-d-bus-daemon-child-process.asciidoc[]
 include::rule-details/unusual-dns-activity.asciidoc[]
 include::rule-details/unusual-dpkg-execution.asciidoc[]
-include::rule-details/unusual-discovery-activity-by-user.asciidoc[]
 include::rule-details/unusual-discovery-signal-alert-with-unusual-process-command-line.asciidoc[]
 include::rule-details/unusual-discovery-signal-alert-with-unusual-process-executable.asciidoc[]
 include::rule-details/unusual-executable-file-creation-by-a-system-critical-process.asciidoc[]
diff --git a/docs/detections/prebuilt-rules/rule-details/accepted-default-telnet-port-connection.asciidoc b/docs/detections/prebuilt-rules/rule-details/accepted-default-telnet-port-connection.asciidoc
index 3e7a41192b..2e7d769ea9 100644
--- a/docs/detections/prebuilt-rules/rule-details/accepted-default-telnet-port-connection.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/accepted-default-telnet-port-connection.asciidoc
@@ -41,7 +41,7 @@ This rule detects network events that may indicate the use of Telnet traffic. Te
 * Data Source: Suricata
 * Resources: Investigation Guide
 
-*Version*: 110
+*Version*: 111
 
 *Rule authors*: 
 
@@ -107,7 +107,7 @@ Telnet, a protocol for remote command-line access, is often used in legacy syste
 (event.dataset:(fortinet_fortigate.log or network_traffic.flow
         or sonicwall_firewall.log or suricata.eve or panw.panos)
     or event.category:(network or network_traffic))
-    and event.type:connection and not event.action:(
+    and event.type:(connection and not end) and not event.action:(
         flow_dropped or flow_denied or denied or deny or
         flow_terminated or timeout or Reject or network_flow)
     and destination.port:23
diff --git a/docs/detections/prebuilt-rules/rule-details/alerts-from-multiple-integrations-by-destination-address.asciidoc b/docs/detections/prebuilt-rules/rule-details/alerts-from-multiple-integrations-by-destination-address.asciidoc
index b8b81d99cd..03bc546fd5 100644
--- a/docs/detections/prebuilt-rules/rule-details/alerts-from-multiple-integrations-by-destination-address.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/alerts-from-multiple-integrations-by-destination-address.asciidoc
@@ -25,7 +25,7 @@ This rule uses alert data to determine when multiple alerts from different integ
 * Rule Type: Higher-Order Rule
 * Resources: Investigation Guide
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -91,7 +91,8 @@ The detection rule uses alert data to determine when multiple alerts from differ
 from .alerts-security.*
 
 // any alerts excluding low severity, threat_match and machine_learning rules 
-| where kibana.alert.rule.name is not null and destination.ip is not null and kibana.alert.risk_score > 21 and not kibana.alert.rule.type in ("threat_match", "machine_learning")
+| where kibana.alert.rule.name is not null and destination.ip is not null and kibana.alert.risk_score > 21 and not kibana.alert.rule.type in ("threat_match", "machine_learning") and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
 
 // group alerts by destination.ip and extract values of interest for alert triage
 | stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
diff --git a/docs/detections/prebuilt-rules/rule-details/alerts-from-multiple-integrations-by-source-address.asciidoc b/docs/detections/prebuilt-rules/rule-details/alerts-from-multiple-integrations-by-source-address.asciidoc
index fb8da84519..f5db0bbb6f 100644
--- a/docs/detections/prebuilt-rules/rule-details/alerts-from-multiple-integrations-by-source-address.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/alerts-from-multiple-integrations-by-source-address.asciidoc
@@ -25,7 +25,7 @@ This rule uses alert data to determine when multiple alerts from different integ
 * Rule Type: Higher-Order Rule
 * Resources: Investigation Guide
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -92,7 +92,8 @@ from .alerts-security.*
 
 // any alerts excluding low severity and the noisy ones
 | where kibana.alert.rule.name is not null and source.ip is not null and kibana.alert.risk_score > 21 and
-        not kibana.alert.rule.type in ("threat_match", "machine_learning")
+        not kibana.alert.rule.type in ("threat_match", "machine_learning") and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
 
 // group alerts by source.ip and extract values of interest for alert triage
 | stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
diff --git a/docs/detections/prebuilt-rules/rule-details/alerts-from-multiple-integrations-by-user-name.asciidoc b/docs/detections/prebuilt-rules/rule-details/alerts-from-multiple-integrations-by-user-name.asciidoc
index c48560811b..7a0b48443b 100644
--- a/docs/detections/prebuilt-rules/rule-details/alerts-from-multiple-integrations-by-user-name.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/alerts-from-multiple-integrations-by-user-name.asciidoc
@@ -25,7 +25,7 @@ This rule uses alert data to determine when multiple alerts from different integ
 * Rule Type: Higher-Order Rule
 * Resources: Investigation Guide
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -93,8 +93,18 @@ from .alerts-security.*
 // any alerts excluding low severity and the noisy ones
 | where kibana.alert.rule.name is not null and user.name is not null and kibana.alert.risk_score > 21 and
         not kibana.alert.rule.type in ("threat_match", "machine_learning") and 
-        not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0")
-
+        not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0") and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) and
+        // Top noisy influencing rules
+        // Agent Spoofing - Mismatched Agent ID
+        // Compression DLL Loaded by Unusual Process
+        // Process Termination followed by Deletion 
+        // Suspicious PrintSpooler Service Executable File Creation
+        // Potential PrintNightmare File Modification
+        // Multiple Vault Web Credentials Read
+        // Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score
+        not kibana.alert.rule.rule_id in ("3115bd2c-0baa-4df0-80ea-45e474b5ef93", "d197478e-39f0-4347-a22f-ba654718b148", "09443c92-46b3-45a4-8f25-383b028b258d", "5bb4a95d-5a08-48eb-80db-4c3a63ec78a8", "5e87f165-45c2-4b80-bfa5-52822552c997", "44fc462c-1159-4fa8-b1b7-9b6296ab4f96", "994e40aa-8c85-43de-825e-15f665375ee8")
+        
 // group alerts by user.name and extract values of interest for alert triage
 | stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
         Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
diff --git a/docs/detections/prebuilt-rules/rule-details/alerts-in-different-att-ck-tactics-by-host.asciidoc b/docs/detections/prebuilt-rules/rule-details/alerts-in-different-att-ck-tactics-by-host.asciidoc
index 3b00a3cfc6..347bb86083 100644
--- a/docs/detections/prebuilt-rules/rule-details/alerts-in-different-att-ck-tactics-by-host.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/alerts-in-different-att-ck-tactics-by-host.asciidoc
@@ -25,7 +25,7 @@ This rule uses alert data to determine when multiple alerts in different phases
 * Rule Type: Higher-Order Rule
 * Resources: Investigation Guide
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -95,8 +95,10 @@ from .alerts-security.*  metadata _id
         kibana.alert.rule.name IS NOT NULL and
         host.id is not null and event.dataset is not null and
         kibana.alert.rule.type != "threat_match" and
-        not kibana.alert.rule.name in ("Agent Spoofing - Mismatched Agent ID") and
-        not kibana.alert.rule.name like "Deprecated - *"
+        // Top noisy influencing rules
+        not kibana.alert.rule.name in ("Agent Spoofing - Mismatched Agent ID", "Compression DLL Loaded by Unusual Process", "Process Termination followed by Deletion", "Suspicious PrintSpooler Service Executable File Creation", "Potential PrintNightmare File Modification") and
+        not kibana.alert.rule.name like "Deprecated - *" and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
 
 // extract unique counts and values by host.id
 | stats Esql.alerts_count = COUNT(*),
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-guardduty-member-account-manipulation.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-guardduty-member-account-manipulation.asciidoc
new file mode 100644
index 0000000000..11bf29285b
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/aws-guardduty-member-account-manipulation.asciidoc
@@ -0,0 +1,163 @@
+[[aws-guardduty-member-account-manipulation]]
+=== AWS GuardDuty Member Account Manipulation
+
+Detects attempts to disassociate or manipulate Amazon GuardDuty member accounts within an AWS organization. In multi-account GuardDuty deployments, a delegated administrator account aggregates findings from member accounts. Adversaries may attempt to disassociate member accounts, delete member relationships, stop monitoring members, or delete pending invitations to break this centralized visibility. These actions can be precursors to or alternatives for deleting GuardDuty detectors entirely, allowing attackers to operate undetected in member accounts while the administrator account loses visibility. This rule identifies successful API calls that manipulate GuardDuty member relationships, which are rare in normal operations and warrant immediate investigation.
+
+*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/guardduty/latest/APIReference/API_DisassociateFromAdministratorAccount.html
+* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteMembers.html
+* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_StopMonitoringMembers.html
+* https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html
+* https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS GuardDuty
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating AWS GuardDuty Member Account Manipulation*
+
+
+In AWS Organizations with GuardDuty enabled, a delegated administrator account receives and aggregates security findings from all member accounts. This centralized visibility is critical for detecting threats across the organization. Adversaries who compromise a member account may attempt to break this relationship to operate without triggering alerts visible to the security team.
+
+This rule detects several API actions that manipulate GuardDuty member relationships:
+- `DisassociateFromMasterAccount` / `DisassociateFromAdministratorAccount`: Member account breaks its connection to the administrator
+- `DeleteMembers`: Administrator removes member accounts from GuardDuty
+- `StopMonitoringMembers`: Administrator stops monitoring specific member accounts without fully removing them
+- `DeleteInvitations`: Member account deletes pending invitations, preventing association
+
+These actions are extremely rare in normal operations and can indicate either a compromised account or an attacker preparing to disable GuardDuty entirely.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine who performed the action.
+  - Determine whether the action originated from a member account (disassociation) or the administrator account (deletion/stop monitoring).
+
+- **Review request context**
+  - Check `aws.cloudtrail.request_parameters` to identify which member accounts were affected.
+  - Determine the scope: single account or multiple accounts targeted.
+
+- **Analyze source and access patterns**
+  - Review `source.ip` and `user_agent.original` for anomalous access patterns.
+  - Check if the action occurred outside normal business hours or maintenance windows.
+
+- **Correlate with related activity**
+  - Search for subsequent `DeleteDetector` API calls in the affected member accounts.
+  - Look for other defense evasion indicators: CloudTrail modifications, Config rule deletions, Security Hub changes.
+  - Check for privilege escalation or credential access events preceding this action.
+
+- **Verify business justification**
+  - Confirm with the identified user or team whether there was a legitimate organizational change.
+  - Check for related change tickets or migration documentation.
+
+
+*False positive analysis*
+
+
+- **Organizational restructuring**
+  - Member relationships may change during account migrations or delegated administrator transitions.
+  - Validate against documented organizational changes.
+
+- **Account decommissioning**
+  - Accounts being retired may be removed from GuardDuty before closure.
+  - Confirm this aligns with account lifecycle management processes.
+
+
+*Response and remediation*
+
+
+- **Immediate containment**
+  - If unauthorized, immediately re-associate the affected member accounts with the administrator.
+  - For `StopMonitoringMembers`, use `StartMonitoringMembers` to restore visibility.
+
+- **Investigation**
+  - Audit the affected member accounts for suspicious activity during the visibility gap.
+  - Review CloudTrail for any actions taken while GuardDuty monitoring was disrupted.
+
+- **Hardening**
+  - Restrict `guardduty:DisassociateFromAdministratorAccount`, `guardduty:DeleteMembers`, and related permissions.
+  - Use SCPs to prevent member accounts from disassociating from GuardDuty administrators.
+  - Implement Security Hub controls to detect changes to GuardDuty organization configuration.
+
+
+*Additional information*
+
+- **https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html[AWS GuardDuty Multi-Account Documentation]**
+- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]**
+- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]**
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: "aws.cloudtrail"
+    and event.provider: "guardduty.amazonaws.com"
+    and event.action: (
+        "DisassociateFromAdministratorAccount" or
+        "DeleteMembers" or
+        "StopMonitoringMembers" or
+        "DeleteInvitations" or
+        "DisassociateMembers"
+    )
+    and event.outcome: "success"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
+* Sub-technique:
+** Name: Disable or Modify Tools
+** ID: T1562.001
+** Reference URL: https://attack.mitre.org/techniques/T1562/001/
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-oidc-provider-created-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-oidc-provider-created-by-rare-user.asciidoc
new file mode 100644
index 0000000000..90cf985fd2
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-oidc-provider-created-by-rare-user.asciidoc
@@ -0,0 +1,165 @@
+[[aws-iam-oidc-provider-created-by-rare-user]]
+=== AWS IAM OIDC Provider Created by Rare User
+
+Detects when an uncommon user or role creates an OpenID Connect (OIDC) Identity Provider in AWS IAM. OIDC providers enable web identity federation, allowing users authenticated by external identity providers (such as Google, GitHub, or custom OIDC-compliant providers) to assume IAM roles and access AWS resources. Adversaries who have gained administrative access may create rogue OIDC providers to establish persistent, federated access that survives credential rotation. This technique allows attackers to assume roles using tokens from an IdP they control. While OIDC provider creation is benign in some environments, it should still be validated against authorized infrastructure changes.
+
+*Rule type*: new_terms
+
+*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/IAM/latest/APIReference/API_CreateOpenIDConnectProvider.html
+* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html
+* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS IAM
+* Use Case: Identity and Access Audit
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating AWS IAM OIDC Provider Created by Rare User*
+
+
+OpenID Connect (OIDC) providers in AWS IAM enable web identity federation, allowing external identity providers to authenticate users who then assume IAM roles. Common legitimate use cases include GitHub Actions accessing AWS resources, Kubernetes pods authenticating to AWS, and web applications using social login.
+
+This rule detects the first time a specific user or role creates an OIDC provider within an account. While OIDC provider creation is common in some environments, a new user creating one for the first time warrants validation to ensure it's authorized.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` to determine who created the OIDC provider.
+  - Check if this user has created OIDC providers before in other accounts.
+
+- **Review the OIDC provider details**
+  - Examine `aws.cloudtrail.request_parameters` for the provider URL and client IDs.
+  - Identify the external IdP (e.g., GitHub, Google, custom provider).
+
+- **Validate business justification**
+  - Confirm with DevOps or platform teams whether this aligns with CI/CD pipeline setup.
+  - Check for related change tickets or infrastructure-as-code deployments.
+
+- **Check for follow-on activity**
+  - Search for `CreateRole` or `UpdateAssumeRolePolicy` calls that trust the new OIDC provider.
+  - Look for `AssumeRoleWithWebIdentity` calls using the newly created provider.
+
+- **Correlate with other suspicious activity**
+  - Check for preceding privilege escalation or credential access events.
+  - Look for other persistence mechanisms being established concurrently.
+
+
+*False positive analysis*
+
+
+- **CI/CD pipeline integration**
+  - GitHub Actions, GitLab CI, and other CI/CD systems commonly use OIDC for AWS authentication.
+  - Validate against known DevOps workflows.
+
+- **Kubernetes federation**
+  - EKS and self-managed Kubernetes clusters may use OIDC providers for pod identity.
+  - Confirm with platform engineering teams.
+
+- **Infrastructure-as-code deployments**
+  - Terraform, CloudFormation, or other IaC tools may create OIDC providers.
+  - Verify via CI/CD logs.
+
+
+*Response and remediation*
+
+
+- **Immediate containment**
+  - If unauthorized, delete the OIDC provider using `DeleteOpenIDConnectProvider`.
+  - Review and remove any IAM roles that trust the rogue provider.
+
+- **Investigation**
+  - Audit CloudTrail for any `AssumeRoleWithWebIdentity` calls using this provider.
+  - Review all IAM roles with web identity trust relationships.
+
+- **Hardening**
+  - Restrict `iam:CreateOpenIDConnectProvider` permissions to authorized roles.
+  - Implement SCPs to control OIDC provider creation in member accounts.
+  - Enable AWS Config rules to monitor identity provider configurations.
+
+
+*Additional information*
+
+- **https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html[AWS IAM OIDC Providers Documentation]**
+- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]**
+- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]**
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: "aws.cloudtrail"
+    and event.provider: "iam.amazonaws.com"
+    and event.action: "CreateOpenIDConnectProvider"
+    and event.outcome: "success"
+
+----------------------------------
+
+*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: Cloud Accounts
+** ID: T1078.004
+** Reference URL: https://attack.mitre.org/techniques/T1078/004/
+* 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: Trust Modification
+** ID: T1484.002
+** Reference URL: https://attack.mitre.org/techniques/T1484/002/
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-saml-provider-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-saml-provider-created.asciidoc
new file mode 100644
index 0000000000..982d8ded79
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-saml-provider-created.asciidoc
@@ -0,0 +1,161 @@
+[[aws-iam-saml-provider-created]]
+=== AWS IAM SAML Provider Created
+
+Detects the creation of a new SAML Identity Provider (IdP) in AWS IAM. SAML providers enable federated authentication between AWS and external identity providers, allowing users to access AWS resources using credentials from the external IdP. Adversaries who have gained administrative access may create rogue SAML providers to establish persistent, federated access to AWS accounts that survives credential rotation. This technique allows attackers to assume roles and access resources by forging SAML assertions from an IdP they control. Creating a SAML provider is a rare administrative action that should be closely monitored and validated against authorized infrastructure changes.
+
+*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/IAM/latest/APIReference/API_CreateSAMLProvider.html
+* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html
+* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS IAM
+* Use Case: Identity and Access Audit
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating AWS IAM SAML Provider Created*
+
+
+SAML (Security Assertion Markup Language) providers in AWS IAM enable federated authentication, allowing users from external identity providers to access AWS resources without separate AWS credentials. Creating a SAML provider establishes a trust relationship between AWS and the external IdP.
+
+This rule detects successful `CreateSAMLProvider` API calls. In most environments, SAML provider creation is extremely rare—typically only occurring during initial SSO setup or major infrastructure changes. An unauthorized SAML provider creation could enable an attacker to maintain persistent access by forging SAML assertions from an IdP they control.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` to determine who created the SAML provider.
+  - Verify whether this principal is authorized to manage identity federation.
+
+- **Review the SAML provider details**
+  - Examine `aws.cloudtrail.request_parameters` for the SAML provider name and metadata document.
+  - Identify the external IdP URL and signing certificate in the metadata.
+
+- **Validate business justification**
+  - Confirm with identity management or platform teams whether this aligns with planned SSO integration.
+  - Check for related change tickets or infrastructure-as-code deployments.
+
+- **Check for follow-on activity**
+  - Search for `CreateRole` or `UpdateAssumeRolePolicy` calls that reference the new SAML provider.
+  - Look for `AssumeRoleWithSAML` calls using the newly created provider.
+
+- **Correlate with other suspicious activity**
+  - Check for preceding privilege escalation or credential access events.
+  - Look for other persistence mechanisms being established concurrently.
+
+
+*False positive analysis*
+
+
+- **Planned SSO integration**
+  - SAML providers are created during initial setup of identity federation with Okta, Azure AD, or other IdPs.
+  - Validate against documented SSO integration projects.
+
+- **Infrastructure-as-code deployments**
+  - Terraform, CloudFormation, or other IaC tools may create SAML providers as part of automated deployments.
+  - Confirm via CI/CD logs.
+
+
+*Response and remediation*
+
+
+- **Immediate containment**
+  - If unauthorized, delete the SAML provider using `DeleteSAMLProvider`.
+  - Review and remove any IAM roles that trust the rogue provider.
+
+- **Investigation**
+  - Audit CloudTrail for any `AssumeRoleWithSAML` calls using this provider.
+  - Review all IAM roles with SAML trust relationships.
+
+- **Hardening**
+  - Restrict `iam:CreateSAMLProvider` permissions to a limited set of administrative roles.
+  - Implement SCPs to control SAML provider creation in member accounts.
+  - Enable AWS Config rules to monitor identity provider configurations.
+
+
+*Additional information*
+
+- **https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html[AWS IAM SAML Providers Documentation]**
+- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]**
+- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]**
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: "aws.cloudtrail"
+    and event.provider: "iam.amazonaws.com"
+    and event.action: "CreateSAMLProvider"
+    and event.outcome: "success"
+
+----------------------------------
+
+*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: Cloud Accounts
+** ID: T1078.004
+** Reference URL: https://attack.mitre.org/techniques/T1078/004/
+* 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: Trust Modification
+** ID: T1484.002
+** Reference URL: https://attack.mitre.org/techniques/T1484/002/
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc
new file mode 100644
index 0000000000..19f690d7a1
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc
@@ -0,0 +1,165 @@
+[[aws-sensitive-iam-operations-performed-via-cloudshell]]
+=== AWS Sensitive IAM Operations Performed via CloudShell
+
+Identifies sensitive AWS IAM operations performed via AWS CloudShell based on the user agent string. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. While convenient for administrators, CloudShell access from compromised console sessions can enable attackers to perform privileged operations without installing tools or using programmatic credentials. This rule detects high-risk actions such as creating IAM users, access keys, roles, or attaching policies when initiated from CloudShell, which may indicate post-compromise credential harvesting or privilege escalation activity.
+
+*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/cloudshell/latest/userguide/welcome.html
+* https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud
+* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS CloudTrail
+* Data Source: AWS IAM
+* Tactic: Persistence
+* Tactic: Privilege Escalation
+* Use Case: Threat Detection
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating AWS Sensitive IAM Operations Performed via CloudShell*
+
+
+AWS CloudShell is a browser-based shell environment that provides instant command-line access to AWS resources without requiring local CLI installation or credential configuration. While this is convenient for legitimate administrators, it also provides adversaries with a powerful tool if they gain access to a compromised AWS console session. Attackers can use CloudShell to perform sensitive operations without leaving artifacts on their local systems.
+
+This rule detects high-risk IAM operations performed via CloudShell, including credential creation, user management, and policy attachment. These actions are commonly seen in post-compromise scenarios where attackers establish persistence or escalate privileges.
+
+
+*Possible investigation steps*
+
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` to determine which IAM principal performed the action.
+  - Check `source.ip` and `source.geo` fields to verify the request origin matches expected administrator locations.
+  - Investigate the console login event that established the CloudShell session.
+
+- **Analyze the specific action**
+  - Review `event.action` to understand exactly what operation was performed.
+  - For `CreateAccessKey` or `CreateUser`, identify the target principal and assess whether this was authorized.
+  - For policy attachments, review which policies were attached and to which entities.
+
+- **Review request and response details**
+  - Examine `aws.cloudtrail.request_parameters` for specifics like user names, policy ARNs, or role configurations.
+  - Check `aws.cloudtrail.response_elements` for created resource identifiers.
+
+- **Correlate with surrounding activity**
+  - Search for preceding events such as `ConsoleLogin` from the same session or IP address.
+  - Look for MFA bypass indicators or unusual login patterns before CloudShell usage.
+  - Check for subsequent use of any created credentials or roles.
+
+- **Assess the broader context**
+  - Determine if this CloudShell usage pattern is typical for this user.
+  - Review recent access patterns for the console session that initiated CloudShell.
+
+
+*False positive analysis*
+
+
+- Routine administrative tasks using CloudShell are common in some organizations. Create baseline profiles for users who regularly use CloudShell.
+- Infrastructure automation testing may involve CloudShell for quick validation. Verify with the user.
+
+
+
+*Response and remediation*
+
+
+- If unauthorized, immediately terminate the console session and revoke any created credentials.
+- Rotate credentials for any IAM users or roles that may have been compromised.
+- Review and remove any unauthorized users, access keys, roles, or policy attachments.
+- Consider restricting CloudShell access via SCPs or IAM policies for sensitive accounts.
+- Implement session duration limits to reduce the window of opportunity for console session abuse.
+
+
+*Additional information*
+
+
+- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]**
+- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** 
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: "aws.cloudtrail"
+    and event.provider: "iam.amazonaws.com"
+    and event.action: (
+        "CreateAccessKey" or
+        "CreateUser" or
+        "AttachUserPolicy" or
+        "PutUserPolicy" or
+        "CreateRole" or
+        "AttachRolePolicy" or
+        "PutRolePolicy" or
+        "CreateInstanceProfile" or
+        "AddRoleToInstanceProfile"
+    )
+    and event.outcome: "success"
+    and user_agent.original: *CloudShell*
+
+----------------------------------
+
+*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: Cloud Account
+** ID: T1136.003
+** Reference URL: https://attack.mitre.org/techniques/T1136/003/
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Sub-technique:
+** Name: Additional Cloud Roles
+** ID: T1098.003
+** Reference URL: https://attack.mitre.org/techniques/T1098/003/
diff --git a/docs/detections/prebuilt-rules/rule-details/aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc
new file mode 100644
index 0000000000..15032dd535
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc
@@ -0,0 +1,145 @@
+[[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.
+
+*Rule type*: new_terms
+
+*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://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud
+* https://www.cisa.gov/sites/default/files/2023-11/aa23-320a_scattered_spider_0.pdf
+* https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS SSM
+* 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 AWS SSM Inventory Reconnaissance by Rare User*
+
+
+AWS Systems Manager (SSM) Inventory provides detailed information about managed EC2 instances, including installed 
+applications, network configurations, OS details, and patch compliance status. Threat actors, including Scattered 
+Spider (LUCR-3), leverage these APIs to discover targets for lateral movement.
+
+This rule detects the first time a specific user (identified by `cloud.account.id` and `user.name`) accesses SSM 
+inventory reconnaissance APIs or runs inventory collection commands. These APIs are typically used by automation 
+systems, not interactively by humans.
+
+
+*Possible investigation steps*
+
+
+- **Verify User Identity**: Check `aws.cloudtrail.user_identity.arn` or `user.name` to determine who performed the action.
+    - Is this a service account, automation role, or human user?
+    - Does this user typically interact with SSM or EC2 infrastructure?
+- **Review Source Context**: Examine `source.ip` and `source.geo` to determine where the request originated.
+    - Does the source IP match expected locations for this user?
+    - Is the source IP from an EC2 instance (potentially compromised) or an external location?
+- **Analyze User Agent**: Check `user_agent.original` for suspicious values.
+    - AWS CLI, SDK, or CloudShell usage from unexpected users is suspicious.
+    - Custom or unusual user agents may indicate attacker tooling.
+- **Correlate with Other Events**: Look for other reconnaissance or lateral movement activity from the same user.
+    - Check for `StartSession`, `SendCommand`, or other SSM execution APIs.
+    - Look for `GetCallerIdentity` calls which often precede reconnaissance.
+- **Review Timeline**: Investigate activity 30 minutes before and after this event.
+    - Was there an initial access event (e.g., console login, `AssumeRole`)?
+    - Did the user proceed to access secrets or attempt lateral movement?
+
+
+*False positive analysis*
+
+
+- Automation and Monitoring: Legitimate monitoring tools, asset management systems, or compliance scanners may query SSM inventory regularly. These should use dedicated service accounts.
+- Administrator Activity: Cloud administrators may occasionally query inventory for troubleshooting. Verify with the user whether this was intentional.
+- CI/CD Pipelines: Deployment pipelines may check patch compliance before deployments.
+- SSM Associations: The `AWS-GatherSoftwareInventory` document is normally deployed via IaC tools (Terraform, CloudFormation) or the AWS Console during initial setup. Interactive `CreateAssociation` calls outside of these contexts warrant investigation.
+
+
+*Response and remediation*
+
+
+- Immediate Verification: Contact the user to verify whether they performed this action intentionally.
+- Review Permissions: If unauthorized, review and restrict the user's IAM permissions following least privilege.
+- Investigate Credential Compromise: If the user did not perform this action, treat their credentials as compromised.
+    - Rotate access keys and session tokens.
+    - Review recent activity for data exfiltration or privilege escalation.
+- Enhanced Monitoring: Add the user or role to enhanced monitoring if suspicious activity is confirmed.
+
+
+*Additional information*
+
+- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** 
+- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** 
+- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]**
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: "aws.cloudtrail"
+    and event.provider: "ssm.amazonaws.com"
+    and (
+        event.action: ("GetInventory" or "GetInventorySchema" or "ListInventoryEntries" or "DescribeInstancePatches" or "ListCommands")
+        or (event.action: "CreateAssociation"
+            and aws.cloudtrail.request_parameters: *AWS-GatherSoftwareInventory*)
+    )
+    and not aws.cloudtrail.user_identity.type : "AWSService" 
+    and event.outcome: "success"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Discovery
+** ID: TA0007
+** Reference URL: https://attack.mitre.org/tactics/TA0007/
+* Technique:
+** Name: Cloud Service Dashboard
+** ID: T1538
+** Reference URL: https://attack.mitre.org/techniques/T1538/
+* Technique:
+** Name: Cloud Infrastructure Discovery
+** ID: T1580
+** Reference URL: https://attack.mitre.org/techniques/T1580/
diff --git a/docs/detections/prebuilt-rules/rule-details/bpf-program-or-map-load-via-bpftool.asciidoc b/docs/detections/prebuilt-rules/rule-details/bpf-program-or-map-load-via-bpftool.asciidoc
new file mode 100644
index 0000000000..d3b8bcd7fb
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/bpf-program-or-map-load-via-bpftool.asciidoc
@@ -0,0 +1,137 @@
+[[bpf-program-or-map-load-via-bpftool]]
+=== BPF Program or Map Load via bpftool
+
+Detects execution of bpftool commands used to load, attach, run, or pin eBPF programs, as well as create or update eBPF maps and links. These operations interact directly with the Linux eBPF subsystem and can modify kernel-level behavior. While commonly used by legitimate networking or observability tooling, unexpected or interactive usage may indicate eBPF-based rootkit activity, policy tampering, or unauthorized kernel instrumentation.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* auditbeat-*
+* endgame-*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+* logs-sentinel_one_cloud_funnel.*
+* logs-crowdstrike.fdr*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://manpages.ubuntu.com/manpages/jammy/man8/bpftool-prog.8.html
+* https://manpages.ubuntu.com/manpages/noble/man8/bpftool-map.8.html
+* https://man.archlinux.org/man/bpftool-link.8.en
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Defense Evasion
+* Threat: Rootkit
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Auditd Manager
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 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 BPF Program or Map Load via bpftool*
+
+
+This rule flags bpftool executions that load, attach, run, or pin eBPF programs and that create or pin maps/links, actions that can change kernel behavior without traditional user-space artifacts. Adversaries can use bpftool to load a malicious eBPF object, attach it to a tracepoint or traffic control hook, and pin the program and maps in bpffs so it persists and hides or filters activity across reboots.
+
+
+*Possible investigation steps*
+
+
+- Capture full command line, parent process, user context, TTY/session, and current working directory to determine whether execution was interactive administration or automated tooling.  
+- Enumerate loaded and pinned eBPF artifacts and their attachment points using `bpftool prog show`, `bpftool map show`, `bpftool link show`, and a filesystem review of `/sys/fs/bpf` to identify unexpected persistence.  
+- Identify the eBPF object/source used for the load (path, inode, hash, package origin) and retrieve a copy for analysis, including checking for recent writes or downloads in the same directory tree.  
+- Correlate the event time with system logs and other telemetry for follow-on activity such as privilege escalation, module loads, network filtering changes, or suspicious process hiding indicators.  
+- Hunt for persistence mechanisms that would reload the same eBPF program after reboot (systemd units/timers, cron, init scripts, container entrypoints) and validate against known legitimate observability/network stacks in the environment.
+
+
+*False positive analysis*
+
+
+- A system administrator or SRE may run `bpftool prog load/attach/pin` or `bpftool map create/pin` during planned troubleshooting or performance investigation to temporarily instrument kernel events and persist objects under `/sys/fs/bpf` for multi-step validation.  
+- A legitimate system service or boot-time automation may invoke `bpftool` to load and pin eBPF programs/maps as part of expected networking, security policy enforcement, or observability initialization, especially after upgrades or configuration changes that trigger reloading.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the host or container from the network and stop the initiating service/session, then detach any active hooks by removing pinned artifacts under `/sys/fs/bpf` and verifying with `bpftool prog show` and `bpftool link show` that the suspicious program/link is no longer attached.  
+- Preserve evidence by collecting the full `bpftool` command line and parent chain, a recursive copy of `/sys/fs/bpf`, and the exact eBPF object file used for the load (path, hash, permissions, timestamps) before deleting or modifying artifacts.  
+- Eradicate persistence by removing malicious eBPF pins, deleting or quarantining the associated `.o`/loader binaries, and disabling the boot-time mechanism that reloads them (systemd unit/timer, cron, init scripts, container entrypoint) followed by a controlled reboot to clear any remaining in-kernel state.  
+- Recover by restoring the system to a known-good configuration, validating expected networking/observability behavior, and monitoring that no new pinned programs/maps/links reappear under `/sys/fs/bpf` after reboot or service restarts.  
+- Escalate to incident response and kernel/rootkit specialists if the program attaches to security-relevant hooks (e.g., tracepoints/kprobes/LSM/tc) or if pinned objects reappear after removal, indicating an active persistence mechanism or compromised privileged runtime.  
+- Harden by restricting `bpftool` availability and access to bpffs, enforcing least-privilege for CAP_BPF/CAP_SYS_ADMIN, requiring signed/managed eBPF loaders, and enabling controls that limit eBPF usage to approved components in production images and hosts.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and
+event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+process.name == "bpftool" and (
+  (process.args == "prog" and process.args in ("load", "loadall", "attach", "run", "pin")) or
+  (process.args == "map" and process.args in ("create", "pin")) or
+  (process.args == "link" and process.args == "pin")
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Boot or Logon Autostart Execution
+** ID: T1547
+** Reference URL: https://attack.mitre.org/techniques/T1547/
+* Sub-technique:
+** Name: Kernel Modules and Extensions
+** ID: T1547.006
+** Reference URL: https://attack.mitre.org/techniques/T1547/006/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Rootkit
+** ID: T1014
+** Reference URL: https://attack.mitre.org/techniques/T1014/
diff --git a/docs/detections/prebuilt-rules/rule-details/bpf-program-tampering-via-bpftool.asciidoc b/docs/detections/prebuilt-rules/rule-details/bpf-program-tampering-via-bpftool.asciidoc
new file mode 100644
index 0000000000..10e4c0d71f
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/bpf-program-tampering-via-bpftool.asciidoc
@@ -0,0 +1,131 @@
+[[bpf-program-tampering-via-bpftool]]
+=== BPF Program Tampering via bpftool
+
+Detects execution of bpftool commands used to detach eBPF programs or links, or to delete or modify eBPF maps. These actions can disable, alter, or interfere with kernel-level instrumentation and enforcement mechanisms implemented through eBPF. In environments relying on eBPF-based networking, observability, or security controls, unexpected use of these operations may indicate defense evasion or runtime tampering.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* auditbeat-*
+* endgame-*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+* logs-sentinel_one_cloud_funnel.*
+* logs-crowdstrike.fdr*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://manpages.ubuntu.com/manpages/jammy/man8/bpftool-prog.8.html
+* https://manpages.ubuntu.com/manpages/noble/man8/bpftool-map.8.html
+* https://man.archlinux.org/man/bpftool-link.8.en
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Threat: Rootkit
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Auditd Manager
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*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 BPF Program Tampering via bpftool*
+
+
+This rule detects bpftool executions that detach eBPF programs/links or delete/update eBPF maps, actions that can silently disable kernel-level visibility and enforcement built on eBPF. Attackers use these operations to evade detection or weaken runtime controls by removing loaded probes or rewriting map contents that drive policy decisions. A common pattern is running bpftool to detach a program from a hook or detach a link shortly before other suspicious activity.
+
+
+*Possible investigation steps*
+
+
+- Pull the full bpftool command line and correlate it with the invoking user, session (TTY/SSH), parent process chain, and any preceding privilege escalation to determine whether it was interactive admin work or automated tampering.  
+- Capture current eBPF state (`bpftool prog show`, `bpftool link show`, `bpftool map show -j`) and compare with recent snapshots/logs to identify which program/link/map changed and what controls (sensor, CNI, LSM, XDP/TC) may have been impacted.  
+- Identify the affected attachment point by mapping the detached program/link ID to its hook (e.g., tc/xdp/cgroup/tracepoint/kprobe) and validate operational impact by checking for missing telemetry, policy gaps, or network behavior changes around the event time.  
+- Review audit/system logs and package history for installation or recent execution of bpftool, kernel/debug tooling, or custom eBPF loaders, and look for nearby suspicious binaries/scripts that could be orchestrating repeated detach/update actions.  
+- If malicious activity is suspected, preserve artifacts by exporting bpftool JSON output and relevant `/sys/fs/bpf` entries, then hunt for follow-on persistence or rootkit-like behavior (new eBPF loads, altered maps, hidden processes, unexpected kernel module activity) on the host.
+
+
+*False positive analysis*
+
+
+- A system administrator or SRE running bpftool during incident response or troubleshooting may detach a program/link or update/delete a map to temporarily disable an eBPF hook and validate whether it is causing network drops, performance regressions, or incorrect enforcement.
+- A maintenance workflow during kernel, CNI, or eBPF policy rollouts may use bpftool to detach and replace existing attachments or refresh map entries as part of a controlled upgrade/rollback, especially when reloading pinned objects under `/sys/fs/bpf`.
+
+
+*Response and remediation*
+
+
+- Contain by isolating the host from the network or restricting outbound access while preserving access for forensics if bpftool detach/map operations are unexpected or coincide with loss of eBPF-based enforcement/telemetry.  
+- Eradicate by stopping and removing the controlling process/script (inspect the bpftool parent chain and cron/systemd units), revoking the initiating account’s sudo/root access, and deleting any unauthorized pinned objects under `/sys/fs/bpf` after exporting them for evidence.  
+- Recover by reloading the approved eBPF components (agent/CNI/LSM/XDP/TC) from trusted packages or images, reattaching required programs/links, and restoring known-good map contents from backups or redeploying policy to repopulate maps.  
+- Escalate to incident response and platform owners immediately if repeated bpftool tampering persists after containment, you find unknown pinned maps/programs with suspicious names/owners, or multiple hosts show simultaneous detach/update activity.  
+- Harden by limiting bpftool availability (remove from production images where not needed), enforcing least-privilege on CAP_BPF/CAP_SYS_ADMIN and sudoers, and adding immutable monitoring of `/usr/sbin/bpftool` and `/sys/fs/bpf` plus periodic snapshots of `bpftool prog/link/map show` for drift detection.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and
+event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+process.name == "bpftool" and (
+  (process.args == "prog" and process.args == "detach") or
+  (process.args == "map" and process.args in ("delete", "update")) or
+  (process.args == "link" and process.args == "detach")
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
+* Sub-technique:
+** Name: Disable or Modify Tools
+** ID: T1562.001
+** Reference URL: https://attack.mitre.org/techniques/T1562/001/
+* Technique:
+** Name: Rootkit
+** ID: T1014
+** Reference URL: https://attack.mitre.org/techniques/T1014/
diff --git a/docs/detections/prebuilt-rules/rule-details/clearing-windows-console-history.asciidoc b/docs/detections/prebuilt-rules/rule-details/clearing-windows-console-history.asciidoc
index 65f15be149..f319a328a8 100644
--- a/docs/detections/prebuilt-rules/rule-details/clearing-windows-console-history.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/clearing-windows-console-history.asciidoc
@@ -49,7 +49,7 @@ Identifies when a user attempts to clear console history. An adversary may clear
 * Data Source: SentinelOne
 * Data Source: Crowdstrike
 
-*Version*: 317
+*Version*: 318
 
 *Rule authors*: 
 
@@ -114,9 +114,12 @@ process where host.os.type == "windows" and event.type == "start" and
     ?process.pe.original_file_name in ("PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE")
   ) and
   (
-    process.args : "*Clear-History*" or
-    (process.args : ("*Remove-Item*", "rm") and process.args : ("*ConsoleHost_history.txt*", "*(Get-PSReadlineOption).HistorySavePath*")) or
-    (process.args : "*Set-PSReadlineOption*" and process.args : "*SaveNothing*")
+    process.command_line : "*Clear-History*" or
+    (
+      process.command_line : ("*Remove-Item*", "* rm *") and
+      process.command_line : ("*ConsoleHost_history.txt*", "*(Get-PSReadlineOption).HistorySavePath*")
+    ) or
+    (process.command_line : "*Set-PSReadlineOption*" and process.command_line : "*SaveNothing*")
   )
 
 ----------------------------------
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 cd4b5adc2c..207b0245ed 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
@@ -42,7 +42,7 @@ Identifies PowerShell.exe or Cmd.exe execution spawning from Windows Script Host
 * Data Source: Elastic Endgame
 * Data Source: Crowdstrike
 
-*Version*: 207
+*Version*: 208
 
 *Rule authors*: 
 
@@ -110,7 +110,25 @@ process where host.os.type == "windows" and event.type == "start" 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")
+  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 event.dataset : ("windows.sysmon_operational", "windows.sysmon")
+  ) 
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/connection-to-common-large-language-model-endpoints.asciidoc b/docs/detections/prebuilt-rules/rule-details/connection-to-common-large-language-model-endpoints.asciidoc
index 48bd9ab911..c9e63bebc6 100644
--- a/docs/detections/prebuilt-rules/rule-details/connection-to-common-large-language-model-endpoints.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/connection-to-common-large-language-model-endpoints.asciidoc
@@ -31,6 +31,7 @@ Identifies DNS queries to known Large Language Model domains by unsigned binarie
 
 * Domain: Endpoint
 * OS: Windows
+* OS: macOS
 * Use Case: Threat Detection
 * Tactic: Command and Control
 * Resources: Investigation Guide
@@ -39,7 +40,7 @@ Identifies DNS queries to known Large Language Model domains by unsigned binarie
 * Data Source: SentinelOne
 * Data Source: Sysmon
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -96,16 +97,19 @@ Identifies DNS queries to known Large Language Model domains by unsigned binarie
 
 [source, js]
 ----------------------------------
-network where host.os.type == "windows" and dns.question.name != null and
+network where host.os.type in ("macos", "windows") and dns.question.name != null and
 (
   process.name : ("MSBuild.exe", "mshta.exe", "wscript.exe", "powershell.exe", "pwsh.exe", "msiexec.exe", "rundll32.exe",
-  "bitsadmin.exe", "InstallUtil.exe", "RegAsm.exe", "vbc.exe", "RegSvcs.exe", "python.exe", "regsvr32.exe", "dllhost.exe",
-  "node.exe", "javaw.exe", "java.exe", "*.pif", "*.com") or
+  "bitsadmin.exe", "InstallUtil.exe", "RegAsm.exe", "vbc.exe", "RegSvcs.exe", "regsvr32.exe", "dllhost.exe",
+  "node.exe", "javaw.exe", "java.exe", "*.pif", "*.com", "python*", "osascript", "Script Editor", "curl", "curl.exe", "deno", 
+  "deno.exe", "node", "bun", "bun.exe") or
 
   ?process.code_signature.subject_name : ("AutoIt Consulting Ltd", "OpenJS Foundation", "Python Software Foundation") or
 
   (
-    process.executable : ("?:\\Users\\*.exe", "?:\\ProgramData\\*.exe") and
+    process.executable : ("?:\\Users\\*.exe", "?:\\ProgramData\\*.exe", "/Users/Shared/*", "/Library/WebServer/*", 
+                          "/Users/*/Library/WebServer/*", "/Library/Graphics/*", "/Users/*/Library/Graphics/*", "/Library/Fonts/*", 
+                          "/Users/*/Library/Fonts/*", "/private/var/root/Library/HTTPStorages/*", "/tmp/*", "/var/tmp/*", "/private/tmp/*") and
     (?process.code_signature.trusted == false or ?process.code_signature.exists == false)
   )
  ) and
@@ -148,7 +152,10 @@ network where host.os.type == "windows" and dns.question.name != null and
     "perplexity.ai",
     "poe.com",
     "chat.forefront.ai",
-    "chat.deepseek.com"
+    "chat.deepseek.com",
+
+    // OpenClaw
+    "openclaw.ai"
   ) and
 
   not process.executable : (
diff --git a/docs/detections/prebuilt-rules/rule-details/correlated-alerts-on-similar-user-identities.asciidoc b/docs/detections/prebuilt-rules/rule-details/correlated-alerts-on-similar-user-identities.asciidoc
new file mode 100644
index 0000000000..b4f82c25dc
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/correlated-alerts-on-similar-user-identities.asciidoc
@@ -0,0 +1,162 @@
+[[correlated-alerts-on-similar-user-identities]]
+=== Correlated Alerts on Similar User Identities
+
+This rule correlates alerts from multiple integrations and event categories that involve different user.name values which may represent the same real-world identity. It uses an LLM-based similarity analysis to evaluate whether multiple user identifiers (e.g. naming variations, formats, aliases, or domain differences) likely belong to the same person.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 30m
+
+*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.elastic.co/docs/reference/query-languages/esql/esql-commands#esql-completion
+* https://www.elastic.co/security-labs/elastic-advances-llm-security
+
+*Tags*: 
+
+* Domain: Identity
+* Domain: LLM
+* Use Case: Threat Detection
+* Use Case: Identity and Access Audit
+* Resources: Investigation Guide
+* Rule Type: Higher-Order Rule
+
+*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, analysts should validate findings against their environment and identity architecture.
+
+
+*Investigating Correlated Alerts on Similar User Identities*
+
+
+This rule identifies alerts from multiple integrations and event categories involving different `user.name` values that may represent the same real-world identity.
+An LLM is used to assess string similarity and naming patterns to determine whether multiple user identifiers likely belong to the same person, which may indicate account compromise, credential abuse, or identity misuse across systems.
+
+
+*Possible investigation steps*
+
+
+- Review the correlated `user.name` values and validate whether they represent naming variations, aliases, or identity mappings.
+- Examine the LLM output fields (`verdict`, `confidence`, `summary`) as decision support, not ground truth.
+- Analyze the diversity of alert sources, event categories, and detection rules involved.
+- Reconstruct the alert timeline to identify potential stages such as initial access, lateral movement, privilege escalation, or persistence.
+- Correlate with authentication logs, IAM/SSO telemetry, EDR data, and network logs to identify shared sessions, IPs, devices, or hosts.
+- Validate identities against directory services, identity providers, and federation mappings.
+
+
+*False positive analysis*
+
+
+- Identity format variations across systems (e.g., `first.last`, `flast`, `user@domain`).
+- Federated identity mappings between on-prem, cloud, and SaaS platforms.
+- Service, automation, and CI/CD accounts with similar naming conventions.
+- Separate admin and standard user accounts for the same individual.
+- Shared credentials or naming templates in development and test environments.
+
+
+*Response and remediation*
+
+
+- Temporarily disable or suspend correlated accounts if compromise is suspected.
+- Revoke active sessions, tokens, and credentials.
+- Investigate access scope, privileges, and lateral movement paths.
+- Perform endpoint and identity forensics to identify persistence mechanisms.
+- Remediate IAM misconfigurations and federation issues.
+- Enhance monitoring for identity correlation, credential misuse, and cross-platform abuse..
+
+==== Setup
+
+
+
+*Setup*
+
+
+
+*LLM Configuration*
+
+
+This rule uses the ES|QL COMPLETION command with Elastic's managed General Purpose LLM v2 (`.gp-llm-v2-completion`),
+which is available out-of-the-box in Elastic Cloud deployments with an appropriate subscription.
+
+To use a different LLM provider (Azure OpenAI, Amazon Bedrock, OpenAI, or Google Vertex), configure a connector
+following the https://www.elastic.co/docs/explore-analyze/ai-features/llm-guides/llm-connectors[LLM connector documentation]
+and update the `inference_id` parameter in the query to reference your configured connector.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from .alerts-security.*
+
+// truncate timestamp to 5-minute window
+| eval Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp)
+
+// high severity alerts excluding system standard user.ids
+| where kibana.alert.rule.name is not null and user.name is not null and kibana.alert.risk_score >= 73 and kibana.alert.workflow_status == "open" and 
+        not kibana.alert.rule.type in ("threat_match", "machine_learning") and
+        not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0")
+
+// group alerts by short time window and extract values of interest for alert triage
+| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
+        Esql.user_name_distinct_count = COUNT_DISTINCT(user.name),
+        Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
+        Esql.event_category_distinct_count = COUNT_DISTINCT(event.category),
+        Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),
+        Esql.event_module_values = VALUES(event.module),
+        Esql.rule_name_values = VALUES(kibana.alert.rule.name),
+        Esql.message_values = VALUES(message),
+        Esql.event_category_values = VALUES(event.category),
+        Esql.event_action_values = VALUES(event.action),
+        Esql.source_ip_values = VALUES(source.ip),
+        Esql.destination_ip_values = VALUES(destination.ip),
+        Esql.host_id_values = VALUES(host.id),
+        Esql.agent_id_values = VALUES(agent.id),
+        Esql.rule_severity_values = VALUES(kibana.alert.risk_score),
+        Esql.user_name_values = VALUES(user.name) by Esql.time_window_date_trunc
+
+// filter for alerts from different integrations with unique categories
+| where Esql.event_module_distinct_count >= 2 and Esql.user_name_distinct_count >= 2 and Esql.event_category_distinct_count >= 2
+
+// build context for LLM analysis
+| eval users_list = MV_CONCAT(Esql.user_name_values, ",")
+
+// LLM analysis
+| eval instructions = "Analyze the provided user names and return a boolean value true if at least 2 of them are similar and they may belong to the same human identify or false if not, do not compare user names that may look like service accounts. If the list of users has more than 2 users and only 2 of them are similar consider this as true. Structure the output as follows: verdict=<verdict> confidence=<score> summary=<short reason max 500 words> without any other response statements on a single line."
+| eval prompt = CONCAT("User identities extracted from different alerts: ", users_list, instructions)
+| COMPLETION triage_result = prompt WITH { "inference_id": ".gp-llm-v2-completion"}
+
+// parse LLM response
+| DISSECT triage_result """verdict=%{Esql.verdict} confidence=%{Esql.confidence} summary=%{Esql.summary}"""
+
+// filter for similar user values
+| where TO_LOWER(Esql.verdict) == "true"
+| keep Esql.*
+
+----------------------------------
diff --git a/docs/detections/prebuilt-rules/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 1f314b8265..df12baa478 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
@@ -36,7 +36,7 @@ Detects modifications in the msDS-ManagedAccountPrecededByLink attribute of a de
 * Data Source: Windows Security Event Logs
 * Resources: Investigation Guide
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-adobe-hijack-persistence.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-adobe-hijack-persistence.asciidoc
new file mode 100644
index 0000000000..5b2f905adb
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-adobe-hijack-persistence.asciidoc
@@ -0,0 +1,153 @@
+[[deprecated-adobe-hijack-persistence]]
+=== Deprecated - Adobe Hijack Persistence
+
+Detects writing executable files that will be automatically launched by Adobe on launch.
+
+*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*: 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://twitter.com/pabraeken/status/997997818362155008
+
+*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: SentinelOne
+* Data Source: Microsoft Defender for Endpoint
+* Data Source: Crowdstrike
+
+*Version*: 419
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Deprecated - Adobe Hijack Persistence*
+
+
+Attackers can replace the `RdrCEF.exe` executable with their own to maintain their access, which will be launched whenever Adobe Acrobat Reader is executed.
+
+> **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.
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
+- 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.
+
+
+*False positive analysis*
+
+
+- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+
+
+*Response and remediation*
+
+
+- Initiate the incident response process based on the outcome of the triage.
+- Isolate the involved host to prevent further post-compromise behavior.
+- If the triage identified malware, search the environment for additional compromised hosts.
+  - Implement temporary network rules, procedures, and segmentation to contain the malware.
+  - Stop suspicious processes.
+  - Immediately block the identified indicators of compromise (IoCs).
+  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
+- Remove and block malicious artifacts identified during triage.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
+- 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).
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+file where host.os.type == "windows" and event.type == "creation" and
+  file.path : (
+    "?:\\Program Files (x86)\\Adobe\\Acrobat Reader DC\\Reader\\AcroCEF\\RdrCEF.exe",
+    "?:\\Program Files\\Adobe\\Acrobat Reader DC\\Reader\\AcroCEF\\RdrCEF.exe",
+
+    /* Crowdstrike specific condition as it uses NT Object paths */
+    "\\Device\\HarddiskVolume*\\Program Files (x86)\\Adobe\\Acrobat Reader DC\\Reader\\AcroCEF\\RdrCEF.exe",
+    "\\Device\\HarddiskVolume*\\Program Files\\Adobe\\Acrobat Reader DC\\Reader\\AcroCEF\\RdrCEF.exe"
+  ) and
+  not process.name : ("msiexec.exe", "AdobeARM.exe")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Compromise Host Software Binary
+** ID: T1554
+** Reference URL: https://attack.mitre.org/techniques/T1554/
+* 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/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-encoded-executable-stored-in-the-registry.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-encoded-executable-stored-in-the-registry.asciidoc
new file mode 100644
index 0000000000..684f42b3ad
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-encoded-executable-stored-in-the-registry.asciidoc
@@ -0,0 +1,125 @@
+[[deprecated-encoded-executable-stored-in-the-registry]]
+=== Deprecated - Encoded Executable Stored in the Registry
+
+Identifies registry write modifications to hide an encoded portable executable. This could be indicative of adversary defense evasion by avoiding the storing of malicious content directly on disk.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.registry-*
+* endgame-*
+* logs-windows.sysmon_operational-*
+* logs-sentinel_one_cloud_funnel.*
+* winlogbeat-*
+* logs-m365_defender.event-*
+* logs-crowdstrike.fdr*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* 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 for Endpoint
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 416
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Deprecated - Encoded Executable Stored in the Registry*
+
+
+Windows Registry is a hierarchical database storing low-level settings for the OS and applications. Adversaries exploit it to hide encoded executables, evading detection by avoiding direct disk storage. The detection rule identifies suspicious registry modifications, specifically targeting encoded patterns indicative of hidden executables, thus flagging potential defense evasion tactics.
+
+
+*Possible investigation steps*
+
+
+- Review the registry path and key where the modification was detected to understand the context and potential impact on the system.
+- Analyze the encoded data string "TVqQAAMAAAAEAAAA*" to determine if it corresponds to a known malicious executable or pattern.
+- Check the modification timestamp to correlate with any other suspicious activities or events on the system around the same time.
+- Investigate the process or user account responsible for the registry modification to assess if it is associated with legitimate activity or known threats.
+- Cross-reference the alert with other data sources such as Sysmon, Microsoft Defender for Endpoint, or SentinelOne for additional context or corroborating evidence of malicious behavior.
+- Evaluate the system's network activity and connections during the time of the registry modification to identify any potential command and control communications or data exfiltration attempts.
+
+
+*False positive analysis*
+
+
+- Legitimate software installations or updates may write encoded executables to the registry as part of their normal operation. Users can create exceptions for known software by identifying their specific registry paths and excluding them from the detection rule.
+- Security tools and system management software might store encoded data in the registry for legitimate purposes. Review the registry paths and data associated with these tools and exclude them if they are verified as non-threatening.
+- Custom scripts or enterprise applications developed in-house may use encoded executables in the registry for deployment or configuration purposes. Work with development teams to identify these scripts and add exceptions for their registry modifications.
+- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking potential threats.
+
+
+*Response and remediation*
+
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the encoded executable.
+- Remove the malicious registry entry by using a trusted registry editor or automated script to ensure the encoded executable is no longer stored in the registry.
+- Conduct a full system scan using updated antivirus and anti-malware tools to identify and remove any additional threats or remnants of the attack.
+- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through cleaning.
+- Monitor the system and network for any signs of re-infection or similar registry modifications, adjusting detection rules if necessary to enhance future threat identification.
+- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further analysis and to determine if additional systems are affected.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+registry where host.os.type == "windows" and
+/* update here with encoding combinations */
+ registry.data.strings : "TVqQAAMAAAAEAAAA*"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* 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: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-m365-exchange-dlp-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-m365-exchange-dlp-policy-deleted.asciidoc
new file mode 100644
index 0000000000..751830e446
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-m365-exchange-dlp-policy-deleted.asciidoc
@@ -0,0 +1,113 @@
+[[deprecated-m365-exchange-dlp-policy-deleted]]
+=== Deprecated - M365 Exchange DLP Policy Deleted
+
+Identifies when a Data Loss Prevention (DLP) policy is removed in Microsoft 365. An adversary may remove a DLP policy to evade existing DLP monitoring.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+* filebeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/powershell/module/exchange/remove-dlppolicy?view=exchange-ps
+* https://docs.microsoft.com/en-us/microsoft-365/compliance/data-loss-prevention-policies?view=o365-worldwide
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: Microsoft 365
+* Use Case: Configuration Audit
+* Tactic: Defense Evasion
+* Resources: Investigation Guide
+
+*Version*: 212
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Deprecated - M365 Exchange DLP Policy Deleted*
+
+
+Data Loss Prevention (DLP) in Microsoft 365 Exchange is crucial for safeguarding sensitive information by monitoring and controlling data transfers. Adversaries may exploit this by removing DLP policies to bypass data monitoring, facilitating unauthorized data exfiltration. The detection rule identifies such actions by analyzing audit logs for specific events indicating successful DLP policy removal, thus alerting security teams to potential defense evasion tactics.
+
+
+*Possible investigation steps*
+
+
+- Review the audit logs for the specific event.action "Remove-DlpPolicy" to identify the user account responsible for the action.
+- Check the event.outcome field to confirm the success of the DLP policy removal and gather additional context from related logs.
+- Investigate the user account's recent activities in Microsoft 365 to identify any other suspicious actions or anomalies.
+- Verify if the removed DLP policy was critical for protecting sensitive data and assess the potential impact of its removal.
+- Contact the user or their manager to confirm if the DLP policy removal was authorized and legitimate.
+- Examine any recent changes in permissions or roles for the user account to determine if they had the necessary privileges to remove the DLP policy.
+
+
+*False positive analysis*
+
+
+- Routine administrative changes to DLP policies by authorized personnel can trigger alerts. To manage this, maintain a list of authorized users and correlate their activities with policy changes to verify legitimacy.
+- Scheduled updates or maintenance activities might involve temporary removal of DLP policies. Document these activities and create exceptions in the monitoring system for the duration of the maintenance window.
+- Automated scripts or third-party tools used for policy management can inadvertently trigger false positives. Ensure these tools are properly documented and their actions are logged to differentiate between legitimate and suspicious activities.
+- Changes in organizational policy or compliance requirements may necessitate the removal of certain DLP policies. Keep a record of such changes and adjust the monitoring rules to accommodate these legitimate actions.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected Microsoft 365 account to prevent further unauthorized actions and data exfiltration.
+- Review the audit logs to identify any additional unauthorized changes or suspicious activities associated with the account or related accounts.
+- Restore the removed DLP policy from a backup or recreate it based on the organization's standard configuration to re-enable data monitoring.
+- Conduct a thorough investigation to determine the scope of data exposure and identify any data that may have been exfiltrated during the period the DLP policy was inactive.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional containment measures are necessary.
+- Implement enhanced monitoring and alerting for similar events, focusing on unauthorized changes to security policies and configurations.
+- Review and strengthen access controls and permissions for accounts with the ability to modify DLP policies to prevent unauthorized changes in the future.
+
+==== Setup
+
+
+The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Remove-DlpPolicy" and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish.asciidoc
new file mode 100644
index 0000000000..3765943870
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish.asciidoc
@@ -0,0 +1,123 @@
+[[deprecated-m365-security-compliance-email-reported-by-user-as-malware-or-phish]]
+=== Deprecated - M365 Security Compliance Email Reported by User as Malware or Phish
+
+Detects the occurrence of emails reported as Phishing or Malware by Users. Security Awareness training is essential to stay ahead of scammers and threat actors, as security products can be bypassed, and the user can still receive a malicious message. Educating users to report suspicious messages can help identify gaps in security controls and prevent malware infections and Business Email Compromise attacks.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+* filebeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://support.microsoft.com/en-us/office/use-the-report-message-add-in-b5caa9f1-cdf3-4443-af8c-ff724ea719d2?ui=en-us&rs=en-us&ad=us
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: Microsoft 365
+* Tactic: Initial Access
+* 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 Deprecated - M365 Security Compliance Email Reported by User as Malware or Phish*
+
+
+Microsoft 365's email services are integral to business communication, but they can be exploited by adversaries through phishing or malware-laden emails. Attackers may bypass security measures, reaching users who might unwittingly engage with malicious content. The detection rule leverages user reports of suspicious emails, correlating them with security events to identify potential threats, thus enhancing the organization's ability to respond to phishing attempts and malware distribution.
+
+
+*Possible investigation steps*
+
+
+- Review the details of the alert triggered by the rule "Email reported by user as malware or phish" in the SecurityComplianceCenter to understand the context and specifics of the reported email.
+- Examine the event dataset from o365.audit to gather additional information about the email, such as sender, recipient, subject line, and any attachments or links included.
+- Correlate the reported email with other security events or alerts to identify any patterns or related incidents that might indicate a broader phishing campaign or malware distribution attempt.
+- Check the user's report against known phishing or malware indicators, such as suspicious domains or IP addresses, using threat intelligence sources to assess the credibility of the threat.
+- Investigate the user's activity following the receipt of the email to determine if any actions were taken that could have compromised the system, such as clicking on links or downloading attachments.
+- Assess the effectiveness of current security controls and awareness training by analyzing how the email bypassed existing defenses and was reported by the user.
+
+
+*False positive analysis*
+
+
+- User-reported emails from trusted internal senders can trigger false positives. Encourage users to verify the sender's identity before reporting and consider adding these senders to an allowlist if they are consistently flagged.
+- Automated system notifications or newsletters may be mistakenly reported as phishing. Educate users on recognizing legitimate automated communications and exclude these sources from triggering alerts.
+- Emails containing marketing or promotional content from known vendors might be reported as suspicious. Train users to differentiate between legitimate marketing emails and phishing attempts, and create exceptions for verified vendors.
+- Frequent reports of emails from specific domains that are known to be safe can lead to unnecessary alerts. Implement domain-based exceptions for these trusted domains to reduce false positives.
+- Encourage users to provide detailed reasons for reporting an email as suspicious, which can help in refining detection rules and reducing false positives over time.
+
+
+*Response and remediation*
+
+
+- Isolate the affected email account to prevent further interaction with potentially malicious content and to stop any ongoing unauthorized access.
+- Quarantine the reported email and any similar emails identified in the system to prevent other users from accessing them.
+- Conduct a thorough scan of the affected user's device and network for any signs of malware or unauthorized access, using endpoint detection and response tools.
+- Reset the credentials of the affected user account and any other accounts that may have been compromised to prevent further unauthorized access.
+- Notify the security team and relevant stakeholders about the incident, providing details of the threat and actions taken, to ensure coordinated response efforts.
+- Review and update email filtering and security policies to address any identified gaps that allowed the malicious email to bypass existing controls.
+- Monitor for any further suspicious activity related to the incident, using enhanced logging and alerting mechanisms to detect similar threats in the future.
+
+==== Setup
+
+
+The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:o365.audit and event.provider:SecurityComplianceCenter and event.action:AlertTriggered and rule.name:"Email reported by user as malware or phish"
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc
new file mode 100644
index 0000000000..f5f28651dc
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc
@@ -0,0 +1,117 @@
+[[deprecated-m365-security-compliance-potential-ransomware-activity]]
+=== Deprecated - M365 Security Compliance Potential Ransomware Activity
+
+Identifies when Microsoft Cloud App Security flags potential ransomware activity in Microsoft 365. This rule detects events where the Security Compliance Center reports a "Ransomware activity" or "Potential ransomware activity" alert, which may indicate file encryption, mass file modifications, or uploads of ransomware-infected files to cloud services such as SharePoint or OneDrive.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+* filebeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy
+* https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference
+* https://www.microsoft.com/en-us/security/blog/threat-intelligence/ransomware/
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: SaaS
+* Data Source: Microsoft 365
+* Data Source: Microsoft 365 Audit Logs
+* Use Case: Threat Detection
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 213
+
+*Rule authors*: 
+
+* Elastic
+* Austin Songer
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Deprecated - M365 Security Compliance Potential Ransomware Activity*
+
+
+Microsoft 365's cloud services can be exploited by adversaries to distribute ransomware by uploading infected files. This detection rule leverages Microsoft Cloud App Security to identify suspicious uploads, focusing on successful events flagged as potential ransomware activity. By monitoring specific event datasets and actions, it helps security analysts pinpoint and mitigate ransomware threats, aligning with MITRE ATT&CK's impact tactics.
+
+
+*Possible investigation steps*
+
+
+- Identify the affected user account and review their recent file activity in Microsoft 365 for signs of mass file encryption, renaming with unusual extensions, or rapid file modifications.
+- Examine the file names, extensions, and metadata of the flagged uploads to determine if they match known ransomware patterns (e.g., `.encrypted`, `.locked`, or ransom note files like `README.txt` or `DECRYPT_INSTRUCTIONS.html`).
+- Correlate this alert with other security events from the same user or source IP, such as impossible travel, failed login attempts, or suspicious inbox rules, to identify potential account compromise.
+- Check whether the affected user's endpoint shows signs of ransomware execution, such as high CPU usage, mass file system changes, or known ransomware process names.
+- Review SharePoint or OneDrive file version history to determine the scope of encrypted or modified files and whether recovery via version rollback is possible.
+- Contact the user to verify whether the activity is legitimate or if their account or device may have been compromised.
+
+
+*False positive analysis*
+
+
+- Legitimate file uploads by trusted users may trigger alerts if the files are mistakenly flagged as ransomware. To manage this, create exceptions for specific users or groups who frequently upload large volumes of files.
+- Automated backup processes that upload encrypted files to the cloud can be misidentified as ransomware activity. Exclude these processes by identifying and whitelisting the associated service accounts or IP addresses.
+- Certain file types or extensions commonly used in business operations might be flagged. Review and adjust the detection rule to exclude these file types if they are consistently identified as false positives.
+- Collaborative tools that sync files across devices may cause multiple uploads that appear suspicious. Monitor and exclude these tools by recognizing their typical behavior patterns and adjusting the rule settings accordingly.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected user account to prevent further uploads and potential spread of ransomware within the cloud environment.
+- Quarantine the uploaded files flagged as potential ransomware to prevent access and further distribution.
+- Conduct a thorough scan of the affected user's devices and cloud storage for additional signs of ransomware or other malicious activity.
+- Notify the security operations team to initiate a deeper investigation into the source and scope of the ransomware activity.
+- Restore any affected files from secure backups, ensuring that the backups are clean and free from ransomware.
+- Review and update access controls and permissions for the affected user and related accounts to minimize the risk of future incidents.
+- Escalate the incident to senior security management and, if necessary, involve legal or compliance teams to assess any regulatory implications.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:o365.audit and
+    event.provider:SecurityComplianceCenter and
+    event.category:web and
+    rule.name:("Ransomware activity" or "Potential ransomware activity") and
+    event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Data Encrypted for Impact
+** ID: T1486
+** Reference URL: https://attack.mitre.org/techniques/T1486/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc
new file mode 100644
index 0000000000..ae963bc3e6
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc
@@ -0,0 +1,117 @@
+[[deprecated-m365-security-compliance-unusual-volume-of-file-deletion]]
+=== Deprecated - M365 Security Compliance Unusual Volume of File Deletion
+
+Identifies that a user has deleted an unusually large volume of files as reported by Microsoft Cloud App Security.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+* filebeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy
+* https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: Microsoft 365
+* Use Case: Configuration Audit
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 212
+
+*Rule authors*: 
+
+* Austin Songer
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Deprecated - M365 Security Compliance Unusual Volume of File Deletion*
+
+
+Microsoft 365's cloud environment facilitates file storage and collaboration, but its vast data handling capabilities can be exploited by adversaries for data destruction. Attackers may delete large volumes of files to disrupt operations or cover their tracks. The detection rule leverages audit logs to identify anomalies in file deletion activities, flagging successful, unusual deletion volumes as potential security incidents, thus enabling timely investigation and response.
+
+
+*Possible investigation steps*
+
+
+- Review the audit logs for the specific user associated with the alert to confirm the volume and context of the file deletions, focusing on entries with event.action:"Unusual volume of file deletion" and event.outcome:success.
+- Correlate the timestamps of the deletion events with other activities in the user's account to identify any suspicious patterns or anomalies, such as unusual login locations or times.
+- Check for any recent changes in user permissions or roles that might explain the ability to delete a large volume of files, ensuring these align with the user's typical responsibilities.
+- Investigate any recent security alerts or incidents involving the same user or related accounts to determine if this activity is part of a broader attack or compromise.
+- Contact the user or their manager to verify if the deletions were intentional and authorized, and gather any additional context that might explain the activity.
+- Assess the impact of the deletions on business operations and data integrity, and determine if any recovery actions are necessary to restore critical files.
+
+
+*False positive analysis*
+
+
+- High-volume legitimate deletions during data migration or cleanup projects can trigger false positives. To manage this, create exceptions for users or groups involved in these activities during the specified time frame.
+- Automated processes or scripts that perform bulk deletions as part of routine maintenance may be flagged. Identify these processes and whitelist them to prevent unnecessary alerts.
+- Users with roles in data management or IT support may regularly delete large volumes of files as part of their job responsibilities. Establish a baseline for these users and adjust the detection thresholds accordingly.
+- Temporary spikes in file deletions due to organizational changes, such as department restructuring, can be mistaken for malicious activity. Monitor these events and temporarily adjust the rule parameters to accommodate expected changes.
+- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded from alerts, maintaining the effectiveness of the detection rule.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected user account to prevent further unauthorized file deletions. This can be done by disabling the account or changing the password.
+- Review the audit logs to identify the scope of the deletion and determine if any critical or sensitive files were affected. Restore these files from backups if available.
+- Conduct a thorough review of the affected user's recent activities to identify any other suspicious actions or potential indicators of compromise.
+- Escalate the incident to the security operations team for further investigation and to determine if the deletion is part of a larger attack or breach.
+- Implement additional monitoring on the affected account and similar high-risk accounts to detect any further unusual activities.
+- Review and update access controls and permissions to ensure that users have the minimum necessary access to perform their job functions, reducing the risk of large-scale deletions.
+- Coordinate with the IT and security teams to conduct a post-incident review, identifying any gaps in the response process and implementing improvements to prevent recurrence.
+
+==== Setup
+
+
+The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:o365.audit and event.provider:SecurityComplianceCenter and event.category:web and event.action:"Unusual volume of file deletion" and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Data Destruction
+** ID: T1485
+** Reference URL: https://attack.mitre.org/techniques/T1485/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc
new file mode 100644
index 0000000000..be24470476
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc
@@ -0,0 +1,112 @@
+[[deprecated-m365-security-compliance-user-restricted-from-sending-email]]
+=== Deprecated - M365 Security Compliance User Restricted from Sending Email
+
+Identifies when a user has been restricted from sending email due to exceeding sending limits of the service policies per the Security Compliance Center.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+* filebeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy
+* https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: Microsoft 365
+* Use Case: Configuration Audit
+* Tactic: Impact
+* Resources: Investigation Guide
+
+*Version*: 212
+
+*Rule authors*: 
+
+* Austin Songer
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Deprecated - M365 Security Compliance User Restricted from Sending Email*
+
+
+Microsoft 365 enforces email sending limits to prevent abuse and ensure service integrity. Adversaries may exploit compromised accounts to send spam or phishing emails, triggering these limits. The detection rule monitors audit logs for successful restrictions by the Security Compliance Center, indicating potential misuse of valid accounts, aligning with MITRE ATT&CK's Initial Access tactic.
+
+
+*Possible investigation steps*
+
+
+- Review the audit logs in Microsoft 365 to confirm the event details, focusing on entries with event.dataset:o365.audit and event.provider:SecurityComplianceCenter to ensure the restriction was logged correctly.
+- Identify the user account that was restricted by examining the event.action:"User restricted from sending email" and event.outcome:success fields to understand which account triggered the alert.
+- Investigate the recent email activity of the restricted user account to determine if there was any unusual or suspicious behavior, such as a high volume of outbound emails or patterns consistent with spam or phishing.
+- Check for any recent changes in account permissions or configurations that might indicate unauthorized access or compromise, aligning with the MITRE ATT&CK technique T1078 for Valid Accounts.
+- Assess whether there are any other related alerts or incidents involving the same user or similar patterns, which could indicate a broader security issue or coordinated attack.
+
+
+*False positive analysis*
+
+
+- High-volume legitimate email campaigns by marketing or communication teams can trigger sending limits. Coordinate with these teams to understand their schedules and create exceptions for known campaigns.
+- Automated systems or applications using Microsoft 365 accounts for sending notifications or alerts may exceed limits. Identify these accounts and consider using service accounts with appropriate permissions and limits.
+- Users with delegated access to multiple mailboxes might inadvertently trigger restrictions. Review and adjust permissions or create exceptions for these users if their activity is verified as legitimate.
+- Temporary spikes in email activity due to business needs, such as end-of-quarter communications, can cause false positives. Monitor these periods and adjust thresholds or create temporary exceptions as needed.
+- Misconfigured email clients or scripts that repeatedly attempt to send emails can appear as suspicious activity. Ensure proper configuration and monitor for any unusual patterns that may need exceptions.
+
+
+*Response and remediation*
+
+
+- Immediately disable the compromised user account to prevent further unauthorized email activity and potential spread of phishing or spam.
+- Conduct a password reset for the affected account and enforce multi-factor authentication (MFA) to enhance security and prevent future unauthorized access.
+- Review the audit logs for any additional suspicious activities associated with the compromised account, such as unusual login locations or times, and investigate any anomalies.
+- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts.
+- Escalate the incident to the security operations team for further analysis and to determine if other accounts or systems have been compromised.
+- Implement additional email filtering rules to block similar phishing or spam patterns identified in the incident to prevent recurrence.
+- Update and enhance detection rules and monitoring to quickly identify and respond to similar threats in the future, leveraging insights from the current incident.
+
+==== Setup
+
+
+The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:o365.audit and event.provider:SecurityComplianceCenter and event.category:web and event.action:"User restricted from sending email" and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-m365-teams-external-access-enabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-m365-teams-external-access-enabled.asciidoc
new file mode 100644
index 0000000000..57cc3f62f4
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-m365-teams-external-access-enabled.asciidoc
@@ -0,0 +1,118 @@
+[[deprecated-m365-teams-external-access-enabled]]
+=== Deprecated - M365 Teams External Access Enabled
+
+Identifies when external access is enabled in Microsoft Teams. External access lets Teams and Skype for Business users communicate with other users that are outside their organization. An adversary may enable external access or add an allowed domain to exfiltrate data or maintain persistence in an environment.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+* filebeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/microsoftteams/manage-external-access
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: Microsoft 365
+* Use Case: Configuration Audit
+* Tactic: Defense Evasion
+* 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 Deprecated - M365 Teams External Access Enabled*
+
+
+Microsoft Teams' external access feature allows users to communicate with individuals outside their organization, facilitating collaboration. However, adversaries can exploit this by enabling external access or adding trusted domains to exfiltrate data or maintain persistence. The detection rule monitors audit logs for changes in federation settings, specifically when external access is successfully enabled, indicating potential misuse.
+
+
+*Possible investigation steps*
+
+
+- Review the audit logs for the specific event.action "Set-CsTenantFederationConfiguration" to identify when and by whom the external access was enabled.
+- Examine the o365.audit.Parameters.AllowFederatedUsers field to confirm that it is set to True, indicating that external access was indeed enabled.
+- Investigate the user account associated with the event to determine if the action was authorized and if the account has a history of suspicious activity.
+- Check the event.provider field to see if the change was made through SkypeForBusiness or MicrosoftTeams, which may provide additional context on the method used.
+- Assess the event.outcome field to ensure the action was successful and not a failed attempt, which could indicate a potential security threat.
+- Look into any recent changes in the list of allowed domains to identify if any unauthorized or suspicious domains have been added.
+
+
+*False positive analysis*
+
+
+- Routine administrative changes to federation settings can trigger alerts. Regularly review and document these changes to differentiate between legitimate and suspicious activities.
+- Organizations with frequent collaboration with external partners may see increased alerts. Consider creating exceptions for known trusted domains to reduce noise.
+- Scheduled updates or policy changes by IT teams might enable external access temporarily. Coordinate with IT to log these activities and exclude them from triggering alerts.
+- Automated scripts or tools used for configuration management can inadvertently enable external access. Ensure these tools are properly documented and monitored to prevent false positives.
+- Changes made during mergers or acquisitions can appear suspicious. Maintain a record of such events and adjust monitoring rules accordingly to account for expected changes.
+
+
+*Response and remediation*
+
+
+- Immediately disable external access in Microsoft Teams to prevent further unauthorized communication with external domains.
+- Review and remove any unauthorized or suspicious domains added to the allowed list in the Teams federation settings.
+- Conduct a thorough audit of recent changes in the Teams configuration to identify any other unauthorized modifications or suspicious activities.
+- Reset credentials and enforce multi-factor authentication for accounts involved in the configuration change to prevent further unauthorized access.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Escalate the incident to the incident response team if there is evidence of data exfiltration or if the scope of the breach is unclear.
+- Implement enhanced monitoring and alerting for changes in Teams federation settings to detect similar threats in the future.
+
+==== Setup
+
+
+The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:o365.audit and event.provider:(SkypeForBusiness or MicrosoftTeams) and
+event.category:web and event.action:"Set-CsTenantFederationConfiguration" and
+o365.audit.Parameters.AllowFederatedUsers:True and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-m365-teams-guest-access-enabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-m365-teams-guest-access-enabled.asciidoc
new file mode 100644
index 0000000000..bcf6fbc235
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-m365-teams-guest-access-enabled.asciidoc
@@ -0,0 +1,117 @@
+[[deprecated-m365-teams-guest-access-enabled]]
+=== Deprecated - M365 Teams Guest Access Enabled
+
+Identifies when guest access is enabled in Microsoft Teams. Guest access in Teams allows people outside the organization to access teams and channels. An adversary may enable guest access to maintain persistence in an environment.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+* filebeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/powershell/module/skype/get-csteamsclientconfiguration?view=skype-ps
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: Microsoft 365
+* Use Case: Configuration Audit
+* Tactic: Persistence
+* 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 Deprecated - M365 Teams Guest Access Enabled*
+
+
+Microsoft Teams allows organizations to collaborate with external users through guest access, facilitating communication and teamwork. However, adversaries can exploit this feature to gain persistent access to sensitive environments by enabling guest access without authorization. The detection rule monitors audit logs for specific configurations that indicate guest access has been enabled, helping identify unauthorized changes and potential security breaches.
+
+
+*Possible investigation steps*
+
+
+- Review the audit logs to confirm the event.action "Set-CsTeamsClientConfiguration" was successfully executed with the parameter o365.audit.Parameters.AllowGuestUser set to True.
+- Identify the user account responsible for enabling guest access by examining the event logs for the user ID or account name associated with the action.
+- Check the user's activity history to determine if there are any other suspicious actions or patterns, such as changes to other configurations or unusual login times.
+- Investigate the context of the change by reviewing any related communications or requests that might justify enabling guest access, ensuring it aligns with organizational policies.
+- Assess the potential impact by identifying which teams and channels now have guest access enabled and evaluate the sensitivity of the information accessible to external users.
+- Contact the user or their manager to verify if the change was authorized and necessary, and document their response for future reference.
+
+
+*False positive analysis*
+
+
+- Legitimate collaboration with external partners may trigger alerts when guest access is enabled for business purposes. To manage this, create exceptions for known and approved external domains or specific projects that require guest access.
+- Routine administrative actions by IT staff to enable guest access for specific teams or channels can be mistaken for unauthorized changes. Implement a process to log and approve such changes internally, and exclude these from triggering alerts.
+- Automated scripts or third-party applications that configure Teams settings, including guest access, might cause false positives. Identify and whitelist these scripts or applications to prevent unnecessary alerts.
+- Changes made during scheduled maintenance windows can be misinterpreted as unauthorized. Define and exclude these time periods from monitoring to reduce false positives.
+
+
+*Response and remediation*
+
+
+- Immediately disable guest access in Microsoft Teams by updating the Teams client configuration to prevent unauthorized external access.
+- Conduct a thorough review of recent audit logs to identify any unauthorized changes or suspicious activities related to guest access settings.
+- Notify the security team and relevant stakeholders about the potential breach to ensure awareness and initiate further investigation.
+- Revoke any unauthorized guest accounts that have been added to Teams to eliminate potential persistence mechanisms.
+- Implement additional monitoring on Teams configurations to detect any future unauthorized changes to guest access settings.
+- Escalate the incident to the organization's incident response team for a comprehensive investigation and to determine if further containment actions are necessary.
+- Review and update access control policies to ensure that enabling guest access requires appropriate authorization and oversight.
+
+==== Setup
+
+
+The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:o365.audit and event.provider:(SkypeForBusiness or MicrosoftTeams) and
+event.category:web and event.action:"Set-CsTeamsClientConfiguration" and
+o365.audit.Parameters.AllowGuestUser:True and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-microsoft-exchange-transport-agent-install-script.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-microsoft-exchange-transport-agent-install-script.asciidoc
new file mode 100644
index 0000000000..35fcae9988
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-microsoft-exchange-transport-agent-install-script.asciidoc
@@ -0,0 +1,100 @@
+[[deprecated-microsoft-exchange-transport-agent-install-script]]
+=== Deprecated - Microsoft Exchange Transport Agent Install Script
+
+Identifies the use of Cmdlets and methods related to Microsoft Exchange Transport Agents install. Adversaries may leverage malicious Microsoft Exchange Transport Agents to execute tasks in response to adversary-defined criteria, establishing persistence.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.powershell*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 60m
+
+*Searches indices from*: now-119m ({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: PowerShell Logs
+* Rule Type: BBR
+
+*Version*: 110
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== 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 : (
+    (
+    "Install-TransportAgent" or
+    "Enable-TransportAgent"
+    )
+  ) and
+  not user.id : "S-1-5-18" and
+  not powershell.file.script_block_text : (
+    "'Install-TransportAgent', 'Invoke-MonitoringProbe', 'Mount-Database', 'Move-ActiveMailboxDatabase'," or
+    "'Enable-TransportAgent', 'Enable-TransportRule', 'Export-ActiveSyncLog', 'Export-AutoDiscoverConfig'," or
+    ("scriptCmd.GetSteppablePipeline" and "ForwardHelpTargetName Install-TransportAgent")
+  )
+
+----------------------------------
+
+*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: Transport Agent
+** ID: T1505.002
+** Reference URL: https://attack.mitre.org/techniques/T1505/002/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-potential-powershell-obfuscated-script.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-potential-powershell-obfuscated-script.asciidoc
new file mode 100644
index 0000000000..016460dfd2
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-potential-powershell-obfuscated-script.asciidoc
@@ -0,0 +1,164 @@
+[[deprecated-potential-powershell-obfuscated-script]]
+=== Deprecated - Potential PowerShell Obfuscated Script
+
+Identifies scripts that contain patterns and known methods that obfuscate PowerShell code. Attackers can use obfuscation techniques to bypass PowerShell security protections such as Antimalware Scan Interface (AMSI).
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.powershell*
+
+*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://github.com/danielbohannon/Invoke-Obfuscation
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: PowerShell Logs
+* 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 Deprecated - Potential PowerShell Obfuscated Script*
+
+
+PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its flexibility to obfuscate scripts, evading security measures like AMSI. The detection rule identifies obfuscation patterns, such as string manipulation and encoding techniques, to flag potentially malicious scripts, aiding in defense evasion detection.
+
+
+*Possible investigation steps*
+
+
+- Review the PowerShell script block text captured in the alert to identify any suspicious patterns or obfuscation techniques, such as string manipulation or encoding methods like "[string]::join" or "-Join".
+- Check the process execution details, including the parent process and command line arguments, to understand the context in which the PowerShell script was executed.
+- Investigate the source and destination of the script execution by examining the host and user details to determine if the activity aligns with expected behavior or if it originates from an unusual or unauthorized source.
+- Analyze any network connections or file modifications associated with the PowerShell process to identify potential data exfiltration or lateral movement activities.
+- Correlate the alert with other security events or logs, such as Windows Event Logs or network traffic logs, to gather additional context and identify any related suspicious activities.
+- Assess the risk and impact of the detected activity by considering the severity and risk score provided in the alert, and determine if immediate remediation actions are necessary.
+
+
+*False positive analysis*
+
+
+- Legitimate administrative scripts may use string manipulation and encoding techniques for benign purposes, such as data processing or configuration management. Review the context of the script execution and verify the source and intent before flagging it as malicious.
+- Scripts that automate complex tasks might use obfuscation-like patterns to handle data securely or efficiently. Consider whitelisting known scripts or trusted sources to reduce false positives.
+- Development and testing environments often run scripts with obfuscation patterns for testing purposes. Exclude these environments from the rule or create exceptions for specific users or groups involved in development.
+- Security tools and monitoring solutions might generate PowerShell scripts with obfuscation patterns as part of their normal operation. Identify these tools and exclude their activities from triggering the rule.
+- Regularly update the list of exceptions and whitelisted scripts to ensure that new legitimate scripts are not mistakenly flagged as threats.
+
+
+*Response and remediation*
+
+
+- Isolate the affected system from the network to prevent further spread of potentially malicious scripts.
+- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activity.
+- Conduct a thorough review of the PowerShell script block logs to identify and remove any obfuscated scripts or malicious code remnants.
+- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.
+- Update and patch the affected system to ensure all security vulnerabilities are addressed, reducing the risk of exploitation.
+- Monitor the system and network for any signs of re-infection or similar obfuscation patterns to ensure the threat has been fully mitigated.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+
+==== 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 : (
+    "[string]::join" or
+    "-Join" or
+    "[convert]::toint16" or
+    "[char][int]$_" or
+    ("ConvertTo-SecureString" and "PtrToStringAuto") or
+    "-BXor" or
+    ("replace" and "char") or
+    "[array]::reverse" or
+    "-replace"
+  ) and
+  powershell.file.script_block_text : (
+    ("$pSHoMe[" and "+$pSHoMe[") or
+    ("$ShellId[" and "+$ShellId[") or
+    ("$env:ComSpec[4" and "25]-Join") or
+    (("Set-Variable" or "SV" or "Set-Item") and "OFS") or
+    ("*MDR*" and "Name[3,11,2]") or
+    ("$VerbosePreference" and "[1,3]+'X'-Join''") or
+    ("rahc" or "ekovin" or "gnirts" or "ecnereferpesobrev" or "ecalper" or "cepsmoc" or "dillehs") or
+    ("System.Management.Automation.$([cHAr]" or "System.$([cHAr]" or ")+[cHAR]([byte]")
+  ) and
+  not powershell.file.script_block_text : (
+        ("Copyright (c) 2018 Ansible Project" or "Export-ModuleMember -Function Add-CSharpType") and
+        ("[Object]$AnsibleModule" or "$AnsibleModule.Tmpdir")
+  )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-powershell-script-with-discovery-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-powershell-script-with-discovery-capabilities.asciidoc
new file mode 100644
index 0000000000..6b292b3c93
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-powershell-script-with-discovery-capabilities.asciidoc
@@ -0,0 +1,238 @@
+[[deprecated-powershell-script-with-discovery-capabilities]]
+=== Deprecated - PowerShell Script with Discovery Capabilities
+
+Identifies the use of Cmdlets and methods related to discovery activities. Attackers can use these to perform various situational awareness related activities, like enumerating users, shares, sessions, domain trusts, groups, etc.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.powershell*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 60m
+
+*Searches indices from*: now-119m ({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: Collection
+* Tactic: Discovery
+* Data Source: PowerShell Logs
+* Rule Type: BBR
+
+*Version*: 214
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== 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 : (
+    (
+      "Get-ADDefaultDomainPasswordPolicy" or
+      "Get-ADDomain" or "Get-ComputerInfo" or
+      "Get-Disk" or "Get-DnsClientCache" or
+      "Get-GPOReport" or "Get-HotFix" or
+      "Get-LocalUser" or "Get-NetFirewallProfile" or
+      "get-nettcpconnection" or "Get-NetAdapter" or
+      "Get-PhysicalDisk" or "Get-Process" or
+      "Get-PSDrive" or "Get-Service" or
+      "Get-SmbShare" or "Get-WinEvent"
+    ) or
+    (
+      ("Get-WmiObject" or "gwmi" or "Get-CimInstance" or
+       "gcim" or "Management.ManagementObjectSearcher" or
+       "System.Management.ManagementClass" or
+       "[WmiClass]") and
+      (
+        "AntiVirusProduct" or "CIM_BIOSElement" or "CIM_ComputerSystem" or "CIM_Product" or "CIM_DiskDrive" or
+        "CIM_LogicalDisk" or "CIM_NetworkAdapter" or "CIM_StorageVolume" or "CIM_OperatingSystem" or
+        "CIM_Process" or "CIM_Service" or "MSFT_DNSClientCache" or "Win32_BIOS" or "Win32_ComputerSystem" or
+        "Win32_ComputerSystemProduct" or "Win32_DiskDrive" or "win32_environment" or "Win32_Group" or
+        "Win32_groupuser" or "Win32_IP4RouteTable" or "Win32_logicaldisk" or "Win32_MappedLogicalDisk" or
+        "Win32_NetworkAdapterConfiguration" or "win32_ntdomain" or "Win32_OperatingSystem" or
+        "Win32_PnPEntity" or "Win32_Process" or "Win32_Product" or "Win32_quickfixengineering" or
+        "win32_service" or "Win32_Share" or "Win32_UserAccount"
+      )
+    ) or
+    (
+      ("ADSI" and "WinNT") or
+      ("Get-ChildItem" and "sysmondrv.sys") or
+      ("::GetIPGlobalProperties()" and "GetActiveTcpConnections()") or
+      ("ServiceProcess.ServiceController" and "::GetServices") or
+      ("Diagnostics.Process" and "::GetProcesses") or
+      ("DirectoryServices.Protocols.GroupPolicy" and ".GetGPOReport()") or
+      ("DirectoryServices.AccountManagement" and "PrincipalSearcher") or
+      ("NetFwTypeLib.NetFwMgr" and "CurrentProfile") or
+      ("NetworkInformation.NetworkInterface" and "GetAllNetworkInterfaces") or
+      ("Automation.PSDriveInfo") or
+      ("Microsoft.Win32.RegistryHive")
+    ) or
+    (
+      "Get-ItemProperty" and
+      (
+        "\Control\SecurityProviders\WDigest" or
+        "\microsoft\windows\currentversion\explorer\runmru" or
+        "\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" or
+        "\Microsoft\Windows\CurrentVersion\Uninstall" or
+        "\Microsoft\Windows\WindowsUpdate" or
+        "Policies\Microsoft\Windows\Installer" or
+        "Software\Microsoft\Windows\CurrentVersion\Policies" or
+        ("\Services\SharedAccess\Parameters\FirewallPolicy" and "EnableFirewall") or
+        ("Microsoft\Windows\CurrentVersion\Internet Settings" and "proxyEnable")
+      )
+    ) or
+    (
+      ("Directoryservices.Activedirectory" or
+      "DirectoryServices.AccountManagement") and 
+      (
+        "Domain Admins" or "DomainControllers" or
+        "FindAllGlobalCatalogs" or "GetAllTrustRelationships" or
+        "GetCurrentDomain" or "GetCurrentForest"
+      ) or
+      "DirectoryServices.DirectorySearcher" and
+      (
+        "samAccountType=805306368" or
+        "samAccountType=805306369" or
+        "objectCategory=group" or
+        "objectCategory=groupPolicyContainer" or
+        "objectCategory=site" or
+        "objectCategory=subnet" or
+        "objectClass=trustedDomain"
+      )
+    ) or
+    (
+      "Get-Process" and
+      (
+        "mcshield" or "windefend" or "savservice" or
+        "TMCCSF" or "symantec antivirus" or
+        "CSFalcon" or "TmPfw" or "kvoop"
+      )
+    )
+  ) and
+  not powershell.file.script_block_text : (
+    (
+      "__cmdletization_BindCommonParameters" and
+      "Microsoft.PowerShell.Core\Export-ModuleMember" and
+      "Microsoft.PowerShell.Cmdletization.Cim.CimCmdletAdapter"
+    ) or
+    "CmdletsToExport=@(\"Add-Content\"," or
+    ("cmdletization" and "cdxml-Help.xml")
+  ) and
+  not user.id : ("S-1-5-18" or "S-1-5-19" or "S-1-5-20")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Discovery
+** ID: TA0007
+** Reference URL: https://attack.mitre.org/tactics/TA0007/
+* Technique:
+** Name: System Service Discovery
+** ID: T1007
+** Reference URL: https://attack.mitre.org/techniques/T1007/
+* Technique:
+** Name: Query Registry
+** ID: T1012
+** Reference URL: https://attack.mitre.org/techniques/T1012/
+* Technique:
+** Name: System Network Connections Discovery
+** ID: T1049
+** Reference URL: https://attack.mitre.org/techniques/T1049/
+* Technique:
+** Name: Process Discovery
+** ID: T1057
+** Reference URL: https://attack.mitre.org/techniques/T1057/
+* Technique:
+** Name: System Information Discovery
+** ID: T1082
+** Reference URL: https://attack.mitre.org/techniques/T1082/
+* Technique:
+** Name: System Information Discovery
+** ID: T1082
+** Reference URL: https://attack.mitre.org/techniques/T1082/
+* Technique:
+** Name: File and Directory Discovery
+** ID: T1083
+** Reference URL: https://attack.mitre.org/techniques/T1083/
+* Technique:
+** Name: Account Discovery
+** ID: T1087
+** Reference URL: https://attack.mitre.org/techniques/T1087/
+* Sub-technique:
+** Name: Local Account
+** ID: T1087.001
+** Reference URL: https://attack.mitre.org/techniques/T1087/001/
+* Sub-technique:
+** Name: Domain Account
+** ID: T1087.002
+** Reference URL: https://attack.mitre.org/techniques/T1087/002/
+* Technique:
+** Name: Network Share Discovery
+** ID: T1135
+** Reference URL: https://attack.mitre.org/techniques/T1135/
+* Technique:
+** Name: Password Policy Discovery
+** ID: T1201
+** Reference URL: https://attack.mitre.org/techniques/T1201/
+* Technique:
+** Name: Domain Trust Discovery
+** ID: T1482
+** Reference URL: https://attack.mitre.org/techniques/T1482/
+* Technique:
+** Name: Software Discovery
+** ID: T1518
+** Reference URL: https://attack.mitre.org/techniques/T1518/
+* Sub-technique:
+** Name: Security Software Discovery
+** ID: T1518.001
+** Reference URL: https://attack.mitre.org/techniques/T1518/001/
+* Technique:
+** Name: Group Policy Discovery
+** ID: T1615
+** Reference URL: https://attack.mitre.org/techniques/T1615/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-powershell-script-with-remote-execution-capabilities-via-winrm.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-powershell-script-with-remote-execution-capabilities-via-winrm.asciidoc
new file mode 100644
index 0000000000..5c0dcfa200
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-powershell-script-with-remote-execution-capabilities-via-winrm.asciidoc
@@ -0,0 +1,106 @@
+[[deprecated-powershell-script-with-remote-execution-capabilities-via-winrm]]
+=== Deprecated - PowerShell Script with Remote Execution Capabilities via WinRM
+
+Identifies the use of Cmdlets and methods related to remote execution activities using WinRM. Attackers can abuse WinRM to perform lateral movement using built-in tools.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.powershell*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 60m
+
+*Searches indices from*: now-119m ({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/006/
+* https://github.com/cobbr/SharpSploit/blob/master/SharpSploit/LateralMovement/PowerShellRemoting.cs
+* https://github.com/BC-SECURITY/Empire/blob/main/empire/server/modules/powershell/lateral_movement/invoke_psremoting.py
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Lateral Movement
+* Tactic: Execution
+* Data Source: PowerShell Logs
+* Rule Type: BBR
+
+*Version*: 212
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== 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 : (
+    ("Invoke-WmiMethod" or "Invoke-Command" or "Enter-PSSession") and "ComputerName"
+  ) and
+  not user.id : "S-1-5-18" and
+  not file.directory : (
+    "C:\\Program Files\\LogicMonitor\\Agent\\tmp" or
+    "C:\\Program Files\\WindowsPowerShell\\Modules\\icinga-powershell-framework\\cache" or
+    "C:\\Program Files\\WindowsPowerShell\\Modules\\SmartCardTools\\1.2.2"
+  ) and not
+  powershell.file.script_block_text : (
+    "Export-ModuleMember -Function @('Invoke-Expression''Invoke-Command')" and
+    "function Invoke-Command {"
+  )
+
+----------------------------------
+
+*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: Windows Remote Management
+** ID: T1021.006
+** Reference URL: https://attack.mitre.org/techniques/T1021/006/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/rule-details/deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc
new file mode 100644
index 0000000000..887f0be6c9
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-suspicious-printspooler-service-executable-file-creation.asciidoc
@@ -0,0 +1,122 @@
+[[deprecated-suspicious-printspooler-service-executable-file-creation]]
+=== Deprecated - Suspicious PrintSpooler Service Executable File Creation
+
+Detects attempts to exploit privilege escalation vulnerabilities related to the Print Spooler service. For more information refer to the following CVE's - CVE-2020-1048, CVE-2020-1337 and CVE-2020-1300 and verify that the impacted system is patched.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-endpoint.events.file-*
+* logs-windows.sysmon_operational-*
+* endgame-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://voidsec.com/cve-2020-1337-printdemon-is-dead-long-live-printdemon/
+* https://www.thezdi.com/blog/2020/7/8/cve-2020-1300-remote-code-execution-through-microsoft-windows-cab-files
+
+*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
+* Data Source: Microsoft Defender for Endpoint
+* Data Source: SentinelOne
+* Resources: Investigation Guide
+
+*Version*: 320
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Deprecated - Suspicious PrintSpooler Service Executable File Creation*
+
+
+The Print Spooler service in Windows manages print jobs, but vulnerabilities like CVE-2020-1048 can be exploited for privilege escalation. Adversaries may create malicious DLL files executed by the spooler to gain elevated privileges. The detection rule identifies such threats by monitoring file creation events linked to the spooler process, focusing on DLL files, which are common vectors for exploitation.
+
+
+*Possible investigation steps*
+
+
+- Review the alert details to confirm the presence of a file creation event with the extension "dll" associated with the "spoolsv.exe" process on a Windows host.
+- Check the file path and name of the created DLL to determine if it matches known malicious patterns or locations typically used for exploitation.
+- Investigate the source of the spoolsv.exe process by examining the parent process and any associated user accounts to identify potential unauthorized access or activity.
+- Analyze recent system logs and security events for any other suspicious activities or anomalies around the time of the DLL creation, such as unexpected user logins or privilege changes.
+- Verify the patch status of the affected system against the vulnerabilities CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300 to ensure it is up to date and not susceptible to known exploits.
+- If the DLL is confirmed to be malicious, isolate the affected system to prevent further exploitation and begin remediation efforts, including removing the malicious file and any associated threats.
+
+
+*False positive analysis*
+
+
+- Legitimate DLL updates by trusted software can trigger the rule. Users should verify the source of the DLL and, if confirmed safe, add the software's update process to an exception list.
+- System maintenance activities, such as Windows updates, may create DLLs that match the rule's criteria. Users can exclude these activities by identifying the associated update processes and adding them to the exception list.
+- Custom in-house applications that interact with the Print Spooler service might generate DLLs during normal operation. Users should validate these applications and exclude their file creation events if they are deemed non-threatening.
+- Security software or monitoring tools that interact with the Print Spooler service could inadvertently create DLLs. Users should confirm the legitimacy of these tools and configure exceptions for their operations.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Terminate the spoolsv.exe process if it is confirmed to be executing a malicious DLL, to halt any ongoing malicious activity.
+- Remove the malicious DLL file from the system to prevent re-execution and further exploitation.
+- Apply the latest security patches and updates to the affected system, specifically addressing CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300, to close the vulnerabilities exploited by the adversary.
+- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized privilege escalation has occurred.
+- Monitor the network for any signs of similar exploitation attempts or related suspicious activity, using enhanced logging and alerting mechanisms.
+- Report the incident to the appropriate internal security team or external authorities if required, providing details of the exploit and actions taken for further investigation and response.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.category : "file" and host.os.type : "windows" and event.type : "creation" and
+  process.name : "spoolsv.exe" and file.extension : "dll"
+
+----------------------------------
+
+*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/deprecated-unusual-discovery-activity-by-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/deprecated-unusual-discovery-activity-by-user.asciidoc
new file mode 100644
index 0000000000..2bf1f85de6
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/deprecated-unusual-discovery-activity-by-user.asciidoc
@@ -0,0 +1,62 @@
+[[deprecated-unusual-discovery-activity-by-user]]
+=== Deprecated - Unusual Discovery Activity by User
+
+This rule leverages alert data from various Discovery building block rules to alert on signals with unusual unique host.id and user.id entries.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* .alerts-security.*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Discovery
+* Rule Type: Higher-Order Rule
+* Rule Type: BBR
+
+*Version*: 3
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:(
+  "d68e95ad-1c82-4074-a12a-125fe10ac8ba" or "7b8bfc26-81d2-435e-965c-d722ee397ef1" or
+  "0635c542-1b96-4335-9b47-126582d2c19a" or "6ea55c81-e2ba-42f2-a134-bccf857ba922" or
+  "e0881d20-54ac-457f-8733-fe0bc5d44c55" or "06568a02-af29-4f20-929c-f3af281e41aa" or
+  "c4e9ed3e-55a2-4309-a012-bc3c78dad10a" or "51176ed2-2d90-49f2-9f3d-17196428b169" or
+  "1d72d014-e2ab-4707-b056-9b96abe7b511"
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Discovery
+** ID: TA0007
+** Reference URL: https://attack.mitre.org/tactics/TA0007/
diff --git a/docs/detections/prebuilt-rules/rule-details/detection-alert-on-a-process-exhibiting-cpu-spike.asciidoc b/docs/detections/prebuilt-rules/rule-details/detection-alert-on-a-process-exhibiting-cpu-spike.asciidoc
index 2563f8cc95..82c2a249c6 100644
--- a/docs/detections/prebuilt-rules/rule-details/detection-alert-on-a-process-exhibiting-cpu-spike.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/detection-alert-on-a-process-exhibiting-cpu-spike.asciidoc
@@ -27,7 +27,7 @@ This rule correlates security alerts with processes exhibiting unusually high CP
 * Domain: Endpoint
 * Tactic: Impact
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -136,6 +136,7 @@ https://docs.elastic.co/integrations/system
 [source, js]
 ----------------------------------
 FROM metrics-*, .alerts-security.* METADATA _index
+| where not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
 | eval
        // processes with more than 70% total CPU use
        cpu_metrics_pids = CASE(_index like ".ds-metrics-system.process-*" and system.process.cpu.total.norm.pct >= 0.7, process.pid, null),
diff --git a/docs/detections/prebuilt-rules/rule-details/disabling-lsa-protection-via-registry-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/disabling-lsa-protection-via-registry-modification.asciidoc
index 86bc1a8452..5e5ca44866 100644
--- a/docs/detections/prebuilt-rules/rule-details/disabling-lsa-protection-via-registry-modification.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/disabling-lsa-protection-via-registry-modification.asciidoc
@@ -43,7 +43,7 @@ LSA protecton is provided to prevent nonprotected processes from reading memory
 * Data Source: SentinelOne
 * Data Source: Crowdstrike
 
-*Version*: 3
+*Version*: 4
 
 *Rule authors*: 
 
@@ -108,9 +108,11 @@ Attackers may disable Lsa protection to access Lsass memory for credentals. This
 [source, js]
 ----------------------------------
 registry where host.os.type == "windows" and event.type == "change" and
-  registry.data.strings != null and registry.value : "RunAsPPL" and
+  registry.data.strings != null and process.name != null and
+  registry.value : "RunAsPPL" and
   registry.path : "*\\SYSTEM\\*ControlSet*\\Control\\Lsa\\RunAsPPL" and
-  not registry.data.strings : ("1", "0x00000001", "2", "0x00000002")
+  not registry.data.strings : ("1", "0x00000001", "2", "0x00000002") and
+  not process.executable : "?:\\Windows\\System32\\SecurityHealthService.exe"
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/discovery-of-internet-capabilities-via-built-in-tools.asciidoc b/docs/detections/prebuilt-rules/rule-details/discovery-of-internet-capabilities-via-built-in-tools.asciidoc
index 25aab85499..ad4dd9254b 100644
--- a/docs/detections/prebuilt-rules/rule-details/discovery-of-internet-capabilities-via-built-in-tools.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/discovery-of-internet-capabilities-via-built-in-tools.asciidoc
@@ -30,7 +30,7 @@ Identifies the use of built-in tools attackers can use to check for Internet con
 * Rule Type: BBR
 * Data Source: Elastic Defend
 
-*Version*: 104
+*Version*: 105
 
 *Rule authors*: 
 
@@ -46,7 +46,8 @@ Identifies the use of built-in tools attackers can use to check for Internet con
 ----------------------------------
 host.os.type:windows and event.category:process and event.type:start and 
 process.name.caseless:("ping.exe" or "tracert.exe" or "pathping.exe") and
-not process.args:("127.0.0.1" or "0.0.0.0" or "localhost" or "::1")
+not process.args:("127.0.0.1" or "0.0.0.0" or "localhost" or "::1" or 192.168.*) and
+process.command_line:*.*
 
 ----------------------------------
 
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 ce0527c901..a1b4e9543e 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
@@ -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*: 2
+*Version*: 3
 
 *Rule authors*: 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/dynamic-iex-reconstruction-via-method-string-access.asciidoc b/docs/detections/prebuilt-rules/rule-details/dynamic-iex-reconstruction-via-method-string-access.asciidoc
index b1a385ba96..26f3eeb353 100644
--- a/docs/detections/prebuilt-rules/rule-details/dynamic-iex-reconstruction-via-method-string-access.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/dynamic-iex-reconstruction-via-method-string-access.asciidoc
@@ -1,7 +1,7 @@
 [[dynamic-iex-reconstruction-via-method-string-access]]
 === Dynamic IEX Reconstruction via Method String Access
 
-Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command by accessing and indexing the string representation of method references. This obfuscation technique uses constructs like ''.IndexOf.ToString() to expose method metadata as a string, then extracts specific characters through indexed access and joins them to form IEX, bypassing static keyword detection and evading defenses such as AMSI.
+Detects PowerShell scripts that rebuilds IEX by converting method references to strings (for example, ''.IndexOf.ToString()) and extracting multiple indexed characters (for example, [n,n,n]). Attackers use method-string reconstruction to conceal dynamic execution and bypass static detections and AMSI.
 
 *Rule type*: esql
 
@@ -28,7 +28,7 @@ Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) comma
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 10
+*Version*: 11
 
 *Rule authors*: 
 
@@ -40,48 +40,95 @@ Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) comma
 ==== Investigation guide
 
 
- ## Triage and analysis
+
+*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.
+> 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 Dynamic IEX Reconstruction via Method String Access*
 
 
-PowerShell's flexibility allows dynamic command execution, which adversaries exploit by obfuscating commands like Invoke-Expression (IEX). They manipulate method strings to reconstruct IEX, evading static detection. The detection rule identifies scripts using this obfuscation by analyzing patterns in method string access, flagging suspicious activity for further investigation.
+This alert indicates PowerShell script block content that uses method-to-string conversion and indexed character extraction to assemble an execution primitive at runtime, commonly "IEX" (Invoke-Expression). This obfuscation technique can conceal dynamic execution intent and is often used to reduce obvious keywords in the script body.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
 
 
 *Possible investigation steps*
 
 
-- Review the powershell.file.script_block_text field to understand the content and intent of the script that triggered the alert. Look for any suspicious patterns or obfuscation techniques.
-- Examine the file.path field to determine the location of the script on the host system, which can provide context about its origin and potential legitimacy.
-- Check the host.name and user.id fields to identify the machine and user account involved in executing the script, which can help assess whether the activity aligns with expected behavior.
-- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other PowerShell activities on the host, providing a broader view of the script's execution context.
-- Investigate the agent.id field to verify the endpoint's security posture and ensure that it is up-to-date with the latest security patches and configurations.
+- Establish execution context and scope:
+  - Review `host.name` and `host.id` to identify the affected endpoint and its role/criticality.
+  - Review `user.name`, `user.domain`, and `user.id` to determine whether the activity aligns with expected administrative or automation usage.
+  - Review `file.path`, `file.directory`, and `file.name` (when present) to understand whether the script originated from an on-disk file.
+  - Review `agent.id` to pivot to other telemetry from the same endpoint and timeframe.
+
+- Validate what matched and how extensively it appears:
+  - Review `Esql.script_block_pattern_count` to gauge how often the technique appears within the script block (higher counts can indicate heavier obfuscation).
+  - Use `Esql.script_block_tmp` to quickly locate the matched regions, then review the corresponding locations in `powershell.file.script_block_text` for the exact construct and nearby context.
+  - Review `powershell.file.script_block_length` alongside `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_unique_symbols` to help distinguish isolated string tricks from broader obfuscation.
+
+- Reconstruct the full script block when content is split:
+  - Pivot on `powershell.file.script_block_id` and order results by `powershell.sequence`.
+  - Use `powershell.total` to confirm you have all fragments before making a final assessment.
+  - Preserve the reassembled content from `powershell.file.script_block_text` for follow-on analysis and scoping.
+
+- Determine the reconstructed token and follow-on behavior:
+  - In `powershell.file.script_block_text`, identify the method string being indexed and the associated index list (for example, [n,n,n]) to determine what characters are being assembled.
+  - Identify how the reconstructed string is used (for example, invoked directly, assigned to a variable, or passed as an argument) and what content it ultimately executes.
+  - Capture any secondary artifacts referenced in the script content (for example, embedded payload strings, additional script blocks, or external resource locations) and use them to drive further correlation.
+
+- Validate likely origin and initiating source:
+  - If `file.path` is present, validate whether the script location is expected for the user and host, and whether it appears in a user-writable location or a standard administrative tooling path.
+  - If file origin fields are not present, the script may have been executed interactively or generated at runtime; rely on surrounding endpoint telemetry to identify the initiating process and any related activity.
+
+- Correlate with adjacent activity to understand impact:
+  - Review other PowerShell script blocks on the same `host.id` and `user.id` around the alert time to identify staging steps and any follow-on execution.
+  - If process telemetry is available, identify the PowerShell process and its parent process that initiated execution, and check for suspicious child processes near the alert time.
+  - If network or file telemetry is available, look for downloads, outbound connections, and file writes temporally aligned with the script block execution and the content referenced within `powershell.file.script_block_text`.
+
+- Assess prevalence across the environment:
+  - Search for similar patterns (including stable substrings from `powershell.file.script_block_text`) across other hosts and users.
+  - Prioritize results with higher `Esql.script_block_pattern_count` and higher obfuscation metrics to identify likely common tooling or shared payloads.
 
 
 *False positive analysis*
 
 
-- Scripts with legitimate use of string manipulation methods like IndexOf or SubString may trigger false positives if they are part of complex PowerShell scripts used in administrative tasks. To manage this, review the context of the script and consider adding exceptions for known safe scripts or users.
-- Automated scripts from trusted software that perform extensive string operations for configuration or data processing might be flagged. Identify these scripts and exclude them by their script block ID or file path to prevent unnecessary alerts.
-- Development environments where PowerShell is used for testing or debugging purposes may generate alerts due to frequent use of string manipulation. Implement exclusions based on host names or user IDs associated with these environments to reduce noise.
-- Security tools or monitoring solutions that use PowerShell for log analysis or system checks might inadvertently match the detection pattern. Verify the source of the script and whitelist these tools by agent ID or specific script characteristics.
-- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity.
+- PowerShell developers or automation teams may experiment with unconventional string manipulation, but method-string indexing to assemble execution primitives is uncommon in routine administration.
+- Authorized security testing, malware analysis, or threat emulation activities can intentionally use this technique; validate against approved testing windows and operator accounts.
+- Some script packaging or code protection approaches can introduce non-standard string operations; treat as benign only when the script origin (`file.path` / `file.name`), execution context (`user.id`), and surrounding host activity support a known, approved workflow.
 
 
 *Response and remediation*
 
 
-- Isolate the affected host immediately to prevent further execution of potentially malicious scripts and limit lateral movement within the network.
-- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity.
-- Review the PowerShell script block text and script block ID from the alert to understand the scope and intent of the obfuscation technique used.
-- Remove any unauthorized or malicious scripts from the affected system to prevent re-execution.
-- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any additional threats.
-- Restore the affected system from a known good backup if the integrity of the system is compromised and cannot be assured.
-- 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 malicious or suspicious activity is confirmed:
+  - Contain the affected host identified by `host.id` to prevent additional execution and lateral movement.
+  - Preserve evidence from the alert, including `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, `file.path`, and `Esql.script_block_pattern_count`.
+  - Scope for related activity by searching for similar content patterns across the environment and identifying additional impacted hosts and accounts.
+  - If an on-disk script is involved (`file.path` present), collect the file for analysis and remove or quarantine it according to your incident handling process.
+  - Review the associated account (`user.id`) for additional suspicious activity and remediate credential exposure as appropriate (for example, reset credentials and review recent authentication activity).
+
+- If the activity is determined to be benign:
+  - Document the legitimate script source, expected hosts, and operator accounts for future triage.
+  - Reduce noise with narrowly scoped suppression using stable characteristics available in the alert (for example, consistent `file.path` and repeatable non-sensitive substrings in `powershell.file.script_block_text`), while continuing to monitor for deviations.
 
 
 ==== Setup
@@ -91,21 +138,8 @@ PowerShell's flexibility allows dynamic command execution, which adversaries exp
 *Setup*
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
-
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
-
-Steps to implement the logging policy via registry:
-
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
@@ -145,6 +179,7 @@ from logs-windows.powershell_operational* metadata _id, _version, _index
     _version,
     _index,
     host.name,
+    host.id,
     agent.id,
     user.id
 
diff --git a/docs/detections/prebuilt-rules/rule-details/elastic-agent-service-terminated.asciidoc b/docs/detections/prebuilt-rules/rule-details/elastic-agent-service-terminated.asciidoc
index 009ff016cf..8a033b8025 100644
--- a/docs/detections/prebuilt-rules/rule-details/elastic-agent-service-terminated.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/elastic-agent-service-terminated.asciidoc
@@ -32,7 +32,7 @@ Identifies the Elastic endpoint agent has stopped and is no longer running on th
 * Data Source: Elastic Defend
 * Resources: Investigation Guide
 
-*Version*: 111
+*Version*: 112
 
 *Rule authors*: 
 
@@ -117,18 +117,16 @@ process where
   process.args : ("elasticendpoint", "Elastic Agent","elastic-agent","elastic-endpoint"))
 or
 /* service or systemctl used to stop Elastic Agent on Linux */
-(event.type == "end" and
+(event.type == "start" and
   (process.name in ("systemctl", "service", "chkconfig", "update-rc.d") and
-    process.args : ("elastic-agent", "elastic-agent.service") and
+    process.args : ("elastic-agent", "elastic-agent.service", "ElasticEndpoint") and
     process.args : ("stop", "disable", "remove", "off", "kill", "mask"))
   or
-  /* pkill , killall used to stop Elastic Agent on Linux */
-  ( event.type == "end" and process.name in ("pkill", "killall", "kill") and process.args: "elastic-agent")
+  /* pkill , killall used to stop Elastic Agent or Endpoint on Linux */
+(event.type == "start" and process.name in ("pkill", "killall", "kill") and process.args : ("elastic-agent", "elastic-endpoint"))
   or
-  /* Unload Elastic Agent extension on MacOS */
-  (process.name : "kextunload" and
-    process.args : "com.apple.iokit.EndpointSecurity" and
-    event.action : "end"))
+  /* Unload Elastic Defend extension on MacOS */
+(event.type == "start" and process.name : "kextunload" and process.args : "com.apple.iokit.EndpointSecurity"))
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/elastic-defend-alert-followed-by-telemetry-loss.asciidoc b/docs/detections/prebuilt-rules/rule-details/elastic-defend-alert-followed-by-telemetry-loss.asciidoc
new file mode 100644
index 0000000000..ce4b6490c6
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/elastic-defend-alert-followed-by-telemetry-loss.asciidoc
@@ -0,0 +1,131 @@
+[[elastic-defend-alert-followed-by-telemetry-loss]]
+=== Elastic Defend Alert Followed by Telemetry Loss
+
+Detects when an Elastic Defend endpoint alert is generated on a host and is not followed by any subsequent endpoint telemetry (process, network, registry, library, or DNS events) within a short time window. This behavior may indicate endpoint security evasion, agent tampering, sensor disablement, service termination, system crash, or malicious interference with telemetry collection following detection.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.*
+
+*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/T1562/001/
+
+*Tags*: 
+
+* Domain: Endpoint
+* Data Source: Elastic Defend
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Tactic: Execution
+* Rule Type: Higher-Order Rule
+* 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 Elastic Defend Alert Followed by Telemetry Loss*
+
+
+This rule identifies situations where an Elastic Defend alert is generated on a host and is not followed by
+any normal endpoint activity events within a short time window. This may indicate agent tampering, sensor
+disablement, host shutdown, system crash, or defense evasion behavior.
+
+
+*Possible investigation steps*
+
+
+- Review the original `endpoint.alert` event and identify the detection that triggered the alert.
+- Check the host’s online status, uptime, and reboot history.
+- Verify the health and status of the Elastic Defend agent and related services.
+- Look for evidence of agent tampering, service stops, or security control modifications.
+- Correlate with activity immediately preceding the alert for signs of exploitation or evasion.
+- Determine if similar alert → silence patterns are occurring on other hosts.
+
+
+*False positive analysis*
+
+
+- Legitimate system reboots or shutdowns
+- Network connectivity loss
+- Elastic Agent upgrades or restarts
+- Endpoint service crashes
+- Maintenance or IT operations
+
+
+*Response and remediation*
+
+
+- Validate host and agent availability.
+- Reconnect or re-enroll the agent if telemetry is missing.
+- Isolate the host if malicious activity is suspected.
+- Investigate for security control tampering.
+- Perform broader environment hunting for similar patterns.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by host.id with maxspan=5m
+ [any where event.dataset == "endpoint.alerts"]
+ ![any where event.category in ("process", "library", "registry", "network", "dns")]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Impair Defenses
+** ID: T1562
+** Reference URL: https://attack.mitre.org/techniques/T1562/
+* Sub-technique:
+** Name: Disable or Modify Tools
+** ID: T1562.001
+** Reference URL: https://attack.mitre.org/techniques/T1562/001/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: 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/rule-details/elastic-defend-and-network-security-alerts-correlation.asciidoc b/docs/detections/prebuilt-rules/rule-details/elastic-defend-and-network-security-alerts-correlation.asciidoc
index ab81ba5a5b..bbc51540f5 100644
--- a/docs/detections/prebuilt-rules/rule-details/elastic-defend-and-network-security-alerts-correlation.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/elastic-defend-and-network-security-alerts-correlation.asciidoc
@@ -28,7 +28,7 @@ This rule correlate any Elastic Defend alert with a set of suspicious events fro
 * Data Source: Fortinet
 * Data Source: PAN-OS
 
-*Version*: 5
+*Version*: 6
 
 *Rule authors*: 
 
@@ -84,6 +84,20 @@ This rule correlate any Elastic Defend alert with suspicious events from Network
 - Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
 - Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.
 
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
+
 ==== Rule query
 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-actor-token-user-impersonation-abuse.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-actor-token-user-impersonation-abuse.asciidoc
index 9645155683..e32968fecd 100644
--- a/docs/detections/prebuilt-rules/rule-details/entra-id-actor-token-user-impersonation-abuse.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/entra-id-actor-token-user-impersonation-abuse.asciidoc
@@ -35,7 +35,7 @@ Identifies potential abuse of actor tokens in Microsoft Entra ID audit logs. Act
 * Tactic: Privilege Escalation
 * Resources: Investigation Guide
 
-*Version*: 4
+*Version*: 5
 
 *Rule authors*: 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-federated-identity-credential-issuer-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-federated-identity-credential-issuer-modified.asciidoc
new file mode 100644
index 0000000000..4231f90421
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/entra-id-federated-identity-credential-issuer-modified.asciidoc
@@ -0,0 +1,145 @@
+[[entra-id-federated-identity-credential-issuer-modified]]
+=== Entra ID Federated Identity Credential Issuer Modified
+
+Detects when the issuer URL of a federated identity credential is changed on an Entra ID application. Adversaries may modify the issuer to point to an attacker-controlled identity provider, enabling them to authenticate as the application's service principal and gain persistent access to Azure resources. This technique allows bypassing traditional authentication controls by federating trust with a malicious external identity provider.
+
+*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*: 
+
+* https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/
+* https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Audit Logs
+* Use Case: Identity and Access Audit
+* Tactic: Persistence
+* Tactic: Privilege Escalation
+* Resources: Investigation Guide
+
+*Version*: 8
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Entra ID Federated Identity Credential Issuer Modified*
+
+
+This rule detects when the issuer URL within a federated identity credential is modified on an Entra ID application. Federated identity credentials allow applications to authenticate using tokens from external identity providers (like GitHub Actions, AWS, etc.) without managing secrets. Adversaries can abuse this by changing the issuer to an attacker-controlled identity provider, allowing them to generate valid tokens and authenticate as the application's service principal.
+
+This technique provides persistent access to Azure resources with the application's permissions and bypasses secret-based authentication controls.
+
+
+*Possible investigation steps*
+
+
+- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `ipAddress` to identify who made the change and from where.
+- Examine the `Esql.external_idp_old_issuer` and `Esql.external_idp_new_issuer` fields to determine if the new issuer is expected or potentially malicious.
+- Check if the new issuer domain is controlled by the organization or if it's an external/suspicious domain.
+- Review the application's assigned roles and permissions to understand the scope of access gained.
+- Use `azure.correlation_id` to pivot to related changes in the same session.
+- Check for subsequent Azure sign-in activity using the modified federated credential.
+- Investigate if the application has been used to access sensitive resources after the change.
+
+
+*False positive analysis*
+
+
+- Legitimate migrations from one identity provider to another (e.g., GitHub to GitLab) may trigger this detection.
+- DevOps teams may update issuer URLs as part of CI/CD pipeline changes.
+- Validate any changes with the application owner or DevOps team before taking action.
+
+
+*Response and remediation*
+
+
+- If the change is unauthorized, immediately remove or revert the federated identity credential.
+- Rotate any secrets or certificates associated with the application.
+- Review Azure sign-in logs and audit logs for any unauthorized activity using the application's identity.
+- Disable the application or service principal if compromise is confirmed.
+- Investigate how the unauthorized change occurred (e.g., compromised admin account, over-privileged service principal).
+- Implement conditional access policies and PIM (Privileged Identity Management) to protect application management operations.
+
+
+==== Setup
+
+
+
+*Microsft Entra ID Audit Logs*
+
+This rule requires the Azure integration with Microsoft Entra ID Audit Logs data stream ingesting in your Elastic Stack deployment. For more information, refer to the https://www.elastic.co/docs/reference/integrations/azure/adlogs[Microsoft Entra ID Audit Logs integration documentation].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-azure.auditlogs-* metadata _id, _version, _index
+| where event.action == "Update application"
+| where `azure.auditlogs.properties.target_resources.0.modified_properties.0.display_name` == "FederatedIdentityCredentials"
+| eval Esql.target_resources_old_value_clean = replace(`azure.auditlogs.properties.target_resources.0.modified_properties.0.old_value`, "\\\\", "")
+| eval Esql.target_resources_new_value_clean = replace(`azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`, "\\\\", "")
+| dissect Esql.target_resources_old_value_clean "%{}\"Issuer\":\"%{Esql.external_idp_old_issuer}\"%{}"
+| dissect Esql.target_resources_new_value_clean "%{}\"Issuer\":\"%{Esql.external_idp_new_issuer}\"%{}"
+| where Esql.external_idp_old_issuer is not null and Esql.external_idp_new_issuer is not null
+| where Esql.external_idp_old_issuer != Esql.external_idp_new_issuer
+| keep @timestamp, Esql.*, azure.*, event.*, cloud.*, related.*, tags, source.*, agent.*, client.*, _id, _version, _index, data_stream.namespace
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
+* Sub-technique:
+** Name: Additional Cloud Credentials
+** ID: T1098.001
+** Reference URL: https://attack.mitre.org/techniques/T1098/001/
+* 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: Trust Modification
+** ID: T1484.002
+** Reference URL: https://attack.mitre.org/techniques/T1484/002/
diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc
new file mode 100644
index 0000000000..2573b24839
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc
@@ -0,0 +1,152 @@
+[[entra-id-service-principal-federated-credential-authentication-by-unusual-client]]
+=== Entra ID Service Principal Federated Credential Authentication by Unusual Client
+
+Identifies when a service principal authenticates using a federated identity credential for the first time in the historical window. This indicates that Entra ID validated a JWT token potentially against an external OIDC identity provider and issued an access token. While legitimate for CI/CD workflows (GitHub Actions, Azure DevOps), adversaries may abuse this by configuring rogue identity providers (BYOIDP) to authenticate as compromised applications. First-time federated credential usage for a service principal warrants investigation to determine if the external identity provider is legitimate.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* logs-azure.signinlogs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/
+* https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation
+* https://github.com/dirkjanm/ROADtools
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Sign-In Logs
+* Use Case: Identity and Access Audit
+* Tactic: Initial Access
+* Tactic: Defense Evasion
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Entra ID Service Principal Federated Credential Authentication by Unusual Client*
+
+
+If this rule triggers, it indicates that a service principal has authenticated using a federated identity credential for the first time within the historical window. This means that Entra ID validated a JWT token potentially issued by an external OIDC identity provider and issued an access token for the service principal. While this can be legitimate for CI/CD workflows (e.g., GitHub Actions, Azure DevOps, Kubernetes OIDC), it can also indicate abuse by adversaries who have configured rogue identity providers (BYOIDP) to authenticate as compromised applications. For BYOIDP attacks, this is the moment the adversary's rogue identity provider is used to authenticate as the
+compromised application for the first time.
+
+
+*Possible investigation steps*
+
+
+- Identify the service principal using `azure.signinlogs.properties.app_id` and `app_display_name`.
+- Critical: Check the application's federated credential configuration in Entra ID:
+  - What is the issuer URL? Is it a known legitimate provider (GitHub Actions, Azure DevOps, Kubernetes)?
+  - When was the federated credential added? Was it recent?
+  - Who added the federated credential?
+- Review the `service_principal_credential_thumbprint` - does it match expected certificates?
+- Investigate the source IP (`azure.signinlogs.caller_ip_address`) - is it from expected CI/CD infrastructure?
+- Check what resources were accessed after authentication using `azure.signinlogs.properties.resource_display_name`.
+- Correlate with Graph Activity logs to see what API calls were made with this token.
+- Use the `correlation_id` to find related sign-in and activity events.
+- Review audit logs for recent changes to this application's federated credentials.
+
+
+*False positive analysis*
+
+
+- Legitimate CI/CD pipelines using GitHub Actions, Azure DevOps, or Kubernetes OIDC will trigger this rule on first use.
+- New application deployments with workload identity federation are expected to show as new behavior.
+- Validate the issuer URL against approved identity providers before dismissing.
+- Create baseline of applications expected to use federated credentials.
+
+
+*Response and remediation*
+
+
+- If this is unexpected federated auth for the application, immediately investigate the federated credential configuration.
+- Review the external IdP issuer URL configured on the application - is it legitimate?
+- If BYOIDP is confirmed:
+    - Remove the malicious federated credential immediately.
+    - Revoke active sessions and tokens for the affected service principal.
+    - Audit what actions were performed using the compromised identity.
+    - Investigate how the federated credential was added (compromised admin account).
+
+==== Setup
+
+
+
+*Required Microsoft Entra ID Sign-In Logs*
+
+To use this rule, ensure that Microsoft Entra ID Sign-In Logs are being collected and streamed into the Elastic Stack via the Azure integration.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: "azure.signinlogs"
+    and azure.signinlogs.category: "ServicePrincipalSignInLogs"
+    and azure.signinlogs.properties.client_credential_type: "federatedIdentityCredential"
+    and azure.signinlogs.result_signature: "SUCCESS"
+    and azure.signinlogs.properties.app_id: *
+    and not azure.signinlogs.properties.app_owner_tenant_id: (
+        "f8cdef31-a31e-4b4a-93e4-5f571e91255a" or
+        "72f988bf-86f1-41af-91ab-2d7cd011db47"
+    )
+
+----------------------------------
+
+*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-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc
new file mode 100644
index 0000000000..0e448345dd
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc
@@ -0,0 +1,158 @@
+[[entra-id-sharepoint-or-onedrive-accessed-by-unusual-client]]
+=== Entra ID Sharepoint or OneDrive Accessed by Unusual Client
+
+Identifies when an application accesses SharePoint Online or OneDrive for Business for the first time in the tenant within a specified timeframe. This detects successful OAuth phishing campaigns, illicit consent grants, or compromised third-party applications gaining initial access to file storage. Adversaries often use malicious OAuth applications or phishing techniques to gain consent from users, allowing persistent access to organizational data repositories without traditional credential theft.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* logs-azure.signinlogs-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/
+* https://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-oauth-applications-used-to-compromise-email-servers-and-spread-spam/
+* https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/manage-consent-requests
+* https://github.com/merill/microsoft-info/blob/main/_info/MicrosoftApps.json
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Domain: Storage
+* Use Case: Identity and Access Audit
+* Tactic: Collection
+* Tactic: Initial Access
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Sign-in Logs
+* Resources: Investigation Guide
+
+*Version*: 4
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Entra ID Sharepoint or OneDrive Accessed by Unusual Client*
+
+
+This rule identifies when an application accesses SharePoint Online or OneDrive for Business for the first time in the tenant. This is a critical signal for detecting successful OAuth phishing campaigns, where adversaries trick users into granting consent to malicious applications. Once consent is granted, the malicious app can persistently access file storage without further user interaction. This detection also catches illicit consent grants, compromised third-party applications, or custom malicious apps registered by adversaries.
+
+
+*Possible Investigation Steps:*
+
+
+- Identify the Application: Review `azure.signinlogs.properties.app_id` and `azure.signinlogs.properties.app_display_name` to determine which application accessed SharePoint. Cross-reference with known legitimate applications in your environment.
+- Check Application Registration: Search Entra ID app registrations for the app ID. Determine if it's a first-party Microsoft app, known third-party integration, or suspicious/unknown application.
+- Review Consent History: Investigate when and how consent was granted. Check `azure.auditlogs` for recent `Consent to application` events matching this app ID. Identify which user granted consent and whether it was admin or user consent.
+- Analyze Permissions Granted: Review the OAuth scopes and permissions granted to the application. Look for overly broad permissions (e.g., `Files.ReadWrite.All`, `Sites.ReadWrite.All`) that exceed business requirements.
+- Correlate with User Activity: Check if the user who granted consent recently received phishing emails, clicked suspicious links, or reported potential phishing attempts.
+- Inspect Source IP and Location: Review `source.ip` and `source.geo.*` fields. Determine if the sign-in originated from expected locations or suspicious infrastructure (VPNs, data centers, anonymizers).
+- Review Application Publisher: Check if the application is verified by Microsoft or has a suspicious/generic publisher name. Unverified applications with generic names (e.g., "File Viewer", "Document Manager") are common in phishing.
+- Check for Data Access: Review subsequent SharePoint audit logs to see what files/sites the application accessed after gaining consent.
+- Conditional Access Evaluation: Review `azure.signinlogs.properties.applied_conditional_access_policies` to determine if any security controls were bypassed or if the application should have been blocked.
+
+
+*False Positive Analysis*
+
+
+- New Legitimate Integrations: Newly deployed third-party SaaS applications (e.g., document management, collaboration tools) that integrate with SharePoint will trigger this detection during initial setup. Validate with IT/procurement teams.
+- Microsoft First-Party Applications: This rule excludes common Microsoft first-party apps (Office 365 SharePoint Online, OneDrive SyncEngine, OneDrive iOS App, Microsoft Office, SharePoint Web Client Extensibility, Microsoft Teams, Office 365 Exchange Online, and other Microsoft-owned app IDs). However, new Microsoft applications or features may still appear. Cross-reference unfamiliar app IDs against Microsoft's first-party app list.
+- Development/Testing: Developers testing OAuth flows or building internal applications may generate alerts in development or staging environments.
+- Organizational Changes: Mergers, acquisitions, or tenant migrations may introduce legitimate applications from partner organizations accessing SharePoint for the first time.
+
+
+*Response and Remediation*
+
+
+- Immediate Actions if Malicious:
+  - Revoke consent for the malicious application immediately via Entra ID > Enterprise Applications
+  - Revoke all active sessions and refresh tokens for affected users
+  - Disable the application's service principal to prevent further access
+  - Review and remediate any data accessed by the application using SharePoint audit logs
+- User Notification: Contact users who granted consent to inform them of the phishing attempt and provide security awareness training on identifying malicious OAuth consent requests
+- Conditional Access Hardening: Implement or strengthen Conditional Access policies to:
+  - Require admin consent for high-risk permissions (Files.ReadWrite.All, Sites.ReadWrite.All)
+  - Block unverified publishers from accessing sensitive resources
+  - Enforce device compliance and MFA for application access
+- Tenant-Wide Review: Audit all application consents across the tenant to identify other potentially malicious applications that may have gained access through similar campaigns
+- Monitor for Campaign Patterns: Check if the same malicious application targeted multiple users, indicating an organized phishing campaign. Coordinate with email security teams to identify and block phishing emails used in the campaign.
+
+
+
+==== Setup
+
+
+
+*Required Microsoft Entra ID Sign-In Logs*
+
+To use this rule, ensure that Microsoft Entra ID Sign-In Logs are being collected and streamed into the Elastic Stack via the Azure integration.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:azure.signinlogs
+    and azure.signinlogs.properties.resource_id: (
+        00000003-0000-0ff1-ce00-000000000000 or
+        6a9b9266-8161-4a7b-913a-a9eda19da220
+    ) and azure.signinlogs.properties.app_id: ( *
+        and not (
+            00000003-0000-0ff1-ce00-000000000000 or
+            08e18876-6177-487e-b8b5-cf950c1e598c or
+            ab9b8c07-8f02-4f72-87fa-80105867a763 or
+            af124e86-4e96-495a-b70a-90f90ab96707
+        )
+    )
+    and azure.signinlogs.properties.tenant_id:*
+    and event.outcome:success
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Collection
+** ID: TA0009
+** Reference URL: https://attack.mitre.org/tactics/TA0009/
+* Technique:
+** Name: Data from Information Repositories
+** ID: T1213
+** Reference URL: https://attack.mitre.org/techniques/T1213/
+* Sub-technique:
+** Name: Sharepoint
+** ID: T1213.002
+** Reference URL: https://attack.mitre.org/techniques/T1213/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/
diff --git a/docs/detections/prebuilt-rules/rule-details/entra-id-unusual-cloud-device-registration.asciidoc b/docs/detections/prebuilt-rules/rule-details/entra-id-unusual-cloud-device-registration.asciidoc
new file mode 100644
index 0000000000..96c3143836
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/entra-id-unusual-cloud-device-registration.asciidoc
@@ -0,0 +1,143 @@
+[[entra-id-unusual-cloud-device-registration]]
+=== Entra ID Unusual Cloud Device Registration
+
+Detects a sequence of events in Microsoft Entra ID indicative of suspicious cloud-based device registration via automated tooling like ROADtools or similar frameworks. This behavior involves adding a device via the Device Registration Service, followed by the assignment of registered users and owners — a pattern consistent with techniques used to establish persistence or acquire a Primary Refresh Token (PRT). ROADtools and similar tooling leave distinct telemetry signatures such as the `Microsoft.OData.Client` user agent. These sequences are uncommon in typical user behavior and may reflect abuse of device trust for session hijacking or silent token replay.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* filebeat-*
+* logs-azure.auditlogs-*
+
+*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://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/
+* https://github.com/dirkjanm/ROADtools
+* https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/
+
+*Tags*: 
+
+* Domain: Cloud
+* Domain: Identity
+* Data Source: Azure
+* Data Source: Microsoft Entra ID
+* Data Source: Microsoft Entra ID Audit Logs
+* Use Case: Identity and Access Audit
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 3
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Entra ID Unusual Cloud Device Registration*
+
+
+This rule detects a sequence of Microsoft Entra ID audit events consistent with cloud device registration abuse via ROADtools or similar automation frameworks. The activity includes three correlated events:
+
+1. Add device operation from the Device Registration Service using suspicious user-agents (`Dsreg/*`, `DeviceRegistrationClient`, or `Microsoft.OData.Client/*`).
+2. Addition of a registered user with an `enterprise registration` URN.
+3. Assignment of a registered owner to the device.
+
+This pattern has been observed in OAuth phishing and PRT abuse campaigns where adversaries silently register a cloud device to obtain persistent, trusted access.
+
+
+*Possible investigation steps*
+
+
+- Identify the user principal associated with the device registration.
+- Review the `azure.auditlogs.identity` field to confirm the Device Registration Service initiated the request.
+- Check the user-agent in `azure.auditlogs.properties.additional_details.value`. Known attack tooling signatures include:
+  - `Dsreg/10.0 (Windows X.X.X)` - ROADtools Windows device registration
+  - `DeviceRegistrationClient` - ROADtools MacOS/Android device registration
+  - `Microsoft.OData.Client/*` - .NET-based tools or Graph SDK
+- Examine the OS version in the modified properties to identify potentially suspicious or outdated versions.
+- Verify the URN in the new value field (`urn:ms-drs:enterpriseregistration.windows.net`) is not being misused.
+- Use `azure.correlation_id` to pivot across all three steps of the registration flow.
+- Pivot to `azure.signinlogs` to detect follow-on activity using the new device, such as sign-ins involving refresh or primary refresh tokens.
+- Look for signs of persistence or lateral movement enabled by the newly registered device.
+- Identify the registered device name by reviewing `azure.auditlogs.properties.target_resources.0.display_name` and confirm it's expected for the user or organization.
+- Use the correlation ID `azure.correlation_id` to pivot into registered user events from Entra ID audit logs and check `azure.auditlogs.properties.target_resources.0.user_principal_name` to identify the user associated with the device registration.
+- Review any activity for this user from Entra ID sign-in logs, where the incoming token type is a `primaryRefreshToken`.
+
+
+*False positive analysis*
+
+
+- Some MDM, autopilot provisioning flows, or third-party device management tools may generate similar sequences. Validate against known provisioning tools, expected rollout windows, and device inventory.
+- Investigate whether the device name, OS version, and registration details align with normal IT workflows.
+- Check if the user-agent corresponds to legitimate automation or tooling used by your organization.
+
+
+*Response and remediation*
+
+
+- If confirmed malicious, remove the registered device from Entra ID.
+- Revoke refresh tokens and primary refresh tokens associated with the user and device.
+- Disable the user account and initiate password reset and identity verification procedures.
+- Review audit logs and sign-in activity for additional indicators of persistence or access from the rogue device.
+- Tighten conditional access policies to restrict device registration and enforce compliance or hybrid join requirements.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by azure.correlation_id with maxspan=5m
+[any where event.dataset == "azure.auditlogs" and
+    azure.auditlogs.identity == "Device Registration Service" and
+    azure.auditlogs.operation_name == "Add device" and
+    (
+        azure.auditlogs.properties.additional_details.value like "Microsoft.OData.Client/*" or
+        azure.auditlogs.properties.additional_details.value like "Dsreg/*" or
+        azure.auditlogs.properties.additional_details.value == "DeviceRegistrationClient"
+    ) and
+    `azure.auditlogs.properties.target_resources.0.modified_properties.1.display_name` == "CloudAccountEnabled" and
+    `azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value` == "[true]"]
+[any where event.dataset == "azure.auditlogs" and
+    azure.auditlogs.operation_name == "Add registered users to device" and
+    `azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value` like "*urn:ms-drs:enterpriseregistration.windows.net*"]
+[any where event.dataset == "azure.auditlogs" and
+    azure.auditlogs.operation_name == "Add registered owner to device"]
+
+----------------------------------
+
+*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-an-unsigned-service.asciidoc b/docs/detections/prebuilt-rules/rule-details/execution-of-an-unsigned-service.asciidoc
index cc2a8896c2..3ca8e9ebba 100644
--- a/docs/detections/prebuilt-rules/rule-details/execution-of-an-unsigned-service.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/execution-of-an-unsigned-service.asciidoc
@@ -31,7 +31,7 @@ This rule identifies the execution of unsigned executables via service control m
 * Rule Type: BBR
 * Data Source: Elastic Defend
 
-*Version*: 107
+*Version*: 108
 
 *Rule authors*: 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/execution-via-windows-subsystem-for-linux.asciidoc b/docs/detections/prebuilt-rules/rule-details/execution-via-windows-subsystem-for-linux.asciidoc
index e497ea8d5e..0a5ba71cf0 100644
--- a/docs/detections/prebuilt-rules/rule-details/execution-via-windows-subsystem-for-linux.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/execution-via-windows-subsystem-for-linux.asciidoc
@@ -46,7 +46,7 @@ Detects attempts to execute a program on the host from the Windows Subsystem for
 * Resources: Investigation Guide
 * Data Source: Sysmon
 
-*Version*: 213
+*Version*: 214
 
 *Rule authors*: 
 
@@ -109,7 +109,7 @@ Windows Subsystem for Linux (WSL) allows users to run Linux binaries natively on
 
 [source, js]
 ----------------------------------
-process where host.os.type == "windows" and event.type : "start" and
+process where host.os.type == "windows" and event.type : "start" and process.command_line != null and
   process.parent.name : ("wsl.exe", "wslhost.exe") and
   not process.executable : (
         "?:\\Program Files (x86)\\*",
@@ -118,11 +118,12 @@ process where host.os.type == "windows" and event.type : "start" and
         "?:\\Windows\\System32\\conhost.exe",
         "?:\\Windows\\System32\\lxss\\wslhost.exe",
         "?:\\Windows\\System32\\WerFault.exe",
+        "?:\\Windows\\System32\\wsl.exe",
         "?:\\Windows\\Sys?????\\wslconfig.exe"
   ) and
   not (
     /* Crowdstrike specific exclusion as it uses NT Object paths */
-    event.dataset == "crowdstrike.fdr" and
+    (event.dataset == "crowdstrike.fdr" or event.action == "ProcessRollup2") and
       process.executable : (
         "\\Device\\HarddiskVolume*\\Program Files (x86)\\*",
         "\\Device\\HarddiskVolume*\\Program Files\\*",
@@ -130,8 +131,15 @@ process where host.os.type == "windows" and event.type : "start" and
         "\\Device\\HarddiskVolume*\\Windows\\System32\\conhost.exe",
         "\\Device\\HarddiskVolume*\\Windows\\System32\\lxss\\wslhost.exe",
         "\\Device\\HarddiskVolume*\\Windows\\System32\\WerFault.exe",
+        "\\Device\\HarddiskVolume*\\Windows\\System32\\wsl.exe",
         "\\Device\\HarddiskVolume*\\Windows\\Sys?????\\wslconfig.exe"
       )
+  ) and
+  not (
+    (process.name : "cmd.exe" and process.command_line : "*echo*%USERPROFILE%*") or
+    (process.name : "git.exe" and process.command_line : "git.exe -c log.*") or
+    (process.name : "powershell.exe" and process.command_line : "powershell.exe -Command $env:USERPROFILE") or
+    (process.name : "Code.exe" and process.command_line : ("*cli.js --folder-uri=vscode-remote://wsl*", "ms-vscode-remote.remote-wsl"))
   )
 
 ----------------------------------
diff --git a/docs/detections/prebuilt-rules/rule-details/fortigate-socks-traffic-from-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/fortigate-socks-traffic-from-an-unusual-process.asciidoc
new file mode 100644
index 0000000000..3662e82647
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/fortigate-socks-traffic-from-an-unusual-process.asciidoc
@@ -0,0 +1,111 @@
+[[fortigate-socks-traffic-from-an-unusual-process]]
+=== FortiGate SOCKS Traffic from an Unusual Process
+
+This detection correlates FortiGate's application control SOCKS events with Elastic Defend network event to identify the source process performing SOCKS traffic. Adversaries may use a connection proxy to direct network traffic between systems or act as an intermediary for network communications to a command and control server to avoid direct connections to their infrastructure.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-endpoint.events.network-*
+* logs-fortinet_fortigate.log-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://attack.mitre.org/techniques/T1090/
+* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate
+* https://www.elastic.co/docs/reference/integrations/endpoint
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* OS: Windows
+* OS: macOS
+* Use Case: Threat Detection
+* Tactic: Command and Control
+* Data Source: Elastic Defend
+* Data Source: Fortinet
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating FortiGate SOCKS Traffic from an Unusual Process*
+
+
+
+*Possible investigation steps*
+
+
+- Review the process details like command_line, privileges, global relevance and reputation.
+- Review the parent process execution details like command_line, global relevance and reputation.
+- Examine all network connection details performed by the process during last 48h.
+- Examine all localhost network connections performed by the same process to verify if there is any port forwarding with another process on the same machine.
+- Correlate the alert with other security events or logs to identify any patterns or additional indicators of compromise related to the same process or network activity.
+
+
+*False positive analysis*
+
+
+- Browser proxy extensions and Add-ons.
+- Development and deployment tools.
+- Third party trusted tools using SOCKS for network communication.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the suspicious processes and all associated children and parents.
+- Conduct a thorough review of the system's configuration files to identify unauthorized changes.
+- Reset credentials for any accounts associated with the source machine.
+- Implement network-level controls to block traffic via SOCKS unless authorized.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by source.port, source.ip, destination.ip with maxspan=1m
+ [network where event.dataset == "fortinet_fortigate.log" and event.action == "signature" and network.application in ("SOCKS4", "SOCKS5")]
+ [network where event.module == "endpoint" and event.action in ("disconnect_received", "connection_attempted")]
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Command and Control
+** ID: TA0011
+** Reference URL: https://attack.mitre.org/tactics/TA0011/
+* Technique:
+** Name: Proxy
+** ID: T1090
+** Reference URL: https://attack.mitre.org/techniques/T1090/
diff --git a/docs/detections/prebuilt-rules/rule-details/fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc
new file mode 100644
index 0000000000..d45a138291
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc
@@ -0,0 +1,104 @@
+[[fortigate-ssl-vpn-login-followed-by-siem-alert-by-user]]
+=== FortiGate SSL VPN Login Followed by SIEM Alert by User
+
+Detects when a FortiGate SSL VPN login event is followed by any SIEM detection alert for the same user name within a short time window. This correlation can indicate abuse of VPN access for malicious activity, credential compromise used from a VPN session, or initial access via VPN followed by post-compromise behavior.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-fortinet_fortigate.log-*
+* .alerts-security.*
+
+*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/tactics/TA0001/
+* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate
+
+*Tags*: 
+
+* Use Case: Threat Detection
+* Rule Type: Higher-Order Rule
+* Tactic: Initial Access
+* Data Source: Fortinet
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating FortiGate SSL VPN Login Followed by SIEM Alert by User*
+
+
+This rule correlates a FortiGate SSL VPN login with a subsequent security alert for the same user name, highlighting possible abuse of VPN access or activity shortly after remote access.
+
+
+*Possible investigation steps*
+
+
+- Review the FortiGate login event (source IP, user, time) and the SIEM alert(s) that followed for the same user.
+- Determine whether the user is expected to use VPN and whether the subsequent alert is related to legitimate work (e.g. admin tools, updates).
+- Check for other alerts or logins for the same user in the same time window to assess scope.
+- Correlate with authentication logs to identify impossible travel or credential reuse from the VPN session.
+
+
+*False positive analysis*
+
+
+- Legitimate VPN users triggering detections (e.g. scripted tasks, admin tooling) after login.
+- Security scans or automated jobs that run in the context of a VPN-authenticated user.
+
+
+*Response and remediation*
+
+
+- If abuse or compromise is suspected, disable or reset the user’s VPN access and credentials.
+- Investigate the host and process associated with the SIEM alert.
+- Escalate to the security or incident response team if the alert indicates malicious activity.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by user.name with maxspan=10m
+ [authentication where event.dataset == "fortinet_fortigate.log" and event.action == "login" and event.code in ("0101039426", "0101039427")]
+ [any where event.kind == "signal" and kibana.alert.rule.name != null and event.dataset != "fortinet_fortigate.log" and
+  kibana.alert.risk_score > 21 and kibana.alert.rule.rule_id != "a7f2c1b4-5d8e-4f3a-9b0c-2e1d4a6b8f3e" and user.name != null]
+
+----------------------------------
+
+*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/rule-details/high-mean-of-process-arguments-in-an-rdp-session.asciidoc b/docs/detections/prebuilt-rules/rule-details/high-mean-of-process-arguments-in-an-rdp-session.asciidoc
index 16e9624db1..19ed31f8cd 100644
--- a/docs/detections/prebuilt-rules/rule-details/high-mean-of-process-arguments-in-an-rdp-session.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/high-mean-of-process-arguments-in-an-rdp-session.asciidoc
@@ -32,7 +32,7 @@ A machine learning job has detected unusually high number of process arguments i
 * Tactic: Lateral Movement
 * Resources: Investigation Guide
 
-*Version*: 7
+*Version*: 8
 
 *Rule authors*: 
 
@@ -96,6 +96,12 @@ Remote Desktop Protocol (RDP) facilitates remote access to systems, often target
 *Setup*
 
 
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
 The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/high-mean-of-rdp-session-duration.asciidoc b/docs/detections/prebuilt-rules/rule-details/high-mean-of-rdp-session-duration.asciidoc
index a63b377862..0795ee07b4 100644
--- a/docs/detections/prebuilt-rules/rule-details/high-mean-of-rdp-session-duration.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/high-mean-of-rdp-session-duration.asciidoc
@@ -32,7 +32,7 @@ A machine learning job has detected unusually high mean of RDP session duration.
 * Tactic: Lateral Movement
 * Resources: Investigation Guide
 
-*Version*: 7
+*Version*: 8
 
 *Rule authors*: 
 
@@ -97,6 +97,12 @@ Remote Desktop Protocol (RDP) enables remote access to systems, facilitating adm
 *Setup*
 
 
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
 The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/high-variance-in-rdp-session-duration.asciidoc b/docs/detections/prebuilt-rules/rule-details/high-variance-in-rdp-session-duration.asciidoc
index fa1a7abd55..3ff6dc6a58 100644
--- a/docs/detections/prebuilt-rules/rule-details/high-variance-in-rdp-session-duration.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/high-variance-in-rdp-session-duration.asciidoc
@@ -32,7 +32,7 @@ A machine learning job has detected unusually high variance of RDP session durat
 * Tactic: Lateral Movement
 * Resources: Investigation Guide
 
-*Version*: 7
+*Version*: 8
 
 *Rule authors*: 
 
@@ -97,6 +97,12 @@ Remote Desktop Protocol (RDP) enables remote access to systems, facilitating leg
 *Setup*
 
 
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
 The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc b/docs/detections/prebuilt-rules/rule-details/kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc
new file mode 100644
index 0000000000..df004dd597
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc
@@ -0,0 +1,130 @@
+[[kernel-instrumentation-discovery-via-kprobes-and-tracefs]]
+=== Kernel Instrumentation Discovery via kprobes and tracefs
+
+Detects common utilities accessing kprobes and tracing-related paths in debugfs/tracefs, which may indicate discovery of kernel instrumentation hooks. Adversaries can enumerate these locations to understand or prepare for eBPF, kprobe, or tracepoint-based activity. This behavior can also be benign during troubleshooting, performance analysis, or observability tooling validation.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* auditbeat-*
+* endgame-*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+* logs-sentinel_one_cloud_funnel.*
+* logs-crowdstrike.fdr*
+
+*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: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Discovery
+* Tactic: Defense Evasion
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Auditd Manager
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Kernel Instrumentation Discovery via kprobes and tracefs*
+
+
+This rule detects common Linux utilities and shells reading kprobes and tracing locations under debugfs/tracefs, signaling discovery of kernel instrumentation hooks. Attackers use this to understand which kprobe/tracepoint interfaces are available or already in use before deploying eBPF-based collection or stealthy monitoring. A typical pattern is a script that iterates tracing directories and reads kprobe and tracepoint listings to map callable probes and active tracing state.
+
+
+*Possible investigation steps*
+
+
+- Review the full command line and the specific tracefs/debugfs paths accessed to determine whether this was benign directory enumeration or targeted inspection of sensitive files like `available_filter_functions`, `kprobe_events`, `set_ftrace_filter`, or `trace_pipe`.  
+- Identify the initiating user and process tree, then search nearby activity for follow-on steps such as writing to `kprobe_events`/`uprobe_events`, enabling tracing events, or sustained reads from `trace_pipe`.  
+- Validate whether `debugfs`/`tracefs` are mounted and assess the host’s role and installed observability/performance tooling to quickly separate routine diagnostics from unexpected tracing access.  
+- Hunt for adjacent signals of kernel instrumentation setup or abuse, including use of eBPF tooling (`bpftool`, `bpftrace`, BCC), `perf`, suspicious `bpf()` syscall activity, or module loading around the same time window.  
+- Compare current tracing configuration and recent file modification activity under `/sys/kernel/debug/tracing` and `/sys/kernel/tracing` against baseline expectations to detect tampering or persistence.
+
+
+*False positive analysis*
+
+
+- A system administrator or automated diagnostic script may use basic utilities like `cat`, `grep`, or `find` to enumerate `/sys/kernel/debug/tracing` or `/sys/kernel/tracing` during kernel troubleshooting or performance triage to confirm tracefs/debugfs is mounted and to review available functions/events.
+- Routine validation of tracing configuration after kernel upgrades or configuration changes can involve shells running `ls`, `stat`, or `readlink` over kprobe and tracing paths to verify current settings and permissions, even when no malicious instrumentation is intended.
+
+
+*Response and remediation*
+
+
+- Contain suspected abuse by isolating the host and immediately stopping the offending script/process tree that is enumerating `/sys/kernel/debug/kprobes/*` or `/sys/kernel/*tracing/*`, then preserve the shell history and the script/binary on disk for analysis.  
+- Eradicate kernel instrumentation changes by checking for and removing any attacker-added entries in `kprobe_events`/`uprobe_events`, disabling any enabled tracing knobs, and remounting or unmounting `debugfs`/`tracefs` if they are not required for operations.  
+- Recover to a known-good state by rebooting to clear transient tracing state, validating that `trace_pipe` is not being read continuously, and confirming that expected observability tooling (if any) still functions after tracing is reset.  
+- Escalate to incident response immediately if you observe writes to `kprobe_events`/`uprobe_events`, sustained reads from `trace_pipe`, or nearby execution of eBPF/performance tooling (e.g., `bpftool`, `bpftrace`, `perf`) by an unexpected user or from an unusual parent process.  
+- Harden to prevent recurrence by restricting access to `debugfs`/`tracefs` to administrators only, disabling unprivileged BPF where feasible, and enforcing MAC policies (SELinux/AppArmor) to deny non-approved processes from reading or writing tracing interfaces.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and
+event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+process.name in (
+  "cat", "grep", "head", "tail", "ls",
+  "less", "more",
+  "awk", "sed", "cut", "tr", "xargs", "tee",
+  "find", "stat", "readlink",
+  "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox"
+) and
+process.args like ("/sys/kernel/debug/kprobes/*", "/sys/kernel/debug/tracing/*", "/sys/kernel/tracing/*")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Discovery
+** ID: TA0007
+** Reference URL: https://attack.mitre.org/tactics/TA0007/
+* Technique:
+** Name: System Information Discovery
+** ID: T1082
+** Reference URL: https://attack.mitre.org/techniques/T1082/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Rootkit
+** ID: T1014
+** Reference URL: https://attack.mitre.org/techniques/T1014/
diff --git a/docs/detections/prebuilt-rules/rule-details/kernel-module-load-from-unusual-location.asciidoc b/docs/detections/prebuilt-rules/rule-details/kernel-module-load-from-unusual-location.asciidoc
new file mode 100644
index 0000000000..936f57c312
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/kernel-module-load-from-unusual-location.asciidoc
@@ -0,0 +1,179 @@
+[[kernel-module-load-from-unusual-location]]
+=== Kernel Module Load from Unusual Location
+
+This rule detects the loading of a kernel module from an unusual location. Threat actors may use this technique to maintain persistence on a system by loading a kernel module into the kernel namespace. This behavior is strongly related to the presence of a rootkit on the system.
+
+*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://decoded.avast.io/davidalvarez/linux-threat-hunting-syslogk-a-kernel-rootkit-found-under-development-in-the-wild/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Defense Evasion
+* Threat: Rootkit
+* Data Source: Elastic Defend
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Kernel Module Load from Unusual Location*
+
+
+This rule detects attempts to load Linux kernel modules from atypical directories, which can indicate an attacker trying to run code in kernel space for stealth and long-term persistence. Adversaries often drop a malicious `.ko` into writable paths like `/tmp` or `/dev/shm` after initial access, then use `insmod` or `modprobe` to insert it and hide processes, files, or network activity as a rootkit.
+
+
+*Possible investigation steps*
+
+
+- Capture the full command line and resolve any referenced `.ko` path, then collect the module file for hashing and static analysis to determine provenance and known-malware matches.  
+- Confirm whether the module is currently loaded by querying `lsmod`/`/proc/modules`, then map it to its on-disk location with `modinfo -n <module>` (or `/sys/module/<module>/sections/*`) to validate it was loaded from the suspicious directory.  
+- Review recent kernel and audit telemetry (`dmesg`, `/var/log/kern.log`, `journalctl -k`, and any audit records) around the event time for insertion messages, signature/taint indicators, and any follow-on errors suggesting tampering.  
+- Identify the initiating user/session and execution chain (parent process tree, TTY/SSH source, container context), then determine whether the action aligns with legitimate admin activity or coincides with other compromise signals on the host.  
+- Hunt for persistence and repeatability by checking for recurring module-load attempts and inspecting boot-time and scheduled execution paths (systemd units, init scripts, cron, rc.local) that could reload the module after reboot.
+
+
+*False positive analysis*
+
+
+- A system administrator or automated maintenance workflow may build or test an out-of-tree kernel module and load it with `insmod`/`modprobe` from a staging directory such as `/tmp`, `/root`, or `/mnt` before installing it into standard module paths.  
+- A legitimate bootstrapping or recovery operation may load a required driver module from nonstandard media or temporary runtime locations (e.g., `/boot`, `/run`, `/var/run`, or `/mnt`) during troubleshooting, initramfs/early-boot tasks, or mounting encrypted/storage devices.
+
+
+*Response and remediation*
+
+
+- Isolate the affected Linux host from the network and disable external access (e.g., revoke SSH keys or block inbound SSH) to prevent additional module loads or lateral movement while preserving evidence.  
+- If the suspicious module is currently loaded, record `lsmod` and `modinfo` output, then unload it where safe (`modprobe -r <name>`/`rmmod <name>`) and quarantine the corresponding `.ko` from the unusual path (e.g., `/tmp`, `/dev/shm`, `/home`, `/mnt`) for hashing and malware analysis.  
+- Remove persistence mechanisms that would reload the module by deleting or disabling any related systemd units, init scripts, cron entries, and boot-time hooks, and validate `/etc/modules-load.d/`, `/lib/modules/$(uname -r)/`, and `depmod` outputs for unauthorized additions.  
+- Recover the host by restoring known-good kernel/module packages and rebuilding the initramfs, then reboot and verify no unexpected modules remain in `/proc/modules` and no new load attempts occur from writable directories.  
+- Escalate immediately to IR/forensics and consider full host rebuild if the module is unsigned/unknown, the kernel is tainted, module removal fails, or post-reboot evidence indicates stealth behavior consistent with a rootkit.  
+- Harden by restricting module loading (enable Secure Boot/module signature enforcement where supported, set `kernel.modules_disabled=1` after boot on fixed-function systems, and limit `CAP_SYS_MODULE` to trusted admins), and enforce file integrity monitoring/permissions to prevent `.ko` creation in world-writable locations.
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from Elastic Defend.
+
+
+*Elastic Defend Integration Setup*
+
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+
+
+*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide].
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide].
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
+  (process.name == "kmod" and process.args == "insmod" and process.args like~ "*.ko*") or
+  (process.name == "kmod" and process.args == "modprobe" and not process.args in ("-r", "--remove")) or
+  (process.name == "insmod" and process.args like~ "*.ko*") or
+  (process.name == "modprobe" and not process.args in ("-r", "--remove"))
+) and (
+  process.working_directory like (
+    "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "/home/*/*", "/root/*",
+    "/var/www/*", "/boot/*", "/srv/*", "/mnt/*"
+  ) or
+  process.parent.working_directory like (
+    "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "/home/*/*", "/root/*",
+    "/var/www/*", "/boot/*", "/srv/*", "/mnt/*"
+  ) or
+  process.args like (
+    "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "/home/*/*", "/root/*",
+    "/var/www/*", "/boot/*", "/srv/*", "/mnt/*", "./*"
+  )
+) and
+not (
+  process.parent.executable == "/usr/bin/podman" or
+  process.working_directory like "/tmp/newroot"
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Boot or Logon Autostart Execution
+** ID: T1547
+** Reference URL: https://attack.mitre.org/techniques/T1547/
+* Sub-technique:
+** Name: Kernel Modules and Extensions
+** ID: T1547.006
+** Reference URL: https://attack.mitre.org/techniques/T1547/006/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Rootkit
+** ID: T1014
+** Reference URL: https://attack.mitre.org/techniques/T1014/
diff --git a/docs/detections/prebuilt-rules/rule-details/kernel-module-load-via-built-in-utility.asciidoc b/docs/detections/prebuilt-rules/rule-details/kernel-module-load-via-built-in-utility.asciidoc
new file mode 100644
index 0000000000..885114f438
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/kernel-module-load-via-built-in-utility.asciidoc
@@ -0,0 +1,226 @@
+[[kernel-module-load-via-built-in-utility]]
+=== Kernel Module Load via Built-in Utility
+
+Detects the use of the insmod binary to load a Linux kernel object file. Threat actors can use this binary, given they have root privileges, to load a rootkit on a system providing them with complete control and the ability to hide from security products. Manually loading a kernel module in this manner should not be at all common and can indicate suspicious or malicious behavior.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* auditbeat-*
+* endgame-*
+* logs-auditd_manager.auditd-*
+* logs-endpoint.events.process*
+* logs-sentinel_one_cloud_funnel.*
+* logs-crowdstrike.fdr*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://decoded.avast.io/davidalvarez/linux-threat-hunting-syslogk-a-kernel-rootkit-found-under-development-in-the-wild/
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Linux
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Tactic: Defense Evasion
+* Threat: Rootkit
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Auditd Manager
+* Data Source: SentinelOne
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 216
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Kernel Module Load via Built-in Utility*
+
+
+Threat actors with root privileges may abuse pre-installed binaries to load loadable kernel modules (LKMs), which are object files that extend the functionality of the kernel. 
+
+Threat actors can abuse this utility to load rootkits, granting them full control over the system and the ability to evade security products.
+
+The detection rule 'Kernel Module Load via Built-in Utility' is designed to identify instances where these binaries are used to load a kernel object file (with a .ko extension) on a Linux system. This activity is uncommon and may indicate suspicious or malicious behavior.
+
+> **Note**:
+> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
+> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run.
+
+
+*Possible investigation steps*
+
+
+- Investigate the kernel object file that was loaded.
+  - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}}
+- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations.
+  - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}}
+- Investigate the kernel ring buffer for any warnings or messages, such as tainted or out-of-tree kernel module loads through `dmesg`.
+- Investigate syslog for any unusual segfaults or other messages. Rootkits may be installed on targets with different architecture as expected, and could potentially cause segmentation faults. 
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.
+- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. 
+  - If scripts or executables were dropped, retrieve the files and determine if they are malicious:
+    - Use a private sandboxed malware analysis system to perform analysis.
+      - Observe and collect information about the following activities:
+        - Attempts to contact external domains and addresses.
+          - Check if the domain is newly registered or unexpected.
+          - Check the reputation of the domain or IP address.
+        - File access, modification, and creation activities.
+- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes.
+  - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration.
+    - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}}
+    - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}}
+  - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action.
+    - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}}
+- Investigate whether the user is currently logged in and active.
+    - $osquery_6
+
+
+*False positive analysis*
+
+
+- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions.
+- If this activity is related to a system administrator who uses cron jobs for administrative purposes, consider adding exceptions for this specific administrator user account. 
+- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.
+
+
+*Related Rules*
+
+
+- Kernel Driver Load - 3e12a439-d002-4944-bc42-171c0dcb9b96
+- Tainted Out-Of-Tree Kernel Module Load - 51a09737-80f7-4551-a3be-dac8ef5d181a
+- Tainted Kernel Module Load - 05cad2fb-200c-407f-b472-02ea8c9e5e4a
+- Attempt to Clear Kernel Ring Buffer - 2724808c-ba5d-48b2-86d2-0002103df753
+- Enumeration of Kernel Modules via Proc - 80084fa9-8677-4453-8680-b891d3c0c778
+- Suspicious Modprobe File Event - 40ddbcc8-6561-44d9-afc8-eefdbfe0cccd
+- Kernel Module Removal - cd66a5af-e34b-4bb0-8931-57d0a043f2ef
+- Enumeration of Kernel Modules - 2d8043ed-5bda-4caf-801c-c1feb7410504
+
+
+*Response and Remediation*
+
+
+- Initiate the incident response process based on the outcome of the triage.
+- Isolate the involved host to prevent further post-compromise behavior.
+- If the triage identified malware, search the environment for additional compromised hosts.
+  - Implement temporary network rules, procedures, and segmentation to contain the malware.
+  - Stop suspicious processes.
+  - Immediately block the identified indicators of compromise (IoCs).
+  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires data coming in from Elastic Defend.
+
+
+*Elastic Defend Integration Setup*
+
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+
+*Prerequisite Requirements:*
+
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation].
+
+
+*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:*
+
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide].
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide].
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide].
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "linux" and event.type == "start" and
+event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and (
+  (process.name == "kmod" and process.args == "insmod" and process.args like~ "*.ko*") or
+  (process.name == "kmod" and process.args == "modprobe" and not process.args in ("-r", "--remove")) or
+  (process.name == "insmod" and process.args like~ "*.ko*") or
+  (process.name == "modprobe" and not process.args in ("-r", "--remove"))
+) and
+not (
+  ?process.parent.executable like ("/opt/ds_agent/*", "/opt/TrendMicro/vls_agent/*", "/opt/intel/oneapi/*") or
+  ?process.working_directory in ("/opt/vinchin/agent", "/var/opt/ds_agent/am", "/opt/ds_agent", "/var/opt/TrendMicro/vls_agent/am") or
+  ?process.parent.executable in (
+    "/usr/lib/uptrack/ksplice-apply", "/opt/commvault/commvault/Base/linux_drv", "/opt/cisco/amp/bin/cisco-amp-helper",
+    "/usr/bin/kcarectl", "/usr/share/ksplice/ksplice-apply", "/opt/commvault/Base/linux_drv", "/usr/sbin/veeamsnap-loader",
+    "/bin/falcoctl"
+  ) or
+  (?process.parent.name like ("python*", "platform-python*") and ?process.parent.args in ("--smart-update", "--auto-update"))
+)
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Boot or Logon Autostart Execution
+** ID: T1547
+** Reference URL: https://attack.mitre.org/techniques/T1547/
+* Sub-technique:
+** Name: Kernel Modules and Extensions
+** ID: T1547.006
+** Reference URL: https://attack.mitre.org/techniques/T1547/006/
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Rootkit
+** ID: T1014
+** Reference URL: https://attack.mitre.org/techniques/T1014/
diff --git a/docs/detections/prebuilt-rules/rule-details/lateral-movement-alerts-from-a-newly-observed-source-address.asciidoc b/docs/detections/prebuilt-rules/rule-details/lateral-movement-alerts-from-a-newly-observed-source-address.asciidoc
index a9043e2291..c36a76113e 100644
--- a/docs/detections/prebuilt-rules/rule-details/lateral-movement-alerts-from-a-newly-observed-source-address.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/lateral-movement-alerts-from-a-newly-observed-source-address.asciidoc
@@ -28,7 +28,7 @@ This rule detects source IPs that triggered their first lateral movement alert w
 * Tactic: Lateral Movement
 * Resources: Investigation Guide
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -80,6 +80,20 @@ whether it represents a true compromise or rare benign activity.
 - If benign, document the finding and consider tuning or exception handling to reduce future noise.
 - Continue monitoring the host and environment for recurrence of the behavior or related alerts.
 
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
+
 ==== Rule query
 
 
@@ -90,7 +104,7 @@ FROM .alerts-security.* METADATA _index
 // Lateral Movement related rules with fields of interest
 | where kibana.alert.rule.threat.tactic.name is not null and
         source.ip IS NOT NULL and destination.ip is not null and
-        host.id is not null and KQL("""kibana.alert.rule.threat.tactic.name : "Lateral Movement" """)
+        host.id is not null and KQL("""kibana.alert.rule.threat.tactic.name : "Lateral Movement" and not kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
 
 // aggregate stats by source.ip
 | stats  Esql.first_time_seen = MIN(@timestamp),
diff --git a/docs/detections/prebuilt-rules/rule-details/lateral-movement-alerts-from-a-newly-observed-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/lateral-movement-alerts-from-a-newly-observed-user.asciidoc
index dd52ab36c7..dfc4b088bd 100644
--- a/docs/detections/prebuilt-rules/rule-details/lateral-movement-alerts-from-a-newly-observed-user.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/lateral-movement-alerts-from-a-newly-observed-user.asciidoc
@@ -29,7 +29,7 @@ This rule detects multiple lateral movement alerts from a user that was observed
 * Tactic: Lateral Movement
 * Resources: Investigation Guide
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -91,7 +91,8 @@ FROM .alerts-security.* METADATA _index
 // Lateral Movement related rules
 | where kibana.alert.rule.threat.tactic.name is not null and user.id is not null and 
         (to_string(user.id) like "S-1-5-21*" or to_string(user.id) like "S-1-12-*") and
-        host.id is not null and KQL("""kibana.alert.rule.threat.tactic.name : "Lateral Movement" """)
+        host.id is not null and KQL("""kibana.alert.rule.threat.tactic.name : "Lateral Movement" """) and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
 
 // aggregate stats by user.id
 | stats  Esql.first_time_seen = MIN(@timestamp),
diff --git a/docs/detections/prebuilt-rules/rule-details/m365-identity-unusual-sso-authentication-errors-for-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/m365-identity-unusual-sso-authentication-errors-for-user.asciidoc
new file mode 100644
index 0000000000..2e47d9b733
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/m365-identity-unusual-sso-authentication-errors-for-user.asciidoc
@@ -0,0 +1,142 @@
+[[m365-identity-unusual-sso-authentication-errors-for-user]]
+=== M365 Identity Unusual SSO Authentication Errors for User
+
+Identifies the first occurrence of SSO, SAML, or federated authentication errors for a user. These errors may indicate token manipulation, SAML assertion tampering, or OAuth phishing attempts. Modern adversaries often target SSO mechanisms through token theft, SAML response manipulation, or exploiting federated authentication weaknesses rather than traditional brute force attacks.
+
+*Rule type*: new_terms
+
+*Rule indices*: 
+
+* logs-o365.audit-*
+* filebeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://techcommunity.microsoft.com/blog/microsoft-entra-blog/understanding-and-mitigating-golden-saml-attacks/4418864
+* https://www.semperis.com/blog/meet-silver-saml/
+
+*Tags*: 
+
+* Domain: Identity
+* Data Source: Microsoft 365
+* Data Source: Microsoft 365 Audit Logs
+* Use Case: Identity and Access Audit
+* Use Case: Threat Detection
+* Tactic: Initial Access
+* Resources: Investigation Guide
+
+*Version*: 213
+
+*Rule authors*: 
+
+* Elastic
+* Austin Songer
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating M365 Identity Unusual SSO Authentication Errors for User*
+
+
+SSO, SAML, and federated authentication mechanisms are critical infrastructure for modern identity access. Adversaries increasingly
+target these systems through token manipulation, SAML response tampering, OAuth phishing, and exploitation of federated trust
+relationships rather than traditional credential brute forcing. This detection identifies when a user experiences SSO-related
+authentication errors that are unusual for their typical behavior, which may indicate an attacker attempting to abuse stolen tokens or manipulate
+authentication flows.
+
+
+*Possible investigation steps*
+
+
+- Review the specific error code(s) in the `o365.audit.ErrorNumber` field to understand the nature of the authentication failure
+  (e.g., token signature failure, SAML assertion tampering, cross-tenant token misuse). Reference Microsoft's AADSTS error codes
+  at https://login.microsoftonline.com/error?code=<ErrorNumber> for detailed descriptions.
+- Examine the source IP address and geolocation of the authentication attempt - compare against the user's typical login patterns.
+- Check for concurrent authentication activity from the same user - multiple SSO errors alongside successful logins may indicate
+  token replay or session hijacking attempts.
+- Investigate recent OAuth application consent activity for this user - OAuth phishing campaigns often precede SSO manipulation attempts.
+- Review the target application or service principal being accessed during the failed authentication to identify potential attacker objectives.
+- Analyze the user's recent mailbox activity, particularly for phishing emails with OAuth consent links or suspicious authentication requests.
+- Check for any recent changes to the user's federation settings, registered devices, or authentication methods.
+- Correlate with Entra ID risky sign-in detections and risky user alerts for the same account.
+
+
+*False positive analysis*
+
+
+- First-time SSO setup: Users configuring SSO access to a new federated application may encounter initial authentication errors.
+  Validate whether the errors occurred during expected onboarding windows.
+- Federation service outages: Widespread SSO errors affecting multiple users simultaneously often indicate infrastructure issues
+  rather than targeted attacks. Check for service health incidents in the same timeframe.
+- Certificate rotation: Federated authentication certificate renewals can temporarily cause signature validation errors. Verify
+  if the errors align with planned certificate maintenance.
+- Legitimate cross-tenant access: Users with business relationships across multiple tenants may encounter cross-tenant policy
+  errors during authorized access attempts.
+
+
+*Response and remediation*
+
+
+- If token manipulation or SAML tampering is suspected, immediately revoke all active sessions and refresh tokens for the affected user.
+- Review and audit all OAuth application consents granted by the user - remove any suspicious or unrecognized applications.
+- Enable Conditional Access policies requiring compliant devices and MFA for SSO authentication if not already enforced.
+- If cross-tenant token misuse is detected, review and restrict external collaboration settings and cross-tenant access policies.
+- For SAML assertion or signature errors, validate the integrity of federation trust certificates and metadata.
+- Investigate whether the user's credentials have been compromised - enforce password reset if credential theft is suspected.
+- Review Entra ID audit logs for unusual application registrations, service principal modifications, or federation setting changes.
+- Escalate to the security operations team if evidence suggests active token theft, SAML Golden Ticket techniques, or OAuth phishing campaigns.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:o365.audit
+    and event.provider:AzureActiveDirectory
+    and event.category:authentication
+    and o365.audit.ErrorNumber:(
+        20001 or 20012 or 20033 or 40008 or 40009 or 40015 or
+        50006 or 50008 or 50012 or 50013 or 50027 or 50048 or
+        50099 or 50132 or 75005 or 75008 or 75011 or 75016 or
+        81004 or 81009 or 81010 or 399284 or 500212 or 500213 or
+        700005 or 5000819
+    )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* Sub-technique:
+** Name: Cloud Accounts
+** ID: T1078.004
+** Reference URL: https://attack.mitre.org/techniques/T1078/004/
+* Technique:
+** Name: Phishing
+** ID: T1566
+** Reference URL: https://attack.mitre.org/techniques/T1566/
diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc
index 8a53b49d64..a0a84216f7 100644
--- a/docs/detections/prebuilt-rules/rule-details/multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc
@@ -25,7 +25,7 @@ This rule correlates multiple security alerts associated with the same ATT&CK ta
 * Rule Type: Higher-Order Rule
 * Resources: Investigation Guide
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -101,7 +101,8 @@ from .alerts-security.*  metadata _id
         kibana.alert.rule.threat.tactic.name in ("Credential Access", "Defense Evasion", "Execution", "Command and Control") and
 
         // excluding some noisy rules
-        not kibana.alert.rule.name in ("Agent Spoofing - Mismatched Agent ID", "Process Termination followed by Deletion")
+        not kibana.alert.rule.name in ("Agent Spoofing - Mismatched Agent ID", "Process Termination followed by Deletion") and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
 
 // extract unique counts and values by host.id and tactic name
 | stats Esql.alerts_count = COUNT(*),
diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-alerts-involving-a-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-alerts-involving-a-user.asciidoc
index 8fae4f0310..5cd3034173 100644
--- a/docs/detections/prebuilt-rules/rule-details/multiple-alerts-involving-a-user.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/multiple-alerts-involving-a-user.asciidoc
@@ -25,7 +25,7 @@ This rule uses alert data to determine when multiple different alerts involving
 * Rule Type: Higher-Order Rule
 * Resources: Investigation Guide
 
-*Version*: 6
+*Version*: 7
 
 *Rule authors*: 
 
@@ -92,7 +92,8 @@ In security environments, monitoring user activity is crucial as adversaries oft
 from .alerts-security.*
 | where kibana.alert.rule.name is not null and user.id is not null and
   // Exclude low severity alerts
-  kibana.alert.risk_score > 21
+  kibana.alert.risk_score > 21 and
+  not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
 | stats
     Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), 
     Esql.rule_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.rule_id),
diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-alerts-on-a-host-exhibiting-cpu-spike.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-alerts-on-a-host-exhibiting-cpu-spike.asciidoc
index dc6a037551..7c080468b9 100644
--- a/docs/detections/prebuilt-rules/rule-details/multiple-alerts-on-a-host-exhibiting-cpu-spike.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/multiple-alerts-on-a-host-exhibiting-cpu-spike.asciidoc
@@ -27,7 +27,7 @@ This rule correlates multiple security alerts from a host exhibiting unusually h
 * Domain: Endpoint
 * Tactic: Impact
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -135,6 +135,7 @@ https://docs.elastic.co/integrations/system
 [source, js]
 ----------------------------------
 FROM metrics-*, .alerts-security.*  METADATA _index
+| where not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
 | eval
        // hosts with more than 90% total CPU use
        cpu_metrics_host_ids = CASE(_index like ".ds-metrics-system.cpu-*" and system.cpu.total.norm.pct >= 0.9, host.id, null),
diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-external-edr-alerts-by-host.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-external-edr-alerts-by-host.asciidoc
index 5ec86199ad..491c81640b 100644
--- a/docs/detections/prebuilt-rules/rule-details/multiple-external-edr-alerts-by-host.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/multiple-external-edr-alerts-by-host.asciidoc
@@ -28,7 +28,7 @@ This rule uses alert data to determine when multiple external EDR alerts involvi
 * Resources: Investigation Guide
 * Domain: Endpoint
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -94,7 +94,8 @@ Endpoint security technologies monitor and analyze activities on devices to dete
 from .alerts-security.*
 | WHERE event.dataset in ("crowdstrike.alert", "crowdstrike.falcon", "sentinel_one.alert", "sentinel_one.threat", "m365_defender.alert") and
         host.id is not null and kibana.alert.risk_score > 21 and
-        not (event.module == "crowdstrike" and (kibana.alert.rule.name like "* at *" or kibana.alert.rule.name like "* on *" or kibana.alert.rule.name == "EICARTestFileWrittenWin"))
+        not (event.module == "crowdstrike" and (kibana.alert.rule.name like "* at *" or kibana.alert.rule.name like "* on *" or kibana.alert.rule.name == "EICARTestFileWrittenWin")) and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
 | stats Esql.alerts_count = COUNT(*),
         Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),
         Esql.unique_rules_count = COUNT_DISTINCT(kibana.alert.rule.name),
diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-machine-learning-alerts-by-influencer-field.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-machine-learning-alerts-by-influencer-field.asciidoc
index d79248d6de..f33992ca1c 100644
--- a/docs/detections/prebuilt-rules/rule-details/multiple-machine-learning-alerts-by-influencer-field.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/multiple-machine-learning-alerts-by-influencer-field.asciidoc
@@ -28,7 +28,7 @@ This rule uses alerts data to determine when multiple unique machine learning jo
 * Resources: Investigation Guide
 * Rule Type: Machine Learning
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -90,7 +90,8 @@ Attackers may trigger multiple alerts by performing suspicious actions under a c
 [source, js]
 ----------------------------------
 from .alerts-security.*
-| where kibana.alert.rule.type == "machine_learning"
+| where kibana.alert.rule.type == "machine_learning" and
+  not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
 | stats Esql.count_distinct_job_id = COUNT_DISTINCT(job_id),
         Esql.job_id_values = VALUES(job_id),
         Esql.rule_name_values = VALUES(kibana.alert.rule.name),
diff --git a/docs/detections/prebuilt-rules/rule-details/newly-observed-fortigate-alert.asciidoc b/docs/detections/prebuilt-rules/rule-details/newly-observed-fortigate-alert.asciidoc
index 7449a8020e..190c87413d 100644
--- a/docs/detections/prebuilt-rules/rule-details/newly-observed-fortigate-alert.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/newly-observed-fortigate-alert.asciidoc
@@ -29,7 +29,7 @@ This rule detects FortiGate alerts that are observed for the first time in the p
 * Domain: Network
 * Data Source: Fortinet
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -90,7 +90,10 @@ FROM logs-fortinet_fortigate.*, filebeat-* metadata _id
 | WHERE event.module == "fortinet_fortigate" and event.action in ("signature", "ssl-anomaly") and
   message is not null and event.category != "authentication" and
   message != "Connection Failed" and not message like "Web.Client: *" and
-  not message like "Network.Service: *" and not message like "General.Interest*" and not message like "Update: *"
+  not message like "Network.Service: *" and not message like "General.Interest*" and not message like "Update: *" and
+  not message like "tcp_reassembler*" and not message like "a-ipdf*" and not message like "Video*" and not message like "nbss_decode*" and
+  not message like "name_server*" and not message like "misc*" and not message like "Collaboration*" and not message like "Business*" and
+  not message like "Cloud.IT*" and not message like "Mobile*"
 
 | STATS Esql.alerts_count = count(*),
         Esql.first_time_seen = MIN(@timestamp),
diff --git a/docs/detections/prebuilt-rules/rule-details/newly-observed-high-severity-detection-alert.asciidoc b/docs/detections/prebuilt-rules/rule-details/newly-observed-high-severity-detection-alert.asciidoc
index 9c9dd4e76e..8b47712bdb 100644
--- a/docs/detections/prebuilt-rules/rule-details/newly-observed-high-severity-detection-alert.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/newly-observed-high-severity-detection-alert.asciidoc
@@ -27,7 +27,7 @@ This rule detects Elastic SIEM high severity detection alerts that are observed
 * Rule Type: Higher-Order Rule
 * Resources: Investigation Guide
 
-*Version*: 3
+*Version*: 4
 
 *Rule authors*: 
 
@@ -90,7 +90,8 @@ FROM .alerts-security.*
   not kibana.alert.rule.type in ("threat_match", "machine_learning", "new_terms") and
   not kibana.alert.rule.name like "Deprecated - *" and kibana.alert.rule.name != "My First Rule" and
   // covered by 7306ce7d-5c90-4f42-aa6c-12b0dc2fe3b8
-  event.dataset != "endpoint.alerts"
+  event.dataset != "endpoint.alerts" and
+  not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
 | STATS Esql.alerts_count = count(*),
         Esql.first_time_seen = MIN(@timestamp),
         Esql.last_time_seen = MAX(@timestamp),
@@ -105,7 +106,8 @@ FROM .alerts-security.*
         Esql.agent_id_values = VALUES(agent.id),
         Esql.host_id_values = VALUES(host.id),
         Esql.event_module_values = VALUES(event.module),
-        Esql.source_ip_values = VALUES(source.ip),
+        Esql.source_ip_values = VALUES(source.ip), 
+        Esql.rule_name_values = VALUES(kibana.alert.rule.name),
         Esql.agents_distinct_count = COUNT_DISTINCT(agent.id) by kibana.alert.rule.name
 // fist time seen in the last 5 days - defined in the rule schedule Additional look-back time
 | eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now())
diff --git a/docs/detections/prebuilt-rules/rule-details/newly-observed-high-severity-suricata-alert.asciidoc b/docs/detections/prebuilt-rules/rule-details/newly-observed-high-severity-suricata-alert.asciidoc
index facf0e291b..3248f1907d 100644
--- a/docs/detections/prebuilt-rules/rule-details/newly-observed-high-severity-suricata-alert.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/newly-observed-high-severity-suricata-alert.asciidoc
@@ -29,7 +29,7 @@ This rule detects Suricata high severity alerts that are observed for the first
 * Domain: Network
 * Data Source: Suricata
 
-*Version*: 2
+*Version*: 3
 
 *Rule authors*: 
 
@@ -89,7 +89,9 @@ whether it represents a true compromise or rare benign activity.
 FROM logs-suricata.*
 
   // high severity alerts
-| where event.module == "suricata" and event.kind == "signal" and event.severity == 1
+| where event.module == "suricata" and event.kind == "signal" and event.severity == 1 and
+        rule.name is not null and
+        not rule.name like "SURICATA STREAM*"
 
 | STATS Esql.alerts_count = count(*),
         Esql.first_time_seen = MIN(@timestamp),
diff --git a/docs/detections/prebuilt-rules/rule-details/okta-admin-console-login-failure.asciidoc b/docs/detections/prebuilt-rules/rule-details/okta-admin-console-login-failure.asciidoc
new file mode 100644
index 0000000000..54d7724020
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/okta-admin-console-login-failure.asciidoc
@@ -0,0 +1,122 @@
+[[okta-admin-console-login-failure]]
+=== Okta Admin Console Login Failure
+
+Identifies failed login attempts to the Okta Admin Console. Adversaries may attempt to gain unauthorized access to administrator portals during reconnaissance or privilege escalation phases. Repeated failures may indicate brute force attacks, credential spraying, or attempts to use compromised credentials. Monitoring Admin Console access failures provides visibility into potential account takeover attempts targeting administrative accounts.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-okta.system-*
+
+*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://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft
+* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security
+* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta
+
+*Tags*: 
+
+* Domain: Identity
+* Use Case: Identity and Access Audit
+* Data Source: Okta
+* Data Source: Okta System Logs
+* Tactic: Initial Access
+* Tactic: Credential Access
+* Resources: Investigation Guide
+* Rule Type: BBR
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Okta Admin Console Login Failure*
+
+
+This rule detects failed authentication attempts specifically targeting the Okta Admin Console. The Admin Console provides privileged access to manage Okta configurations, users, and policies, making it a high-value target for adversaries.
+
+Threat actors like ShinyHunters have been observed probing for valid admin credentials as part of their attack chain. Failed Admin Console access attempts often precede successful compromise through vishing (voice phishing) or credential harvesting.
+
+
+*Possible investigation steps:*
+
+- Identify the user involved by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.
+- Review the `okta.outcome.reason` field to understand why the authentication failed (e.g., invalid credentials, MFA failure, policy violation).
+- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.
+- Check if the source IP is associated with known malicious activity, VPN/proxy services, or unusual geolocations.
+- Examine the `okta.request.ip_chain` field to determine if the actor used a proxy or VPN.
+- Correlate with other failed login attempts from the same IP or user to identify patterns.
+- Review if the targeted user has administrative privileges that would make them a high-value target.
+- Check for any recent vishing or phishing reports targeting users in your organization.
+
+
+*False positive analysis:*
+
+- Administrators may legitimately mistype passwords or have MFA issues.
+- Automated systems or scripts may fail authentication due to expired credentials.
+- Users may accidentally attempt to access the Admin Console without proper permissions.
+
+
+*Response and remediation:*
+
+- If repeated failures are observed from the same IP, consider blocking the IP address at the network perimeter.
+- Alert the targeted administrator about the failed access attempts.
+- If the user reports not attempting to access the Admin Console, treat this as a potential account compromise attempt.
+- Review and strengthen MFA requirements for Admin Console access.
+- Consider implementing conditional access policies to restrict Admin Console access to trusted networks.
+- If vishing is suspected, remind users of social engineering awareness and verification procedures.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset: "okta.system"
+    and event.category: "authentication"
+    and okta.target.alternate_id: "Okta Admin Console"
+    and okta.outcome.result: "FAILURE"
+
+----------------------------------
+
+*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/
+* 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/
diff --git a/docs/detections/prebuilt-rules/rule-details/okta-successful-login-after-credential-attack.asciidoc b/docs/detections/prebuilt-rules/rule-details/okta-successful-login-after-credential-attack.asciidoc
new file mode 100644
index 0000000000..d95bd29fc9
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/okta-successful-login-after-credential-attack.asciidoc
@@ -0,0 +1,250 @@
+[[okta-successful-login-after-credential-attack]]
+=== Okta Successful Login After Credential Attack
+
+Correlates Okta credential attack alerts with subsequent successful authentication for the same user account, identifying potential compromise following brute force, password spray, or credential stuffing attempts.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: high
+
+*Risk score*: 73
+
+*Runs every*: 30m
+
+*Searches indices from*: now-6h ({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.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta
+* https://www.okta.com/identity-101/brute-force/
+* https://developer.okta.com/docs/reference/api/system-log/
+* https://developer.okta.com/docs/reference/api/event-types/
+* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy
+* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security
+* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta
+
+*Tags*: 
+
+* Domain: Identity
+* Use Case: Identity and Access Audit
+* Use Case: Threat Detection
+* Data Source: Okta
+* Data Source: Okta System Logs
+* Tactic: Credential Access
+* Tactic: Initial Access
+* Resources: Investigation Guide
+* Rule Type: Higher-Order Rule
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Okta Successful Login After Credential Attack*
+
+
+This rule correlates credential attack alerts with subsequent successful authentication for the same user account. The correlation is user-centric, capturing IP rotation scenarios where attackers may login from a different IP after obtaining credentials.
+
+
+*Possible investigation steps*
+
+- Identify the user account and review the timeline between the attack and successful login.
+- Compare the attack source IPs versus the login source IP to identify potential IP rotation.
+- Review the original credential attack alert to understand the scope and nature of the attack.
+- Check the authentication method used and whether MFA was required and satisfied.
+- Review the session activity following the successful login for signs of account takeover.
+- Verify with the user if the login was legitimate.
+
+
+*False positive analysis*
+
+- Users experiencing legitimate login issues may trigger attack alerts before successfully authenticating.
+- Automated password reset flows where a user fails multiple times then succeeds after resetting may trigger this rule.
+- The rule correlates on user identity only, so it fires when a user is targeted and later logs in, even if from different IPs.
+
+
+*Response and remediation*
+
+- If compromise is suspected, reset the user's password and revoke all active sessions.
+- Reset MFA if the attacker may have enrolled their own device.
+- Block the source IP at the network perimeter.
+- Review the user's recent activity for signs of lateral movement or data access.
+- Check for persistence mechanisms such as new OAuth apps, API tokens, or enrolled devices.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the following:
+1. The Okta Fleet integration, Filebeat module, or similarly structured data for Okta System Logs.
+2. The correlated credential attack detection rules must be enabled (at least one):
+   - Potential Okta Credential Stuffing (Single Source) (94e734c0-2cda-11ef-84e1-f661ea17fbce)
+   - Potential Okta Password Spray (Single Source) (42bf698b-4738-445b-8231-c834ddefd8a0)
+   - Potential Okta Brute Force (Device Token Rotation) (23f18264-2d6d-11ef-9413-f661ea17fbce)
+   - Potential Okta Brute Force (Multi-Source) (5889760c-9858-4b4b-879c-e299df493295)
+   - Potential Okta Password Spray (Multi-Source) (2d3c27d5-d133-4152-8102-8d051619ec4a)
+3. Alerts from these rules must be written to the `.alerts-security.*` indices.
+
+The rule queries both alert indices and Okta log indices to correlate attack alerts with successful logins.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM .alerts-security.*, logs-okta.system-* METADATA _id, _version, _index
+// Filter for credential attack alerts OR successful Okta authentications
+| WHERE
+    (
+        // Credential attack alerts from the five correlated rules
+        kibana.alert.rule.rule_id IN (
+            "94e734c0-2cda-11ef-84e1-f661ea17fbce",  // Credential Stuffing
+            "42bf698b-4738-445b-8231-c834ddefd8a0",  // Password Spraying
+            "23f18264-2d6d-11ef-9413-f661ea17fbce",  // DT Brute Force
+            "5889760c-9858-4b4b-879c-e299df493295",  // Distributed Brute Force
+            "2d3c27d5-d133-4152-8102-8d051619ec4a"   // Distributed Spray
+        )
+    )
+    OR (
+        // Successful Okta authentication events
+        event.dataset == "okta.system"
+        AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start")
+        AND okta.outcome.result == "SUCCESS"
+        AND okta.actor.alternate_id IS NOT NULL
+    )
+// correlation - alerts may store user/IP in different fields than raw logs
+| EVAL
+    Esql.user = COALESCE(okta.actor.alternate_id, user.name, user.email),
+    Esql.source_ip = COALESCE(okta.client.ip, client.ip, source.ip)
+// Must have user identity to correlate
+| WHERE Esql.user IS NOT NULL
+// Classify events and capture timestamps/IPs by event type
+| EVAL
+    Esql.is_attack_alert = CASE(
+        kibana.alert.rule.rule_id IN (
+            "94e734c0-2cda-11ef-84e1-f661ea17fbce",
+            "42bf698b-4738-445b-8231-c834ddefd8a0",
+            "23f18264-2d6d-11ef-9413-f661ea17fbce",
+            "5889760c-9858-4b4b-879c-e299df493295",
+            "2d3c27d5-d133-4152-8102-8d051619ec4a"
+        ), 1, 0
+    ),
+    Esql.is_success_login = CASE(
+        event.dataset == "okta.system"
+        AND okta.outcome.result == "SUCCESS", 1, 0
+    ),
+    Esql.attack_ip = CASE(
+        kibana.alert.rule.rule_id IN (
+            "94e734c0-2cda-11ef-84e1-f661ea17fbce",
+            "42bf698b-4738-445b-8231-c834ddefd8a0",
+            "23f18264-2d6d-11ef-9413-f661ea17fbce",
+            "5889760c-9858-4b4b-879c-e299df493295",
+            "2d3c27d5-d133-4152-8102-8d051619ec4a"
+        ), Esql.source_ip, null
+    ),
+    Esql.login_ip = CASE(
+        event.dataset == "okta.system"
+        AND okta.outcome.result == "SUCCESS", Esql.source_ip, null
+    ),
+    Esql.attack_ts = CASE(
+        kibana.alert.rule.rule_id IN (
+            "94e734c0-2cda-11ef-84e1-f661ea17fbce",
+            "42bf698b-4738-445b-8231-c834ddefd8a0",
+            "23f18264-2d6d-11ef-9413-f661ea17fbce",
+            "5889760c-9858-4b4b-879c-e299df493295",
+            "2d3c27d5-d133-4152-8102-8d051619ec4a"
+        ), @timestamp, null
+    ),
+    Esql.login_ts = CASE(
+        event.dataset == "okta.system"
+        AND okta.outcome.result == "SUCCESS", @timestamp, null
+    )
+// Aggregate by user (catches IP rotation: spray from IP A, login from IP B)
+| STATS
+    Esql.attack_count = SUM(Esql.is_attack_alert),
+    Esql.login_count = SUM(Esql.is_success_login),
+    Esql.earliest_attack = MIN(Esql.attack_ts),
+    Esql.latest_attack = MAX(Esql.attack_ts),
+    Esql.earliest_login = MIN(Esql.login_ts),
+    Esql.latest_login = MAX(Esql.login_ts),
+    Esql.attack_source_ips = VALUES(Esql.attack_ip),
+    Esql.login_source_ips = VALUES(Esql.login_ip),
+    Esql.all_source_ips = VALUES(Esql.source_ip),
+    Esql.alert_rule_ids = VALUES(kibana.alert.rule.rule_id),
+    Esql.alert_rule_names = VALUES(kibana.alert.rule.name),
+    Esql.event_action_values = VALUES(event.action),
+    Esql.geo_country_values = VALUES(client.geo.country_name),
+    Esql.geo_city_values = VALUES(client.geo.city_name),
+    Esql.source_asn_values = VALUES(source.as.number),
+    Esql.source_asn_org_values = VALUES(source.as.organization.name),
+    Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent),
+    Esql.device_values = VALUES(okta.client.device),
+    Esql.is_proxy_values = VALUES(okta.security_context.is_proxy)
+  BY Esql.user
+// Calculate time gap between latest attack and earliest subsequent login
+| EVAL Esql.attack_to_login_minutes = DATE_DIFF("minute", Esql.latest_attack, Esql.earliest_login)
+// Correlation: attack BEFORE login + success within reasonable window (3 hours)
+| WHERE
+    Esql.attack_count > 0
+    AND Esql.login_count > 0
+    AND Esql.latest_attack < Esql.earliest_login
+    AND Esql.attack_to_login_minutes <= 180
+| SORT Esql.login_count DESC
+| KEEP Esql.*
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Brute Force
+** ID: T1110
+** Reference URL: https://attack.mitre.org/techniques/T1110/
+* Sub-technique:
+** Name: Password Guessing
+** ID: T1110.001
+** Reference URL: https://attack.mitre.org/techniques/T1110/001/
+* Sub-technique:
+** Name: Password Spraying
+** ID: T1110.003
+** Reference URL: https://attack.mitre.org/techniques/T1110/003/
+* Sub-technique:
+** Name: Credential Stuffing
+** ID: T1110.004
+** Reference URL: https://attack.mitre.org/techniques/T1110/004/
+* Tactic:
+** Name: Initial Access
+** ID: TA0001
+** Reference URL: https://attack.mitre.org/tactics/TA0001/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* 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/okta-user-assigned-administrator-role.asciidoc b/docs/detections/prebuilt-rules/rule-details/okta-user-assigned-administrator-role.asciidoc
new file mode 100644
index 0000000000..34d88b52a3
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/okta-user-assigned-administrator-role.asciidoc
@@ -0,0 +1,120 @@
+[[okta-user-assigned-administrator-role]]
+=== Okta User Assigned Administrator Role
+
+Identifies when an administrator role is assigned to an Okta user or group. Adversaries may assign administrator privileges to compromised accounts to establish persistence, escalate privileges, and maintain long-term access to the environment. This detection monitors for both user-level and group-level administrator privilege grants, which can be used to bypass security controls and perform unauthorized administrative actions.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-okta*
+
+*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://help.okta.com/en/prod/Content/Topics/Security/administrators-admin-comparison.htm
+* https://developer.okta.com/docs/reference/api/system-log/
+* https://developer.okta.com/docs/reference/api/event-types/
+* https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft
+* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy
+* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security
+* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta
+* https://www.elastic.co/security-labs/okta-and-lapsus-what-you-need-to-know
+
+*Tags*: 
+
+* Domain: Identity
+* Data Source: Okta
+* Data Source: Okta System Logs
+* Use Case: Identity and Access Audit
+* Tactic: Persistence
+* Resources: Investigation Guide
+
+*Version*: 413
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Okta User Assigned Administrator Role*
+
+
+Okta administrator roles provide elevated permissions to manage users, applications, policies, and security settings within the Okta environment. Adversaries who compromise Okta accounts may assign administrator privileges to establish persistence and maintain control over the identity infrastructure. This rule detects when administrator roles are granted to users or groups, which can indicate privilege escalation or persistence techniques.
+
+
+*Possible investigation steps:*
+
+- Identify the actor who performed the privilege grant by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.
+- Determine the target user or group that received administrator privileges by reviewing the `okta.target` fields.
+- Review the specific administrator role granted by examining the `okta.debug_context.debug_data.flattened.privilegeGranted` field.
+- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.
+- Check if the source IP is associated with known malicious activity, VPN/proxy services, or unusual geolocations.
+- Examine the `okta.request.ip_chain` field to determine if the actor used a proxy or VPN.
+- Review the actor's recent authentication history and session activity for suspicious patterns.
+- Verify whether the privilege grant was part of a legitimate change request or administrative workflow.
+- Check for any other suspicious activities performed by the actor or target account around the same time.
+- Review audit logs for any administrative actions performed after the privilege grant.
+
+
+*False positive analysis:*
+
+- Legitimate administrators may assign roles during normal IT operations such as onboarding, role changes, or incident response.
+- Automated provisioning systems or service accounts may assign administrator roles as part of authorized workflows.
+- During organizational changes or access certification processes, multiple role assignments may occur.
+- Create exceptions for known administrators, service accounts, or specific groups that regularly perform legitimate role assignments.
+
+
+*Response and remediation:*
+
+- If the privilege grant is unauthorized, immediately revoke the administrator role from the affected user or group.
+- Reset credentials and revoke active sessions for both the actor and target accounts if compromise is suspected.
+- Enforce multi-factor authentication (MFA) re-enrollment for affected accounts.
+- Review all administrative actions performed by the target account after the privilege grant.
+- Check for other indicators of compromise such as unauthorized MFA device registrations, policy modifications, or suspicious authentication patterns.
+- Alert security leadership and identity management teams about the unauthorized privilege escalation.
+- Review and strengthen privileged access management controls, including requiring approval workflows for administrator role assignments.
+- Consider implementing anomaly detection for administrator role assignments from unusual sources or at unusual times.
+- If broader compromise is suspected, conduct a comprehensive security investigation including forensic analysis of Okta audit logs.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.dataset:okta.system
+    and event.action: (user.account.privilege.grant or group.privilege.grant)
+    and okta.debug_context.debug_data.flattened.privilegeGranted: *administrator*
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Account Manipulation
+** ID: T1098
+** Reference URL: https://attack.mitre.org/techniques/T1098/
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc
index 4d2a73160a..732462dc8c 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc
@@ -36,7 +36,7 @@ Identifies potential ransomware note being uploaded to an AWS S3 bucket. This ru
 * Tactic: Impact
 * Resources: Investigation Guide
 
-*Version*: 9
+*Version*: 10
 
 *Rule authors*: 
 
@@ -149,6 +149,7 @@ file where
   /* common ransom note file name keywords */
   aws.cloudtrail.resources.arn regex~ "arn:aws:s3:::[^/]+/.*?(how|decrypt|restor|help|instruct|read|get|recov|save|encrypt|info|ransom).*"
   and not aws.cloudtrail.resources.arn regex~ ".*(AWSLogs|CloudTrail|access-logs).*"
+  and not aws.cloudtrail.user_identity.type == "AWSService"
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc
index d043e0bdfc..f7ae95b6bf 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc
@@ -1,7 +1,7 @@
 [[potential-dynamic-iex-reconstruction-via-environment-variables]]
 === Potential Dynamic IEX Reconstruction via Environment Variables
 
-Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command at runtime using indexed slices of environment variables. This technique leverages character access and join operations to build execution logic dynamically, bypassing static keyword detection and evading defenses such as AMSI.
+Detects PowerShell scripts that reconstructs IEX (Invoke-Expression) by indexing environment variable strings (for example, $env:VAR[1,2,3]) or related `.name[...]` slices and joining characters at runtime. Attackers use environment-variable slicing to hide dynamic execution and evade keyword-based detections and AMSI.
 
 *Rule type*: esql
 
@@ -28,7 +28,7 @@ Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) comma
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 9
+*Version*: 10
 
 *Rule authors*: 
 
@@ -40,48 +40,90 @@ Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) comma
 ==== Investigation guide
 
 
- ## Triage and analysis
+
+*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.
+> 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 Dynamic IEX Reconstruction via Environment Variables*
 
 
-PowerShell's Invoke-Expression (IEX) command is a powerful tool for executing strings as code, often exploited by attackers to run obfuscated scripts. Adversaries may dynamically reconstruct IEX using environment variables to evade static detection. The detection rule identifies scripts that manipulate environment variables to form IEX commands, focusing on patterns of character slicing and joining, which are indicative of obfuscation techniques. By analyzing script length and specific patterns, the rule effectively flags potential misuse, aiding in defense against such evasion tactics.
+This alert indicates PowerShell Script Block Logging captured a script that builds "IEX" (Invoke-Expression) at runtime by indexing characters from environment variable strings or related name properties and combining them. This technique is commonly used to obscure dynamic execution and can indicate an attempt to execute attacker-controlled content.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
 
 
 *Possible investigation steps*
 
 
-- Review the powershell.file.script_block_text field to understand the content and intent of the script, focusing on how environment variables are manipulated to reconstruct the IEX command.
-- Examine the file.path and host.name fields to determine the origin and location of the script execution, which can provide context on whether the activity is expected or suspicious.
-- Analyze the user.id and agent.id fields to identify the user and agent responsible for executing the script, checking for any anomalies or unauthorized access.
-- Investigate the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other related PowerShell activities on the host.
-- Assess the count field to understand the extent of obfuscation patterns detected, which can indicate the complexity and potential maliciousness of the script.
+- Confirm scope and execution context:
+  - Review `host.name` and `host.id` to identify the impacted endpoint and determine whether it is a typical user workstation, server, or a special-purpose system in your environment.
+  - Review `user.name`, `user.domain`, and `user.id` to understand who executed the script and whether the account is expected to run PowerShell on this host (interactive user, service account, or administrative context).
+  - Use `agent.id` (if available) to identify the reporting agent and to support correlation with other telemetry collected from the same endpoint.
+  - Use the alert timestamp as the anchor to correlate activity immediately before and after the script block ran.
+
+- Analyze the obfuscation and intended execution:
+  - Examine `powershell.file.script_block_text` to locate environment-variable slicing patterns (for example, `$env:<var>[<idx>]`, `$env:<var>[<idx1>,<idx2>,<idx3>]`, or `.name[<idx1>,<idx2>,<idx3>]`) and identify the variable names and indices being used.
+  - Use `Esql.script_block_tmp` to quickly find the match locations, then review the surrounding context in `powershell.file.script_block_text` to determine how the reconstructed string is used (assignment, concatenation/join, or immediate invocation).
+  - Determine whether the reconstructed output is used as a dynamic execution primitive (for example, passed to `Invoke-Expression` / `IEX`, used with the call operator, or invoked via a method). Focus on what content is ultimately evaluated or executed.
+
+- Reconstruct full script content:
+  - If the script appears incomplete or staged across multiple events, use `powershell.file.script_block_id` with `powershell.sequence` and `powershell.total` to collect all fragments and rebuild the full script in order.
+  - After reconstruction, identify where string construction occurs versus where execution occurs to understand the end-to-end flow.
+
+- Assess obfuscation level and intent using available enrichments:
+  - Review `Esql.script_block_pattern_count` to understand how frequently the reconstruction pattern appears within the script block; repeated occurrences can indicate systematic obfuscation rather than an isolated string operation.
+  - Review `powershell.file.script_block_length` for size context and compare it with typical script sizes seen for the same host or user.
+  - Review `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_unique_symbols` to gauge whether the script contains encoded or highly obfuscated content (for example, large high-entropy blocks that may indicate packed or encoded data).
+
+- Identify script origin and potential spread:
+  - If `file.path` is populated, review `file.name` and `file.directory` to determine where the script was sourced from and whether the location aligns with approved administrative tooling or software distribution paths.
+  - If `file.path` is not populated, treat the activity as potentially inline or dynamically generated and prioritize identifying the initiating process or source using adjacent telemetry.
+  - Scope for other alerts or script blocks on the same `host.id` or associated with the same `user.id` that show similar reconstruction patterns, especially within the same time window.
+
+- Correlate with adjacent telemetry (as available in your environment):
+  - Using `host.id` / `host.name`, `user.id`, and the alert time, correlate with process execution data to identify the PowerShell host process and the initiating parent process or source (for example, interactive session, script runner, scheduled task, service, or another application).
+  - Correlate with network, file, registry, and authentication telemetry on the same host around the alert time to identify follow-on activity that supports malicious intent (download or retrieval of content, creation or modification of files, persistence-related changes, or suspicious logons).
 
 
 *False positive analysis*
 
 
-- Scripts with legitimate use of environment variables for configuration management may trigger the rule. Users can create exceptions for specific scripts or processes known to use environment variables in a non-threatening manner.
-- Automated scripts that dynamically construct commands for legitimate administrative tasks might be flagged. Review the script's purpose and source, and whitelist trusted scripts or processes.
-- Development environments where scripts are frequently tested and modified may produce false positives. Implement monitoring exclusions for development machines or specific user accounts involved in script testing.
-- Scripts using environment variables for localization or language settings can be mistakenly identified. Identify and exclude scripts that are part of standard localization processes.
-- PowerShell scripts from trusted vendors or software packages that use environment variables for legitimate functionality should be reviewed and excluded from detection if verified as safe.
+- Legitimate automation or administration scripts may construct command strings dynamically, including deriving short tokens from environment variables for compatibility or to reduce hard-coded strings.
+- Security testing and purple-team or red-team activity may intentionally use environment-variable slicing to emulate evasive tradecraft.
+- Developer tooling, obfuscation research, or PowerShell training content may include this technique. Benign usage is typically tied to known owners, consistent hosts, predictable execution windows, and the absence of suspicious downstream activity.
 
 
 *Response and remediation*
 
 
-- Isolate the affected system from the network to prevent further execution of potentially malicious scripts and limit lateral movement.
-- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity.
-- Review the PowerShell script block text and associated file paths to understand the scope and intent of the script, focusing on any obfuscated commands or environment variable manipulations.
-- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.
-- Update endpoint protection and intrusion detection systems to recognize and block similar obfuscation patterns in PowerShell scripts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
-- Implement additional monitoring for unusual PowerShell activity and environment variable manipulations to enhance detection of similar threats in the future.
+- If the activity is suspected or confirmed malicious:
+  - Contain the affected host to prevent additional execution and reduce lateral movement risk.
+  - Preserve evidence by collecting the complete script content using `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`, and retain the original `powershell.file.script_block_text` for analysis.
+  - Extract and track indicators from the script content (for example, URLs, domains, IP addresses, file names, or unique strings) and scope for additional occurrences across the environment using `host.id`, `host.name`, `user.id`, and `file.path` when present.
+  - Identify and remediate the initial execution source (parent process or launching mechanism) and remove or quarantine any associated script files referenced by `file.path`.
+  - If account compromise is suspected, reset affected credentials and review for additional suspicious PowerShell activity associated with the same `user.id`.
+
+- If the activity is determined to be benign:
+  - Document the business justification, owning team, expected hosts, and expected script location (`file.path` when present).
+  - Monitor for deviations in execution context (new hosts, new users, or materially different script content) and consider targeted tuning based on stable attributes such as `file.path` and known `user.id` values.
 
 
 ==== Setup
@@ -91,21 +133,8 @@ PowerShell's Invoke-Expression (IEX) command is a powerful tool for executing st
 *Setup*
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
-
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
-
-Steps to implement the logging policy via registry:
-
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
@@ -144,6 +173,7 @@ from logs-windows.powershell_operational* metadata _id, _version, _index
     _version,
     _index,
     host.name,
+    host.id,
     agent.id,
     user.id
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc
index da1d67e3eb..ac7b52b6ca 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc
@@ -39,7 +39,7 @@ This rule detects the use of SSH options that may indicate tunneling or port for
 * Data Source: SentinelOne
 * Resources: Investigation Guide
 
-*Version*: 3
+*Version*: 4
 
 *Rule authors*: 
 
@@ -138,7 +138,7 @@ For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/
 [source, js]
 ----------------------------------
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
-process.name in ("ssh", "sshd") and process.args == "-o" and
+process.name in ("ssh", "sshd") and process.args like "-o*" and
 process.command_line like~ (
   "*ProxyCommand*", "*LocalForward*", "*RemoteForward*", "*DynamicForward*", "*Tunnel*", "*GatewayPorts*",
   "*ExitOnForwardFailure*", "*ProxyCommand*", "*ProxyJump*"
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-linux-tunneling-and-or-port-forwarding.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-linux-tunneling-and-or-port-forwarding.asciidoc
index 68882a0ff0..aaf56d80ad 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-linux-tunneling-and-or-port-forwarding.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-linux-tunneling-and-or-port-forwarding.asciidoc
@@ -42,7 +42,7 @@ This rule monitors for a set of Linux utilities that can be used for tunneling a
 * Data Source: Auditd Manager
 * Resources: Investigation Guide
 
-*Version*: 113
+*Version*: 114
 
 *Rule authors*: 
 
@@ -178,8 +178,19 @@ process where host.os.type == "linux" and event.type == "start" and event.action
     // gost & pivotnacci - spawned without process.parent.name
     (process.name == "gost" and process.args : ("-L*", "-C*", "-R*")) or (process.name == "pivotnacci")) or (
     // ssh
-    (process.name == "ssh" and (process.args in ("-R", "-L", "-D", "-w") and process.args_count >= 4 and 
-     not (process.args == "chmod" or process.command_line like "*rungencmd*"))) or
+    (process.name == "ssh" and (
+      (
+        /* exact tunnel argument matching */
+        process.args in ("-R", "-L", "-D", "-w") or
+        /* single-dash token, first letter is NOT o/O, contains one of R/L/D/w/W somewhere later */
+        process.args regex "-[A-NP-Za-np-z][A-Za-z]*[RLDwW][A-Za-z]*"
+      ) and
+      process.args_count >= 4 and 
+      not (
+        process.args == "chmod" or process.command_line like "*rungencmd*"
+      )
+    )) or
+    (process.name == "ssh" and process.args == "-J") or
     // sshuttle
     (process.name == "sshuttle" and process.args in ("-r", "--remote", "-l", "--listen") and process.args_count >= 4) or
     // socat
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 05ed6de439..ef3fe0c61b 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
@@ -1,7 +1,7 @@
 [[potential-malicious-powershell-based-on-alert-correlation]]
 === Potential Malicious PowerShell Based on Alert Correlation
 
-Identifies PowerShell script blocks associated with multiple distinct detections, indicating likely malicious behavior.
+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
 
@@ -28,7 +28,7 @@ Identifies PowerShell script blocks associated with multiple distinct detections
 * Rule Type: Higher-Order Rule
 * Resources: Investigation Guide
 
-*Version*: 4
+*Version*: 5
 
 *Rule authors*: 
 
@@ -44,66 +44,85 @@ Identifies PowerShell script blocks associated with multiple distinct detections
 *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 detection rule aggregates alert data to identify PowerShell Scripts that have triggered various PowerShell-related detection logic, thereby producing higher-fidelity results.
+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.
+
 
-> **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.
+*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*
 
 
-- Analyzing the detections triggered by the script should offer insight into the suspicious behaviors it exhibits. This information can be found in the `distinct_alerts` field.
-- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
-- Investigate the script 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.
-- Examine the script's execution context, such as the user account, privileges, the role of the system on which it was executed, and any relevant timestamps.
-- Investigate other alerts associated with the user/host during the past 48 hours.
-- Evaluate whether the user needs to use PowerShell to complete tasks.
-- Investigate the origin of the PowerShell script, including its source, download method, and any associated URLs or IP addresses.
-- Examine the host for derived artifacts that indicate suspicious activities:
-  - Analyze the script 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.
-- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.
+- 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.
+
+- 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.
+
+- 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.
+
+- 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).
+
+- 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.
+
+- 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.
 
 
 *False positive analysis*
 
 
-- This rule is unlikely to trigger on legitimate activity. Benign true positives (B-TPs) can be added as exceptions if necessary.
+- 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.
+
+
+*Response and remediation*
 
 
-*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.
 
-- 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 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.
-- Reimage the host operating system or restore the compromised files to clean versions.
-- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
-- 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).
+- 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.
 
 
 ==== 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
new file mode 100644
index 0000000000..301c0a98a0
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/potential-notepad-markdown-rce-exploitation.asciidoc
@@ -0,0 +1,117 @@
+[[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 for Endpoint
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*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.
+
+
+*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.
+
+
+*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.
+
+
+==== 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"
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-okta-brute-force-device-token-rotation.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-okta-brute-force-device-token-rotation.asciidoc
new file mode 100644
index 0000000000..61e8d11668
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/potential-okta-brute-force-device-token-rotation.asciidoc
@@ -0,0 +1,158 @@
+[[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.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*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://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta
+* https://www.okta.com/identity-101/brute-force/
+* https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US
+* https://developer.okta.com/docs/reference/api/event-types/
+* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy
+* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection
+* https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/
+* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security
+* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta
+
+*Tags*: 
+
+* Domain: Identity
+* Use Case: Identity and Access Audit
+* Data Source: Okta
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Okta Brute Force (Device Token Rotation)*
+
+
+This rule identifies excessive unique device token hashes generated for a single user account, indicating automated brute force tooling that fails to persist browser cookies between authentication attempts.
+
+
+*Possible investigation steps*
+
+- Identify the targeted user account and determine if it has elevated privileges or sensitive access.
+- Review the source IP and check if it belongs to known proxy, VPN, or cloud infrastructure.
+- Examine user agent strings for signs of automation, scripting tools, or inconsistent browser fingerprints.
+- Check if Okta flagged the source as a known threat or proxy.
+- Determine if any authentication attempts succeeded following the failed attempts.
+- Review the user's recent activity for signs of account compromise.
+
+
+*False positive analysis*
+
+- Users experiencing login issues may generate multiple device tokens through repeated legitimate attempts.
+- Automated testing or monitoring tools that do not persist cookies may trigger this rule.
+- Browser extensions or privacy tools that clear cookies between requests may cause device token rotation.
+
+
+*Response and remediation*
+
+- If attack is confirmed, reset the user's password immediately.
+- Block the source IP at the network perimeter.
+- Review and potentially reset MFA for the targeted account.
+- Monitor for any successful authentication that may indicate compromise.
+- Contact the user to verify if they experienced legitimate login issues.
+
+
+==== Setup
+
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM logs-okta.system-* METADATA _id, _version, _index
+| WHERE
+    event.dataset == "okta.system"
+    AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start")
+    AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT")
+    AND okta.actor.alternate_id IS NOT NULL
+    // Primary authn endpoint; sessions API provides additional coverage
+    AND (
+        okta.debug_context.debug_data.request_uri == "/api/v1/authn"
+        OR okta.debug_context.debug_data.request_uri LIKE "/api/v1/sessions*"
+    )
+// Track whether each event has a device token
+| EVAL has_dt_hash = CASE(okta.debug_context.debug_data.dt_hash IS NOT NULL, 1, 0)
+// Aggregate by IP + user to detect single-user brute force
+| STATS
+    Esql.unique_dt_hashes = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash),
+    Esql.total_attempts = COUNT(*),
+    Esql.attempts_with_dt = SUM(has_dt_hash),
+    Esql.unique_user_agents = COUNT_DISTINCT(okta.client.user_agent.raw_user_agent),
+    Esql.first_seen = MIN(@timestamp),
+    Esql.last_seen = MAX(@timestamp),
+    Esql.dt_hash_values = VALUES(okta.debug_context.debug_data.dt_hash),
+    Esql.event_action_values = VALUES(event.action),
+    Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent),
+    Esql.device_values = VALUES(okta.client.device),
+    Esql.is_proxy_values = VALUES(okta.security_context.is_proxy),
+    Esql.geo_country_values = VALUES(client.geo.country_name),
+    Esql.geo_city_values = VALUES(client.geo.city_name),
+    Esql.source_asn_values = VALUES(source.as.number),
+    Esql.source_asn_org_values = VALUES(source.as.organization.name),
+    Esql.threat_suspected_values = VALUES(okta.debug_context.debug_data.threat_suspected),
+    Esql.risk_level_values = VALUES(okta.debug_context.debug_data.risk_level),
+    Esql.risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons)
+  BY okta.client.ip, okta.actor.alternate_id
+// Calculate automation detection metrics (float-safe division)
+| EVAL Esql.dt_coverage = Esql.attempts_with_dt * 1.0 / Esql.total_attempts,
+       Esql.dt_per_attempt = Esql.unique_dt_hashes * 1.0 / Esql.total_attempts
+// Detection branches:
+//   A) Many unique DT hashes relative to attempts = tooling generating new tokens per attempt
+//   B) High attempts + very low DT coverage = cookie-less automation (no DT sent at all)
+//   C) Multiple user agents for same user = evasion or automation
+| WHERE
+    (Esql.unique_dt_hashes >= 7 AND Esql.total_attempts >= 10 AND Esql.dt_per_attempt >= 0.5)
+    OR (Esql.total_attempts >= 12 AND Esql.dt_coverage < 0.15)
+    OR (Esql.total_attempts >= 10 AND Esql.unique_user_agents >= 5)
+| SORT Esql.total_attempts DESC
+| KEEP Esql.*, okta.client.ip, okta.actor.alternate_id
+
+----------------------------------
+
+*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/
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-okta-brute-force-multi-source.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-okta-brute-force-multi-source.asciidoc
new file mode 100644
index 0000000000..1793fa4491
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/potential-okta-brute-force-multi-source.asciidoc
@@ -0,0 +1,168 @@
+[[potential-okta-brute-force-multi-source]]
+=== Potential Okta Brute Force (Multi-Source)
+
+Detects potential brute force attacks against a single Okta user account from multiple source IPs, indicating attackers rotating through proxy infrastructure to evade IP-based detection.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*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://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta
+* https://www.okta.com/identity-101/brute-force/
+* https://developer.okta.com/docs/reference/api/event-types/
+* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy
+* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security
+* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta
+
+*Tags*: 
+
+* Domain: Identity
+* Use Case: Identity and Access Audit
+* Use Case: Threat Detection
+* Data Source: Okta
+* Data Source: Okta System Logs
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Okta Brute Force (Multi-Source)*
+
+
+This rule identifies a single user account receiving failed authentication attempts from multiple unique source IPs. This pattern indicates attackers rotating through proxy infrastructure to evade IP-based detection while targeting a specific account.
+
+
+*Possible investigation steps*
+
+- Identify the targeted user account and determine if it has elevated privileges or sensitive access.
+- Review the geographic distribution of source IPs for anomalies such as multiple countries or unusual locations.
+- Examine the ASN ownership of source IPs for signs of proxy, VPN, or cloud infrastructure.
+- Check if Okta flagged any of the sources as known threats or proxies.
+- Determine if any authentication attempts succeeded following the failed attempts.
+- Review the user's recent activity for signs of account compromise.
+
+
+*False positive analysis*
+
+- Users traveling internationally with mobile devices may generate failed attempts from multiple locations.
+- Service accounts accessed from distributed legitimate infrastructure may trigger this rule.
+- Corporate VPN exit nodes spread across regions could appear as multiple IPs for a single user.
+
+
+*Response and remediation*
+
+- If attack is confirmed, reset the user's password immediately.
+- Review and potentially reset MFA for the targeted account.
+- Block attacking IP addresses at the network perimeter.
+- Consider implementing geo-restrictions for the targeted account if dispersed access is not expected.
+- Monitor for any successful authentication that may indicate compromise.
+
+
+==== Setup
+
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM logs-okta.system-* METADATA _id, _version, _index
+| WHERE event.dataset == "okta.system"
+    AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start")
+    AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT")
+    AND okta.actor.alternate_id IS NOT NULL
+
+// Create source mapping for analyst context
+| EVAL Esql.source_info = CONCAT(
+    "{\"ip\":\"", COALESCE(okta.client.ip::STRING, "unknown"),
+    "\",\"country\":\"", COALESCE(client.geo.country_name, "unknown"),
+    "\",\"asn\":\"", COALESCE(source.as.organization.name, "unknown"),
+    "\",\"user_agent\":\"", COALESCE(okta.client.user_agent.raw_user_agent, "unknown"), "\"}"
+  )
+
+| STATS
+    Esql.unique_source_ips = COUNT_DISTINCT(okta.client.ip),
+    Esql.total_attempts = COUNT(*),
+    Esql.unique_user_agents = COUNT_DISTINCT(okta.client.user_agent.raw_user_agent),
+    Esql.unique_dt_hashes = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash),
+    Esql.unique_asns = COUNT_DISTINCT(source.as.number),
+    Esql.unique_countries = COUNT_DISTINCT(client.geo.country_name),
+    Esql.first_seen = MIN(@timestamp),
+    Esql.last_seen = MAX(@timestamp),
+    Esql.source_ip_values = VALUES(okta.client.ip),
+    Esql.source_mapping = VALUES(Esql.source_info),
+    Esql.event_action_values = VALUES(event.action),
+    Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent),
+    Esql.device_values = VALUES(okta.client.device),
+    Esql.is_proxy_values = VALUES(okta.security_context.is_proxy),
+    Esql.geo_country_values = VALUES(client.geo.country_name),
+    Esql.geo_city_values = VALUES(client.geo.city_name),
+    Esql.source_asn_values = VALUES(source.as.number),
+    Esql.source_asn_org_values = VALUES(source.as.organization.name),
+    Esql.threat_suspected_values = VALUES(okta.debug_context.debug_data.threat_suspected),
+    Esql.risk_level_values = VALUES(okta.debug_context.debug_data.risk_level),
+    Esql.risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons)
+  BY okta.actor.alternate_id
+
+| EVAL
+    Esql.attempts_per_ip = Esql.total_attempts * 1.0 / Esql.unique_source_ips,
+    Esql.duration_seconds = DATE_DIFF("seconds", Esql.first_seen, Esql.last_seen)
+
+| WHERE
+    Esql.unique_source_ips >= 5
+    AND Esql.total_attempts >= 10
+    AND (
+        Esql.unique_countries >= 2 OR
+        Esql.unique_asns >= 3 OR
+        Esql.unique_source_ips >= 8 OR
+        Esql.unique_user_agents >= 3
+    )
+
+| SORT Esql.unique_source_ips DESC
+| KEEP Esql.*, okta.actor.alternate_id
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Brute Force
+** ID: T1110
+** Reference URL: https://attack.mitre.org/techniques/T1110/
+* Sub-technique:
+** Name: Password Guessing
+** ID: T1110.001
+** Reference URL: https://attack.mitre.org/techniques/T1110/001/
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-okta-credential-stuffing-single-source.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-okta-credential-stuffing-single-source.asciidoc
new file mode 100644
index 0000000000..6f285c2fd6
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/potential-okta-credential-stuffing-single-source.asciidoc
@@ -0,0 +1,185 @@
+[[potential-okta-credential-stuffing-single-source]]
+=== Potential Okta Credential Stuffing (Single Source)
+
+Detects potential credential stuffing attacks where a single source IP attempts authentication against many Okta user accounts with minimal attempts per user, indicating the use of breached credential lists.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*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://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta
+* https://www.okta.com/identity-101/brute-force/
+* https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US
+* https://developer.okta.com/docs/reference/api/event-types/
+* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy
+* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection
+* https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/
+* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security
+* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta
+
+*Tags*: 
+
+* Domain: Identity
+* Use Case: Identity and Access Audit
+* Data Source: Okta
+* Data Source: Okta System Logs
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 210
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Okta Credential Stuffing (Single Source)*
+
+
+This rule identifies a single source IP attempting authentication against many user accounts with minimal attempts per user. This pattern indicates credential stuffing where attackers rapidly test breached username and password pairs.
+
+
+*Possible investigation steps*
+
+- Identify the source IP and determine if it belongs to known proxy, VPN, or cloud infrastructure.
+- Review the list of targeted user accounts and check if any authentications succeeded.
+- Examine the user agent strings for signs of automation or scripting tools.
+- Check if Okta flagged the source as a known threat or proxy.
+- Determine if any targeted accounts have elevated privileges or access to sensitive systems.
+- Review the geographic location and ASN of the source IP for anomalies.
+
+
+*False positive analysis*
+
+- Corporate proxies or VPN exit nodes may aggregate traffic from multiple legitimate users.
+- Shared systems such as kiosks or conference room computers may have multiple users authenticating.
+- Legitimate SSO integrations may generate multiple authentication attempts from a single source.
+
+
+*Response and remediation*
+
+- If attack is confirmed, block the source IP at the network perimeter.
+- Reset passwords for any accounts that may have been compromised.
+- Enable or strengthen MFA for targeted accounts.
+- Review Okta sign-on policies to add additional friction for suspicious authentication patterns.
+- If this is a known legitimate source, consider adding an exception for the IP or ASN.
+
+
+==== Setup
+
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM logs-okta.system-* METADATA _id, _version, _index
+| WHERE
+    event.dataset == "okta.system"
+    AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start")
+    AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT")
+    AND okta.actor.alternate_id IS NOT NULL
+// Build user-source context as JSON for enrichment
+| EVAL Esql.user_source_info = CONCAT(
+    "{\"user\":\"", okta.actor.alternate_id,
+    "\",\"ip\":\"", COALESCE(okta.client.ip::STRING, "unknown"),
+    "\",\"user_agent\":\"", COALESCE(okta.client.user_agent.raw_user_agent, "unknown"), "\"}"
+  )
+// FIRST STATS: Aggregate by (IP, user) to get per-user attempt counts
+// This prevents skew from outlier users with many attempts
+| STATS
+    Esql.user_attempts = COUNT(*),
+    Esql.user_dt_hashes = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash),
+    Esql.user_source_info = VALUES(Esql.user_source_info),
+    Esql.user_agents_per_user = VALUES(okta.client.user_agent.raw_user_agent),
+    Esql.devices_per_user = VALUES(okta.client.device),
+    Esql.is_proxy = VALUES(okta.security_context.is_proxy),
+    Esql.geo_country = VALUES(client.geo.country_name),
+    Esql.geo_city = VALUES(client.geo.city_name),
+    Esql.asn_number = VALUES(source.as.number),
+    Esql.asn_org = VALUES(source.as.organization.name),
+    Esql.threat_suspected = VALUES(okta.debug_context.debug_data.threat_suspected),
+    Esql.risk_level = VALUES(okta.debug_context.debug_data.risk_level),
+    Esql.risk_reasons = VALUES(okta.debug_context.debug_data.risk_reasons),
+    Esql.event_actions = VALUES(event.action),
+    Esql.first_seen_user = MIN(@timestamp),
+    Esql.last_seen_user = MAX(@timestamp)
+  BY okta.client.ip, okta.actor.alternate_id
+// SECOND STATS: Aggregate by IP to detect credential stuffing pattern
+// Now we can accurately measure the distribution of attempts across users
+| STATS
+    Esql.unique_users = COUNT(*),
+    Esql.total_attempts = SUM(Esql.user_attempts),
+    Esql.max_attempts_per_user = MAX(Esql.user_attempts),
+    Esql.min_attempts_per_user = MIN(Esql.user_attempts),
+    Esql.avg_attempts_per_user = AVG(Esql.user_attempts),
+    Esql.users_with_single_attempt = SUM(CASE(Esql.user_attempts == 1, 1, 0)),
+    Esql.users_with_few_attempts = SUM(CASE(Esql.user_attempts <= 2, 1, 0)),
+    Esql.first_seen = MIN(Esql.first_seen_user),
+    Esql.last_seen = MAX(Esql.last_seen_user),
+    Esql.target_users = VALUES(okta.actor.alternate_id),
+    Esql.user_source_mapping = VALUES(Esql.user_source_info),
+    Esql.event_action_values = VALUES(Esql.event_actions),
+    Esql.user_agent_values = VALUES(Esql.user_agents_per_user),
+    Esql.device_values = VALUES(Esql.devices_per_user),
+    Esql.is_proxy_values = VALUES(Esql.is_proxy),
+    Esql.geo_country_values = VALUES(Esql.geo_country),
+    Esql.geo_city_values = VALUES(Esql.geo_city),
+    Esql.source_asn_values = VALUES(Esql.asn_number),
+    Esql.source_asn_org_values = VALUES(Esql.asn_org),
+    Esql.threat_suspected_values = VALUES(Esql.threat_suspected),
+    Esql.risk_level_values = VALUES(Esql.risk_level),
+    Esql.risk_reasons_values = VALUES(Esql.risk_reasons)
+  BY okta.client.ip
+// Calculate stuffing signature: most users should have very few attempts
+| EVAL Esql.pct_users_few_attempts = Esql.users_with_few_attempts * 100.0 / Esql.unique_users
+// Credential stuffing: many users, most with 1-2 attempts each, low max per user
+// Stacked stats gives us accurate per-user distribution instead of skewed averages
+| WHERE
+    Esql.total_attempts >= 25
+    AND Esql.unique_users >= 15
+    AND Esql.max_attempts_per_user <= 2
+    AND Esql.pct_users_few_attempts >= 80.0
+| SORT Esql.unique_users DESC
+| KEEP Esql.*, okta.client.ip
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Brute Force
+** ID: T1110
+** Reference URL: https://attack.mitre.org/techniques/T1110/
+* Sub-technique:
+** Name: Credential Stuffing
+** ID: T1110.004
+** Reference URL: https://attack.mitre.org/techniques/T1110/004/
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-okta-password-spray-multi-source.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-okta-password-spray-multi-source.asciidoc
new file mode 100644
index 0000000000..e8b5a4d654
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/potential-okta-password-spray-multi-source.asciidoc
@@ -0,0 +1,173 @@
+[[potential-okta-password-spray-multi-source]]
+=== Potential Okta Password Spray (Multi-Source)
+
+Detects potential password spray attacks where multiple source IPs target multiple Okta user accounts within a time window, indicating coordinated attacks using IP rotation to evade single-source detection.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 15m
+
+*Searches indices from*: now-1h ({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.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta
+* https://www.okta.com/identity-101/brute-force/
+* https://developer.okta.com/docs/reference/api/event-types/
+* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy
+* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security
+* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta
+
+*Tags*: 
+
+* Domain: Identity
+* Use Case: Identity and Access Audit
+* Use Case: Threat Detection
+* Data Source: Okta
+* Data Source: Okta System Logs
+* Tactic: Credential Access
+* Resources: Investigation Guide
+
+*Version*: 2
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Okta Password Spray (Multi-Source)*
+
+
+This rule identifies coordinated password spray attacks where multiple source IPs target multiple user accounts within a time window. This pattern indicates attackers using IP rotation to evade single-source detection while spraying passwords across the organization.
+
+
+*Possible investigation steps*
+
+- Review the list of targeted user accounts and check if any authentications succeeded.
+- Examine the source IPs and their ASN ownership for signs of proxy, VPN, or cloud infrastructure.
+- Check if Okta flagged any of the sources as known threats or proxies.
+- Analyze the attempts-per-user ratio to confirm spray behavior versus brute force.
+- Review the geographic distribution of source IPs for coordination patterns.
+- Cross-reference with successful authentication events to identify potential compromises.
+
+
+*False positive analysis*
+
+- Organization-wide password rotation or expiration events may cause widespread authentication failures.
+- Misconfigured SSO or SAML integrations can cause batch failures from legitimate infrastructure.
+- Penetration testing should be coordinated and whitelisted in advance.
+
+
+*Response and remediation*
+
+- If attack is confirmed, notify affected users and enforce password resets for potentially compromised accounts.
+- Block attacking IP ranges at the network perimeter.
+- Enable or strengthen MFA for targeted accounts.
+- Review Okta sign-on policies to add additional friction for suspicious authentication patterns.
+- Consider temporary lockdowns for highly targeted accounts.
+
+
+==== Setup
+
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM logs-okta.system-* METADATA _id, _version, _index
+| WHERE
+    event.dataset == "okta.system"
+    AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start")
+    AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT")
+    AND okta.actor.alternate_id IS NOT NULL
+
+// Bucket into 15-minute windows and create user-source mapping for context
+| EVAL
+    Esql.time_bucket = DATE_TRUNC(15 minutes, @timestamp),
+    Esql.user_source_info = CONCAT(
+      "{\"user\":\"", okta.actor.alternate_id,
+      "\",\"ip\":\"", COALESCE(okta.client.ip::STRING, "unknown"),
+      "\",\"user_agent\":\"", COALESCE(okta.client.user_agent.raw_user_agent, "unknown"), "\"}"
+    )
+
+// Aggregate across entire tenant per time bucket to detect distributed spray
+| STATS
+    Esql.unique_users = COUNT_DISTINCT(okta.actor.alternate_id),
+    Esql.unique_source_ips = COUNT_DISTINCT(okta.client.ip),
+    Esql.total_attempts = COUNT(*),
+    Esql.unique_user_agents = COUNT_DISTINCT(okta.client.user_agent.raw_user_agent),
+    Esql.unique_asns = COUNT_DISTINCT(source.as.number),
+    Esql.unique_countries = COUNT_DISTINCT(client.geo.country_name),
+    Esql.first_seen = MIN(@timestamp),
+    Esql.last_seen = MAX(@timestamp),
+    Esql.target_users = VALUES(okta.actor.alternate_id),
+    Esql.source_ip_values = VALUES(okta.client.ip),
+    Esql.user_source_mapping = VALUES(Esql.user_source_info),
+    Esql.event_action_values = VALUES(event.action),
+    Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent),
+    Esql.device_values = VALUES(okta.client.device),
+    Esql.is_proxy_values = VALUES(okta.security_context.is_proxy),
+    Esql.geo_country_values = VALUES(client.geo.country_name),
+    Esql.geo_city_values = VALUES(client.geo.city_name),
+    Esql.source_asn_values = VALUES(source.as.number),
+    Esql.source_asn_org_values = VALUES(source.as.organization.name),
+    Esql.threat_suspected_values = VALUES(okta.debug_context.debug_data.threat_suspected),
+    Esql.risk_level_values = VALUES(okta.debug_context.debug_data.risk_level),
+    Esql.risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons)
+  BY Esql.time_bucket
+
+// Calculate spray metrics
+| EVAL
+    Esql.attempts_per_user = Esql.total_attempts * 1.0 / Esql.unique_users,
+    Esql.attempts_per_ip = Esql.total_attempts * 1.0 / Esql.unique_source_ips,
+    Esql.users_per_ip = Esql.unique_users * 1.0 / Esql.unique_source_ips
+
+// Distributed spray: many IPs, many users, moderate spread across both
+// Key differentiator: attacks come from multiple IPs (evading per-IP rules)
+| WHERE
+    Esql.unique_source_ips >= 5
+    AND Esql.unique_users >= 8
+    AND Esql.total_attempts >= 25
+    AND Esql.attempts_per_user <= 5.0
+    AND Esql.users_per_ip >= 1.0
+
+| SORT Esql.total_attempts DESC
+| KEEP Esql.*
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Brute Force
+** ID: T1110
+** Reference URL: https://attack.mitre.org/techniques/T1110/
+* Sub-technique:
+** Name: Password Spraying
+** ID: T1110.003
+** Reference URL: https://attack.mitre.org/techniques/T1110/003/
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-okta-password-spray-single-source.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-okta-password-spray-single-source.asciidoc
new file mode 100644
index 0000000000..9dac81c718
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/potential-okta-password-spray-single-source.asciidoc
@@ -0,0 +1,188 @@
+[[potential-okta-password-spray-single-source]]
+=== Potential Okta Password Spray (Single Source)
+
+Detects potential password spray attacks where a single source IP attempts authentication against multiple Okta user accounts with repeated attempts per user, indicating common password guessing paced to avoid lockouts.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 15m
+
+*Searches indices from*: now-1h ({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.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta
+* https://www.okta.com/identity-101/brute-force/
+* https://developer.okta.com/docs/reference/api/system-log/
+* https://developer.okta.com/docs/reference/api/event-types/
+* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy
+* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security
+* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta
+
+*Tags*: 
+
+* Domain: Identity
+* Use Case: Identity and Access Audit
+* Tactic: Credential Access
+* Data Source: Okta
+* Data Source: Okta System Logs
+* Resources: Investigation Guide
+
+*Version*: 417
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+
+*Investigating Potential Okta Password Spray (Single Source)*
+
+
+This rule identifies a single source IP attempting authentication against multiple user accounts with repeated attempts per user over time. This pattern indicates password spraying where attackers try common passwords while pacing attempts to avoid lockouts.
+
+
+*Possible investigation steps*
+
+- Identify the source IP and determine if it belongs to known proxy, VPN, or cloud infrastructure.
+- Review the list of targeted user accounts and check if any authentications succeeded.
+- Analyze the timing of attempts to determine if they are paced to avoid lockout thresholds.
+- Check if Okta flagged the source as a known threat or proxy.
+- Examine user agent strings for signs of automation or consistent tooling across attempts.
+- Review the geographic location and ASN of the source IP for anomalies.
+
+
+*False positive analysis*
+
+- Corporate proxies or VPN exit nodes may aggregate traffic from multiple legitimate users with login issues.
+- Automated processes or misconfigured applications retrying authentication may trigger this rule.
+- Password rotation events may cause legitimate widespread authentication failures.
+
+
+*Response and remediation*
+
+- If attack is confirmed, block the source IP at the network perimeter.
+- Notify targeted users and enforce password resets for accounts that may have been compromised.
+- Enable or strengthen MFA for targeted accounts.
+- Consider implementing CAPTCHA or additional friction for suspicious authentication patterns.
+- Review Okta sign-on policies to ensure lockout thresholds are appropriately configured.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+FROM logs-okta.system-* METADATA _id, _version, _index
+| WHERE
+    event.dataset == "okta.system"
+    AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start")
+    AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT")
+    AND okta.actor.alternate_id IS NOT NULL
+// Build user-source context as JSON for enrichment
+| EVAL Esql.user_source_info = CONCAT(
+    "{\"user\":\"", okta.actor.alternate_id,
+    "\",\"ip\":\"", COALESCE(okta.client.ip::STRING, "unknown"),
+    "\",\"user_agent\":\"", COALESCE(okta.client.user_agent.raw_user_agent, "unknown"), "\"}"
+  )
+// FIRST STATS: Aggregate by (IP, user) to get per-user attempt counts
+// This prevents skew from outlier users with many attempts
+| STATS
+    Esql.user_attempts = COUNT(*),
+    Esql.user_source_info = VALUES(Esql.user_source_info),
+    Esql.user_agents_per_user = VALUES(okta.client.user_agent.raw_user_agent),
+    Esql.devices_per_user = VALUES(okta.client.device),
+    Esql.is_proxy = VALUES(okta.security_context.is_proxy),
+    Esql.geo_country = VALUES(client.geo.country_name),
+    Esql.geo_city = VALUES(client.geo.city_name),
+    Esql.asn_number = VALUES(source.as.number),
+    Esql.asn_org = VALUES(source.as.organization.name),
+    Esql.threat_suspected = VALUES(okta.debug_context.debug_data.threat_suspected),
+    Esql.risk_level = VALUES(okta.debug_context.debug_data.risk_level),
+    Esql.event_actions = VALUES(event.action),
+    Esql.first_seen_user = MIN(@timestamp),
+    Esql.last_seen_user = MAX(@timestamp)
+  BY okta.client.ip, okta.actor.alternate_id
+// SECOND STATS: Aggregate by IP to detect password spray pattern
+// Now we can accurately measure the distribution of attempts across users
+| STATS
+    Esql.unique_users = COUNT(*),
+    Esql.total_attempts = SUM(Esql.user_attempts),
+    Esql.max_attempts_per_user = MAX(Esql.user_attempts),
+    Esql.min_attempts_per_user = MIN(Esql.user_attempts),
+    Esql.avg_attempts_per_user = AVG(Esql.user_attempts),
+    // Spray band: 2-6 attempts per user (deliberate slow spray below lockout)
+    Esql.users_in_spray_band = SUM(CASE(Esql.user_attempts >= 2 AND Esql.user_attempts <= 6, 1, 0)),
+    // Also track users with only 1 attempt (stuffing-like) for differentiation
+    Esql.users_with_single_attempt = SUM(CASE(Esql.user_attempts == 1, 1, 0)),
+    Esql.first_seen = MIN(Esql.first_seen_user),
+    Esql.last_seen = MAX(Esql.last_seen_user),
+    Esql.target_users = VALUES(okta.actor.alternate_id),
+    Esql.user_source_mapping = VALUES(Esql.user_source_info),
+    Esql.event_action_values = VALUES(Esql.event_actions),
+    Esql.user_agent_values = VALUES(Esql.user_agents_per_user),
+    Esql.device_values = VALUES(Esql.devices_per_user),
+    Esql.is_proxy_values = VALUES(Esql.is_proxy),
+    Esql.geo_country_values = VALUES(Esql.geo_country),
+    Esql.geo_city_values = VALUES(Esql.geo_city),
+    Esql.source_asn_values = VALUES(Esql.asn_number),
+    Esql.source_asn_org_values = VALUES(Esql.asn_org),
+    Esql.threat_suspected_values = VALUES(Esql.threat_suspected),
+    Esql.risk_level_values = VALUES(Esql.risk_level)
+  BY okta.client.ip
+// Calculate spray signature metrics
+| EVAL
+    // Percentage of users in the spray band (2-6 attempts)
+    Esql.pct_users_in_spray_band = Esql.users_in_spray_band * 100.0 / Esql.unique_users,
+    // Attack duration in minutes (spray is paced, not bursty)
+    Esql.attack_duration_minutes = DATE_DIFF("minute", Esql.first_seen, Esql.last_seen)
+// Password spraying detection logic:
+// - Many users targeted (>= 5)
+// - Hard cap below Okta lockout threshold (max <= 8 attempts per user)
+// - Majority of users in spray band (2-6 attempts) (at least 60%)
+// - Attack is paced over time (>= 5 minutes) (not a 10-second burst like stuffing)
+// - Minimum total attempts to reduce noise
+// Note: For IP rotation attacks, see "Distributed Password Spray Attack in Okta" rule
+| WHERE
+    Esql.unique_users >= 5
+    AND Esql.total_attempts >= 15
+    AND Esql.max_attempts_per_user <= 8
+    AND Esql.max_attempts_per_user >= 2
+    AND Esql.pct_users_in_spray_band >= 60.0
+    AND Esql.attack_duration_minutes >= 5
+| SORT Esql.total_attempts DESC
+| KEEP Esql.*, okta.client.ip
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: Brute Force
+** ID: T1110
+** Reference URL: https://attack.mitre.org/techniques/T1110/
+* Sub-technique:
+** Name: Password Spraying
+** ID: T1110.003
+** Reference URL: https://attack.mitre.org/techniques/T1110/003/
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-hacktool-script-by-author.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-hacktool-script-by-author.asciidoc
index d6a107f869..48d5dae5c2 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
@@ -1,7 +1,7 @@
 [[potential-powershell-hacktool-script-by-author]]
 === Potential PowerShell HackTool Script by Author
 
-Detects known PowerShell offensive tooling author's name in PowerShell scripts. Attackers commonly use out-of-the-box offensive tools without modifying the code, which may still contain the author artifacts. This rule identifies common author handles found in popular PowerShell scripts used for red team exercises.
+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
 
@@ -10,9 +10,9 @@ Detects known PowerShell offensive tooling author's name in PowerShell scripts.
 * winlogbeat-*
 * logs-windows.powershell*
 
-*Severity*: medium
+*Severity*: high
 
-*Risk score*: 47
+*Risk score*: 73
 
 *Runs every*: 5m
 
@@ -33,7 +33,7 @@ Detects known PowerShell offensive tooling author's name in PowerShell scripts.
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 108
+*Version*: 109
 
 *Rule authors*: 
 
@@ -50,68 +50,93 @@ Detects known PowerShell offensive tooling author's name in PowerShell scripts.
 
 
 > **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.
+> 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*
 
 
-PowerShell is a powerful scripting language and automation framework used in Windows environments for task automation and configuration management. Adversaries exploit PowerShell's capabilities to execute malicious scripts, often leveraging well-known offensive tools without altering the original code. The detection rule identifies scripts containing specific author names linked to these tools, flagging potential misuse by recognizing unmodified author artifacts in the script block text.
+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*
+
+
+- `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 PowerShell script block text associated with the alert to identify the specific author name that triggered the detection. This can provide insight into the potential tool or script being used.
-- Examine the process details, including the parent process and command line arguments, to understand the context in which the PowerShell script was executed. This can help determine if the execution was part of a legitimate task or a suspicious activity.
-- Check the host's recent activity logs for any other unusual or related events, such as network connections, file modifications, or other process executions, to identify potential lateral movement or data exfiltration attempts.
-- Investigate the user account under which the PowerShell script was executed to determine if it has been compromised or if the activity aligns with the user's typical behavior.
-- Correlate the alert with other security tools and logs, such as antivirus or endpoint detection and response (EDR) solutions, to gather additional context and confirm whether the activity is malicious.
+- 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.
+
+- 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.
+
+- 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.
+
+- 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.
+
+- 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).
 
 
 *False positive analysis*
 
 
-- Scripts used in legitimate red team exercises may trigger the rule due to the presence of known author names. To manage this, create exceptions for scripts verified as part of authorized security assessments.
-- PowerShell scripts from open-source security tools used for internal testing or training might be flagged. Ensure these tools are documented and approved, then exclude them from the rule.
-- Automated scripts for system administration that include code snippets from well-known authors could be mistakenly identified. Review and whitelist these scripts if they are part of routine operations.
-- Security research and development activities using sample scripts from recognized authors may cause alerts. Maintain a list of such activities and exclude them from detection to avoid unnecessary alerts.
-- Internal development teams using PowerShell scripts for legitimate purposes might inadvertently use code from popular authors. Conduct regular reviews and exclude these scripts if they are deemed non-threatening.
+- 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.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected system from the network to prevent further execution of potentially malicious scripts and lateral movement.
-- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing malicious activity.
-- Conduct a thorough review of the PowerShell script block text to confirm the presence of known offensive tool author names and assess the potential impact.
-- Remove any unauthorized or malicious scripts from the affected system and ensure that all legitimate scripts are verified and restored from a clean backup.
-- Update endpoint protection and antivirus signatures to detect and block the specific PowerShell scripts and associated indicators of compromise (IOCs) identified in the alert.
-- 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 PowerShell activity across the network to detect similar threats in the future, leveraging the MITRE ATT&CK framework for guidance on relevant techniques and tactics.
+- 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.
 
-==== Setup
+- 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.
 
+- 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.
 
 
-*Setup*
+==== Setup
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
 
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
+*Setup*
 
-Steps to implement the logging policy via registry:
 
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-hacktool-script-by-function-names.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-hacktool-script-by-function-names.asciidoc
index fb148c5765..300a0a58b9 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-hacktool-script-by-function-names.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-hacktool-script-by-function-names.asciidoc
@@ -1,7 +1,7 @@
 [[potential-powershell-hacktool-script-by-function-names]]
 === Potential PowerShell HackTool Script by Function Names
 
-Detects known PowerShell offensive tooling functions names in PowerShell scripts. Attackers commonly use out-of-the-box offensive tools without modifying the code. This rule aim is to take advantage of that.
+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.
 
 *Rule type*: query
 
@@ -35,7 +35,7 @@ Detects known PowerShell offensive tooling functions names in PowerShell scripts
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 219
+*Version*: 220
 
 *Rule authors*: 
 
@@ -51,102 +51,97 @@ Detects known PowerShell offensive tooling functions names in PowerShell scripts
 *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 Function Names*
 
 
-PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code.
+This rule identifies PowerShell Script Block Logging events where the captured script content includes function names commonly reused by offensive PowerShell toolkits. Script blocks can contain function definitions (tool staging) and/or function invocation (active use). Prioritize determining what capability is present, how the script was introduced, and whether follow-on activity occurred.
 
-Adversaries often exploit PowerShell's capabilities to execute malicious scripts and perform various attacks. This rule identifies known offensive tooling function names in PowerShell scripts, as attackers commonly use out-of-the-box tools without modifying the code. By monitoring these specific function names, the rule aims to detect and alert potential malicious PowerShell activity.
 
-> **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.
+*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.
 
 
-- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
-- Investigate the script 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.
-- Examine the script's execution context, such as the user account, privileges, the role of the system on which it was executed, and any relevant timestamps.
-- Investigate other alerts associated with the user/host during the past 48 hours.
-- Evaluate whether the user needs to use PowerShell to complete tasks.
-- Investigate the origin of the PowerShell script, including its source, download method, and any associated URLs or IP addresses.
-- Examine the host for derived artifacts that indicate suspicious activities:
-  - Analyze the script 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.
-- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.
+*Possible investigation steps*
 
 
+- Review `powershell.file.script_block_text` to determine intent and urgency:
+  - Identify the function name(s) present and map them to likely capability. Examples include:
+    - Credential access: `Invoke-Mimikatz`, `Invoke-Kerberoast`, `Invoke-DCSync`, `Get-GPPPassword`, `Get-LSASecret`.
+    - Injection or token manipulation: `Invoke-ReflectivePEInjection`, `Create-RemoteThread`, `Inject-RemoteShellcode`, `Invoke-TokenManipulation`.
+    - Remote execution or lateral movement: `Invoke-PsExec`, `Invoke-SMBExec`, `Invoke-WmiCommand`, `Invoke-PSRemoting`, `Invoke-DCOM`.
+    - Staging, persistence, or exfiltration: `Invoke-DownloadCradle`, `Add-Persistence`, `HTTP-Backdoor`, `Do-Exfiltration`.
+  - Determine whether the script block primarily defines functions (tool staging) or calls them (active use). If only definitions are present, look for follow-on script blocks from the same host and user that invoke the functions.
+  - Capture any embedded targets or indicators visible in the text (other usernames, hostnames, domains, remote paths, URLs, or IP addresses).
 
-*False positive analysis*
+- Reconstruct the complete script when it is split across multiple events:
+  - Pivot using `host.name` (or `host.id`) and `powershell.file.script_block_id` to collect related script blocks around `@timestamp`.
+  - Order fragments using `powershell.sequence` and confirm completeness using `powershell.total`.
+  - Use `powershell.file.script_block_length` as a size signal to distinguish a full toolkit/module from a small launcher or single command.
+
+- Establish script origin and execution context:
+  - If `file.path` / `file.name` (and `file.directory`) are present, treat the script as an on-disk artifact. Validate whether its location and naming align with approved scripts and expected administrative workflows for that host and user.
+  - If file fields are not present, treat the activity as potentially interactive or in-memory. Correlate other endpoint telemetry from the same `host.id` and time window to identify how PowerShell was started and what else executed immediately before and after.
 
+- Validate the account and host context:
+  - Review `user.name`, `user.domain`, and `user.id` for privilege level and whether the activity aligns with expected responsibilities and working hours.
+  - Review `host.name` and `host.id` to understand the system role and whether advanced PowerShell activity is expected on that host.
 
-- This rule may generate false positives if legitimate scripts or tools used by administrators contain any of the listed function names. These function names are commonly associated with offensive tooling, but they may also be present in benign scripts or tools.
-- To handle these false positives consider adding exceptions - preferably with a combination of full file path and users.
+- Scope for additional related activity on the same host:
+  - Search for other script blocks on the same `host.id` and `user.id` near the alert time to identify staging, follow-on commands, or cleanup actions.
+  - Pivot on `powershell.file.script_block_id` to ensure all fragments are reviewed and to detect repeated execution of the same script content.
 
+- Scope for related activity across the environment:
+  - Search for additional script blocks containing the same distinctive function name(s) or matching snippets of `powershell.file.script_block_text` to identify reuse and potential spread.
+  - If `file.path` or `file.name` is present, check for the same script artifact referenced on other hosts.
 
-*Related Rules*
+- Correlate with adjacent telemetry (as available) to confirm impact and intent:
+  - Process telemetry to identify the initiating process (parent of PowerShell) and any suspicious child processes spawned after the script executed.
+  - Authentication telemetry to identify anomalous logons or access patterns involving the same user around the execution window.
+  - Network and DNS telemetry to identify outbound connections, internal scanning, or remote management activity aligned with `@timestamp`.
+  - Persistence telemetry to identify new or modified services, scheduled tasks, autoruns, or registry changes that align with the observed script capability.
 
 
-- PowerShell Invoke-NinjaCopy script - b8386923-b02c-4b94-986a-d223d9b01f88
-- PowerShell Suspicious Discovery Related Windows API Functions - 61ac3638-40a3-44b2-855a-985636ca985e
-- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d
-- PowerShell Keylogging Script - bd2c86a0-8b61-4457-ab38-96943984e889
+*False positive analysis*
 
 
-*Response and Remediation*
+- Internal security or IT teams may run proof-of-concept or validation scripts for training, detection testing, or incident response. Confirm script ownership, change control, and expected distribution.
 
 
-- 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 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.
-- Reimage the host operating system or restore the compromised files to clean versions.
-- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
-- 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).
+*Response and remediation*
 
 
-==== Setup
+- If the activity is unauthorized or suspicious:
+  - Contain the affected host to prevent additional execution and lateral movement.
+  - Preserve evidence by saving all related script block events (reconstruct full content using `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`) and collecting any referenced on-disk script identified by `file.path`.
+  - Prioritize impact assessment based on the functions observed (credential access, injection, remote execution, persistence, or exfiltration) and look for corroborating activity in adjacent telemetry.
+  - Scope for additional impacted systems and accounts by searching for the same function names or script snippets across other hosts and users.
+  - Remove identified artifacts and persistence mechanisms, and monitor for re-execution using the same function-name patterns.
 
+- If the activity is confirmed benign:
+  - Document the justification (owner, purpose, expected hosts/users, and time window) and retain the reconstructed script content for future baselining.
+  - Where feasible, limit high-risk PowerShell tooling to controlled administrative hosts and approved accounts to reduce recurrence.
 
 
-*Setup*
+==== Setup
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
 
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
+*Setup*
 
-Steps to implement the logging policy via registry:
 
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscated-script-via-high-entropy.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscated-script-via-high-entropy.asciidoc
new file mode 100644
index 0000000000..67545807db
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscated-script-via-high-entropy.asciidoc
@@ -0,0 +1,190 @@
+[[potential-powershell-obfuscated-script-via-high-entropy]]
+=== Potential PowerShell Obfuscated Script via High Entropy
+
+Identifies PowerShell script blocks with high entropy and non-uniform character distributions. Attackers may obfuscate PowerShell scripts using encoding, encryption, or compression techniques to evade signature-based detections and hinder manual analysis by security analysts.
+
+*Rule type*: query
+
+*Rule indices*: 
+
+* logs-windows.powershell*
+
+*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: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: PowerShell Logs
+* 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 PowerShell Obfuscated Script via High Entropy*
+
+
+This alert flags a large PowerShell script block with statistical characteristics consistent with obfuscated content (for example, encoded, compressed, or encrypted data embedded in a script). Triage should focus on establishing execution context (who/where), reconstructing the complete script content, identifying whether the high-entropy data is a benign embedded resource or a staged payload, and scoping for related activity.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
+
+
+*Possible investigation steps*
+
+
+- Triage the execution context and initial severity:
+  - Review `@timestamp` to identify when the script block executed and align pivots to the same timeframe.
+  - Review `host.name` and `host.id` to identify the endpoint and validate whether PowerShell use is expected for its role.
+  - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to run PowerShell on this host and whether it is privileged, shared, or an automation/service identity.
+  - Review `powershell.file.script_block_length`, `powershell.file.script_block_entropy_bits`, and `powershell.file.script_block_surprisal_stdev` to understand whether the alert is driven by a large embedded blob (often staging) or more mixed script content (often a wrapper/loader plus embedded data).
+
+- Determine script provenance (file-backed vs. dynamic/interactive):
+  - If `file.path` is present, review `file.directory` and `file.name` to understand where the script originated.
+  - Assess whether `file.directory` is consistent with approved administrative tooling locations for this host and user, or whether it appears user-writable, temporary, or otherwise unusual.
+  - If `file.path` is absent, treat the script block as potentially interactive or dynamically generated and prioritize reconstructing the full script content and identifying the launch source via process correlation.
+
+- Reconstruct the full script content when fragmented:
+  - Pivot on `powershell.file.script_block_id` to collect all fragments associated with the script block.
+  - Order fragments using `powershell.sequence` and validate completeness using `powershell.total`.
+  - Analyze the reconstructed content as a whole to avoid missing small loader logic that precedes a large encoded/encrypted payload.
+
+- Perform structured content review of `powershell.file.script_block_text`:
+  - Identify large contiguous strings, byte arrays, or character arrays that may represent encoded or packed data; use `powershell.file.script_block_unique_symbols` to help distinguish limited-alphabet encodings from broader character sets.
+  - Look for transformation and staging patterns (for example, decode/decrypt/decompress routines) and whether transformed content is immediately executed (for example, dynamic invocation, in-memory loading, or secondary script evaluation).
+  - Extract any embedded indicators (domains, URLs, IPs, file paths/names, registry paths, scheduled task/service names, or distinctive strings) and retain them for scoping and containment.
+
+- Establish the execution chain and initiating source:
+  - Use `process.pid` with `host.id` and `@timestamp` to pivot to process telemetry for the PowerShell host instance that generated the script block.
+  - Identify the parent process and initiating mechanism (interactive shell, scheduled execution, remote management, document/script host, or other launcher). Treat unexpected launch sources or unusual timing for the host role as higher risk.
+  - Check whether the same `process.pid` generated additional suspicious script blocks around the alert time, and whether `user.id` and `host.id` align with expected administrative behavior.
+
+- Correlate for follow-on activity on the same host and account:
+  - Correlate on `host.id` and `@timestamp` to identify adjacent events that indicate impact (outbound connections, file writes, module downloads, persistence changes, or unusual authentication activity).
+  - When `file.path` is present, correlate on that path and timeframe for file creation/modification patterns that may indicate initial staging or subsequent cleanup.
+
+- Scope the activity across the environment:
+  - Search for other high-entropy script blocks on the same `host.id` and `user.id` before and after the alert to identify repeated execution or iterative staging.
+  - Search across hosts for the same `file.name` and `file.path` (when present) and compare `powershell.file.script_block_text` structure to identify reuse.
+  - Use distinctive substrings from `powershell.file.script_block_text` as pivots to find related script blocks even when paths or accounts differ.
+
+
+*False positive analysis*
+
+
+- Benign scripts can trigger this alert when they legitimately embed packed data (for example, compressed resources, serialized configuration blobs, embedded certificates/keys, or packaged modules) that increase entropy and appear non-uniform.
+- Indicators supporting a benign determination:
+  - `file.path` and `file.name` consistently map to an approved internal tool or vendor-managed automation across multiple hosts.
+  - `user.id` represents an expected administrative or automation identity with predictable host targeting and execution timing.
+  - Reconstructed `powershell.file.script_block_text` shows a stable, repeatable structure over time, and any decoded content aligns with known operational functionality rather than staging and immediate secondary execution.
+- Indicators supporting suspicion:
+  - Unusual `file.directory` for the host role or account, or absence of `file.path` combined with evidence of dynamic staging behavior.
+  - Reconstructed content includes clear execution of transformed data, in-memory loading patterns, or embedded external destinations not associated with known tooling.
+- If determined benign, document the owning tool/team, expected `user.id` usage, and expected `file.path`/`file.name` (when present). Use those stable attributes for future baselining and noise reduction while preserving detection for new paths, new users, or materially different script structures.
+
+
+*Response and remediation*
+
+
+- If suspicious or malicious activity is confirmed:
+  - Contain the affected host to prevent further execution and lateral movement.
+  - Preserve relevant evidence from the alert, including full reconstructed script content (via `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`), and associated context (`@timestamp`, `host.*`, `user.*`, `file.*`, `process.pid`, and entropy metrics).
+  - Use extracted indicators from `powershell.file.script_block_text` to hunt across hosts and accounts, and to identify additional affected systems.
+  - Investigate and remediate follow-on activity identified during correlation (downloaded payloads, dropped files, persistence mechanisms, or unauthorized network access) and remove malicious artifacts from affected endpoints.
+  - If account compromise is suspected for `user.id` / `user.name`, initiate credential reset and review recent authentication activity and access paths associated with that identity.
+
+- If benign activity is confirmed:
+  - Record the justification and expected behavior (who runs it, where it runs, and expected `file.path` when present).
+  - Monitor for deviations from the established baseline, including new `user.id`, new `host.id`, new `file.path`, or significant changes in `powershell.file.script_block_text` structure or entropy characteristics.
+
+
+==== 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
+
+This rule uses the following fields that require the Windows Integration v3.3.0 and up: `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_length`.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+event.category:process and host.os.type:windows and powershell.file.script_block_length > 1000 and
+  powershell.file.script_block_entropy_bits >= 5.3 and powershell.file.script_block_surprisal_stdev > 0.7 and
+  not file.directory: "C:\Program Files (x86)\Microsoft Intune Management Extension\Content\DetectionScripts"
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Obfuscated Files or Information
+** ID: T1027
+** Reference URL: https://attack.mitre.org/techniques/T1027/
+* Technique:
+** Name: Deobfuscate/Decode Files or Information
+** ID: T1140
+** Reference URL: https://attack.mitre.org/techniques/T1140/
+* Tactic:
+** Name: Execution
+** ID: TA0002
+** Reference URL: https://attack.mitre.org/tactics/TA0002/
+* Technique:
+** Name: Command and Scripting Interpreter
+** ID: T1059
+** Reference URL: https://attack.mitre.org/techniques/T1059/
+* Sub-technique:
+** Name: PowerShell
+** ID: T1059.001
+** Reference URL: https://attack.mitre.org/techniques/T1059/001/
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc
index 860ffc432f..548687ecee 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc
@@ -1,7 +1,7 @@
 [[potential-powershell-obfuscation-via-backtick-escaped-variable-expansion]]
 === Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion
 
-Identifies PowerShell scripts that use backtick-escaped characters inside ${} variable expansion as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).
+Detects PowerShell scripts that uses backtick-escaped characters inside `${}` variable expansion (multiple backticks between word characters) to reconstruct strings at runtime. Attackers use variable-expansion obfuscation to split keywords, hide commands, and evade static analysis and AMSI.
 
 *Rule type*: esql
 
@@ -28,7 +28,7 @@ Identifies PowerShell scripts that use backtick-escaped characters inside ${} va
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 8
+*Version*: 9
 
 *Rule authors*: 
 
@@ -40,49 +40,94 @@ Identifies PowerShell scripts that use backtick-escaped characters inside ${} va
 ==== Investigation guide
 
 
- ## Triage and analysis
+
+*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.
+> 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 Obfuscation via Backtick-Escaped Variable Expansion*
 
 
-PowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques like backtick-escaped variable expansion to evade detection. This method involves disguising malicious scripts to bypass security measures. The detection rule identifies scripts with excessive length and specific obfuscation patterns, flagging potential threats for further analysis.
+This rule identifies Windows PowerShell Script Block Logging events where backtick-escaped characters are embedded within `${}` variable expansion. This technique can be used to split tokens and reconstruct variable names or keywords at runtime, reducing the effectiveness of simple string-based detections and content scanning.
+
+Focus analysis on (1) who executed the script, (2) where it executed, (3) how much of the script is obfuscated, and (4) what the script ultimately does after deobfuscation. Higher `Esql.script_block_pattern_count`, elevated `powershell.file.script_block_entropy_bits`, and unexpected script origin (for example, unusual `file.path`) increase the likelihood of malicious intent.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
 
 
 *Possible investigation steps*
 
 
-- Review the `powershell.file.script_block_text` field to understand the content of the script and identify any suspicious or malicious commands.
-- Examine the `file.path` and `file.name` fields to determine the origin and context of the script execution, which may provide insights into whether the script is part of a legitimate process or potentially malicious activity.
-- Check the `host.name` and `agent.id` fields to identify the affected system and correlate with other security events or logs from the same host for additional context.
-- Analyze the `user.id` field to determine which user account executed the script, and assess whether this activity aligns with the user's typical behavior or role.
-- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution flow of the script and identify any related script blocks that may have been executed in sequence.
-- Consider the `count` field to evaluate the extent of obfuscation used in the script, which may indicate the level of sophistication or intent behind the script.
+- Validate execution scope and context:
+  - Review `host.name` / `host.id` to understand where the script ran and whether the endpoint role makes this activity unexpected.
+  - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to run PowerShell on this host and to identify any unusual account usage patterns in your environment.
+  - If `file.path` / `file.name` / `file.directory` are present, determine whether the script appears to originate from an expected location (for example, a managed scripts directory) versus an unusual or user-writable location.
+
+- Reconstruct the complete script before interpreting intent:
+  - Pivot on `powershell.file.script_block_id` and collect all related fragments.
+  - Use `powershell.sequence` and `powershell.total` to verify you have the full set of fragments and to order them correctly.
+  - Review the reconstructed `powershell.file.script_block_text` for staging behavior (for example, an initial deobfuscation routine followed by a second stage that performs the primary action).
+
+- Locate the obfuscated variable expansions and normalize the content:
+  - Use `Esql.script_block_tmp` to quickly identify the positions of suspicious `${}` expansions, then review the corresponding sections in `powershell.file.script_block_text`.
+  - Use `Esql.script_block_pattern_count` to estimate how pervasive the obfuscation is. A higher count is more consistent with deliberate evasion than isolated escaping.
+  - In the matched `${}` segments, assess what the obfuscated expansion is intended to represent by mentally removing backtick escapes and looking for recognizable tokens (cmdlet/function names, variable names, or string literals) that the script is trying to hide.
+
+- Assess behavior indicated by the script content:
+  - Identify whether the script uses dynamic invocation patterns, such as building an invocation target at runtime or executing reconstructed strings.
+  - Look for decoding and deobfuscation constructs (string concatenation, character-by-character reconstruction, data transformation, decompression) that may reveal embedded or second-stage content.
+  - Extract and document any clear indicators contained in the script text (remote endpoints, file paths, registry paths, service/task names, or additional scripts referenced). Use these indicators to scope impact across hosts.
+
+- Use alert-side obfuscation metrics to prioritize and focus review:
+  - Compare `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_surprisal_stdev` against what is typical in your environment for administrative scripts.
+  - Treat scripts with high entropy and many unique symbols as higher risk, especially when combined with multiple obfuscated `${}` expansions.
+
+- Scope prevalence and recurrence:
+  - Search for other Script Block Logging events on the same `host.id` and `user.id` that include similar backtick-escaped `${}` patterns.
+  - Look for repeated occurrences of the same `file.name` / `file.path` across multiple hosts, which may indicate a shared script or distributed execution.
+  - If the script contains unique strings or indicators, use them to identify additional affected endpoints.
 
 
 *False positive analysis*
 
 
-- Scripts with legitimate administrative functions may use backtick-escaped variable expansion for complex string manipulations. Review the script's context and purpose to determine if it aligns with expected administrative tasks.
-- Automated scripts generated by trusted software might include obfuscation patterns as part of their normal operation. Verify the source and integrity of the software to ensure it is from a reputable vendor.
-- Developers and IT professionals may use obfuscation techniques during testing or development phases. Establish a process to whitelist known development environments or user accounts to reduce unnecessary alerts.
-- PowerShell scripts that are part of legitimate security tools or monitoring solutions may trigger the rule. Identify and exclude these tools by their file path or script block ID to prevent false positives.
-- Regularly update the list of known false positives based on historical data and feedback from users to refine the detection rule and improve its accuracy.
+- Legitimate scripts that implement complex string building or variable-name handling and happen to use backticks within `${}` expansion (more common in developer tooling, templating, or edge-case input handling).
+- Auto-generated PowerShell produced by administrative automation that uses nonstandard escaping or runtime string construction.
+
+When evaluating potential false positives, weigh consistency (same `user.id`, `host.id`, and `file.path` over time) against indicators of compromise (unexpected user/host pairing, high obfuscation density, high entropy, or evidence of follow-on actions).
 
 
 *Response and remediation*
 
 
-- Isolate the affected host immediately to prevent further spread of the potentially malicious script across the network.
-- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of obfuscated scripts.
-- Conduct a thorough review of the script block text and associated file paths to identify and remove any malicious scripts or files from the system.
-- Reset credentials for any user accounts involved in the alert to mitigate the risk of compromised credentials being used for further attacks.
-- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or additional compromised systems.
-- Implement enhanced monitoring on the affected host and similar systems to detect any recurrence of obfuscation techniques or related suspicious activities.
-- Update endpoint protection and intrusion detection systems with indicators of compromise (IOCs) derived from the analysis to improve detection capabilities for similar threats in the future.
+- If the activity is suspicious or confirmed malicious:
+  - Contain the affected endpoint to prevent additional execution and limit potential lateral movement.
+  - Preserve evidence from the alert, including the full reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence` / `powershell.total`, and any `file.path` / `file.name` values.
+  - If an on-disk source is indicated by `file.path`, collect the referenced script and related files for review and remove or quarantine malicious artifacts according to your procedures.
+  - Investigate for follow-on effects suggested by the script content (persistence, payload delivery, configuration changes) and remediate any identified artifacts.
+  - Review the impacted `user.id` for compromise, revoke active sessions as appropriate, and reset credentials based on your incident response policy.
+  - Use extracted indicators and distinctive script fragments to hunt for additional affected hosts and users.
+
+- If the activity is verified benign:
+  - Document the legitimate script source, expected `file.path` / `file.name`, and the normal execution context (`user.id`, `host.id`) to speed up future triage.
+  - Monitor for deviations in execution context or significant changes in obfuscation metrics (for example, increased `Esql.script_block_pattern_count` or higher entropy) that could indicate abuse of an otherwise legitimate script.
 
 
 ==== Setup
@@ -92,21 +137,8 @@ PowerShell, a powerful scripting language in Windows environments, can be exploi
 *Setup*
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
-
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
-
-Steps to implement the logging policy via registry:
-
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
@@ -142,6 +174,7 @@ from logs-windows.powershell_operational* metadata _id, _version, _index
     _version,
     _index,
     host.name,
+    host.id,
     agent.id,
     user.id
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc
index 268367b1ad..c955e84b2c 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc
@@ -1,7 +1,7 @@
 [[potential-powershell-obfuscation-via-character-array-reconstruction]]
 === Potential PowerShell Obfuscation via Character Array Reconstruction
 
-Identifies PowerShell scripts that use character arrays and runtime string reconstruction as a form of obfuscation. This technique breaks strings into individual characters, often using constructs like char[] with index-based access or joining logic. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).
+Detects PowerShell scripts that reconstructs strings from char[] arrays, index lookups, or repeated ([char]NN)+ concatenation/join logic. Attackers use character-array reconstruction to hide commands, URLs, or payloads and evade static analysis and AMSI.
 
 *Rule type*: esql
 
@@ -28,7 +28,7 @@ Identifies PowerShell scripts that use character arrays and runtime string recon
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 8
+*Version*: 9
 
 *Rule authors*: 
 
@@ -40,48 +40,76 @@ Identifies PowerShell scripts that use character arrays and runtime string recon
 ==== Investigation guide
 
 
- ## Triage and analysis
+
+*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.
+> 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 Obfuscation via Character Array Reconstruction*
 
 
-PowerShell, a powerful scripting language, is often targeted by adversaries for obfuscation to bypass security measures. By reconstructing strings from character arrays, attackers evade static analysis and detection. The detection rule identifies scripts using such obfuscation by searching for patterns indicative of character array manipulation, thus flagging potential threats for further investigation.
+This rule identifies PowerShell Script Block Logging content that reconstructs strings at runtime from character codes or character arrays. This technique is commonly used to conceal intent (for example, commands, URLs, or file paths) and can indicate attempts to evade static inspection.
+
+Focus triage on what strings are being rebuilt, who ran the script, where it ran, and whether the decoded content leads to follow-on activity.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
 
 
 *Possible investigation steps*
 
 
-- Review the powershell.file.script_block_text field to understand the content and intent of the script, focusing on the obfuscated parts indicated by the presence of the "char" keyword and the 🔥 character.
-- Examine the file.path and host.name fields to determine the origin and location of the script execution, which can provide context about the environment and potential risk.
-- Check the user.id and agent.id fields to identify the user and agent responsible for executing the script, which can help assess whether the activity is expected or suspicious.
-- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other related script blocks, providing a broader view of the script's behavior.
-- Investigate the count field to assess the extent of obfuscation, as a higher count may indicate more complex or extensive obfuscation techniques being used.
+- Review `powershell.file.script_block_text` and use `Esql.script_block_tmp` to quickly spot the segments that triggered the match. Identify the reconstruction method (for example, `[char[]](...)`, repeated `([char]NN)+` concatenation, joins, or index-based lookups).
+- If the script block is split, reconstruct the full content using `powershell.file.script_block_id` together with `powershell.sequence` and `powershell.total`. Verify that all expected sequences are present and in order before drawing conclusions.
+- If `powershell.total` indicates multiple fragments but one or more `powershell.sequence` values are missing, treat the script as incomplete context. Attempt to retrieve the missing fragments and consider the possibility of log gaps or ingestion delays.
+- Deobfuscate the reconstructed strings by translating numeric character codes and arrays into their resulting text. Capture any decoded values that look like commands, script content, URLs, file paths, registry paths, or encoded blobs.
+- After decoding, re-review the full script block content for additional obfuscation layers or execution logic that is not covered by the character reconstruction pattern (for example, secondary decoding steps or dynamically-invoked script).
+- Use `Esql.script_block_pattern_count` as a quick measure of how heavily the script relies on this obfuscation pattern. Higher counts typically indicate more deliberate concealment and can help prioritize review.
+- Use the script statistics to support prioritization and comparison against expected baselines: `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_length`. Look for unusually long, high-entropy, or highly variable content relative to known-good PowerShell activity in your environment.
+- Review the execution context: `user.name`, `user.domain`, and `user.id` to understand who executed the script and whether the account matches expected administrative or automation usage for the `host.name` and `host.id` involved.
+- Review file origin indicators when present: `file.path`, `file.directory`, and `file.name`. Assess whether the script appears to originate from an expected location for your environment versus a user-writable, temporary, or unusual directory.
+- Pivot to the source event using `_id` and `_index` to review the full event payload and confirm whether additional relevant `powershell.file.*` context is available for analysis.
+- Scope for related activity by searching for additional script blocks that share the same `powershell.file.script_block_id`, similar `powershell.file.script_block_text` content, the same `file.path`, the same `user.id`, or the same `host.id` around the alert time window.
+- Correlate the alert timestamp with adjacent telemetry from the same host and user (process activity, network connections, file writes, registry modifications, and authentication events) to identify how PowerShell was launched (including the initiating/parent process) and what occurred immediately before and after the obfuscated content executed.
+- If decoded content indicates external communication or secondary payload retrieval, identify potential indicators (domains, IPs, URLs, file names) and check for additional occurrences across other hosts and users.
+- If decoded content indicates credential access, lateral movement, or persistence, expand the investigation to related accounts and hosts within the same timeframe and document the full execution chain.
 
 
 *False positive analysis*
 
 
-- Scripts used for legitimate administrative tasks may use character arrays for performance optimization or to handle special characters. Review the script's purpose and context to determine if it aligns with known administrative functions.
-- PowerShell scripts from trusted sources or vendors might use character arrays for legitimate obfuscation to protect intellectual property. Verify the script's origin and check for digital signatures or hashes to confirm authenticity.
-- Automated scripts generated by development tools or frameworks could include character array manipulation as part of their standard output. Identify and whitelist these tools if they are commonly used in your environment.
-- Security tools or monitoring solutions might use character arrays in their scripts for legitimate purposes. Cross-reference with known security software and consider excluding these from the detection rule if they are verified as safe.
-- Regularly update the exclusion list to include new trusted scripts or tools as they are introduced into the environment, ensuring that legitimate activities are not flagged as false positives.
+- Some benign scripts reconstruct strings from character codes for formatting, localization, or to safely represent special characters. These cases are often limited in scope and decode to human-readable, expected values.
+- Software deployment, management, or monitoring tooling may generate PowerShell dynamically and use string reconstruction as an implementation detail. Validate whether the script source (`file.path`) and execution context (`user.id`, `host.id`) align with known tooling behavior.
+- Internal scripts may use light obfuscation to reduce casual tampering or to embed configuration values. Treat unknown sources, unexpected accounts, or unusually high `Esql.script_block_pattern_count` / `powershell.file.script_block_entropy_bits` as higher risk until validated.
+- If determined benign, document the script source and expected execution context (account and host) and retain the decoded strings for faster triage of future alerts.
 
 
 *Response and remediation*
 
 
-- Isolate the affected host immediately to prevent further spread of potentially malicious scripts or unauthorized access.
-- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing obfuscation activities.
-- Conduct a thorough review of the script block text and associated logs to identify any malicious payloads or commands executed.
-- Remove any identified malicious scripts or files from the affected system to prevent re-execution.
-- Reset credentials for any user accounts involved in the alert to mitigate potential credential compromise.
-- Update endpoint protection and ensure that AMSI and other security features are fully enabled and configured to detect similar threats.
-- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems are affected.
+- If malicious or suspicious activity is confirmed, contain the affected host to prevent additional execution and lateral movement. Consider restricting the involved account based on investigation results.
+- Preserve evidence: retain the full `powershell.file.script_block_text` and any reconstructed/decoded strings, along with related events for the same `powershell.file.script_block_id` (all `powershell.sequence` values).
+- If the script originates from disk (`file.path` present), collect and quarantine the referenced file and review for additional related artifacts created or modified around the alert time window.
+- Identify and remediate follow-on actions indicated by the decoded content (for example, downloaded payloads, persistence mechanisms, or changes to system configuration).
+- Hunt for spread: search for the same decoded indicators, similar reconstruction patterns, and elevated `Esql.script_block_pattern_count` across other hosts and users.
+- If account misuse is suspected, perform appropriate credential hygiene and review recent authentication activity for the affected `user.id` and related accounts.
+- Review and strengthen PowerShell controls and monitoring based on findings (for example, ensure Script Block Logging is consistently enabled and that anti-malware scanning integration is functioning as expected).
 
 
 ==== Setup
@@ -91,21 +119,8 @@ PowerShell, a powerful scripting language, is often targeted by adversaries for
 *Setup*
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
-
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
-
-Steps to implement the logging policy via registry:
-
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
@@ -142,6 +157,7 @@ from logs-windows.powershell_operational* metadata _id, _version, _index
     _version,
     _index,
     host.name,
+    host.id,
     agent.id,
     user.id
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc
index f59a1f9795..9fc37c2cb1 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc
@@ -1,7 +1,7 @@
 [[potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation]]
 === Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation
 
-Identifies PowerShell scripts that use concatenated strings within dynamic command invocation (&() or .()) as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).
+Detects PowerShell scripts that builds commands from concatenated string literals inside dynamic invocation constructs like &() or .(). Attackers use concatenated dynamic invocation to obscure execution intent, bypass keyword-based detections, and evade AMSI.
 
 *Rule type*: esql
 
@@ -28,7 +28,7 @@ Identifies PowerShell scripts that use concatenated strings within dynamic comma
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 8
+*Version*: 9
 
 *Rule authors*: 
 
@@ -40,72 +40,117 @@ Identifies PowerShell scripts that use concatenated strings within dynamic comma
 ==== Investigation guide
 
 
- ## Triage and analysis
+
+*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.
+> 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 Obfuscation via Concatenated Dynamic Command Invocation*
 
 
-PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its capabilities by obfuscating commands to evade detection, often using concatenated strings in dynamic invocations. This detection rule identifies such obfuscation by analyzing script patterns, specifically looking for concatenated strings within dynamic command invocations, which are indicative of attempts to bypass security measures like AMSI. By counting these patterns, the rule effectively flags suspicious scripts, aiding in the identification of potential threats.
+This rule identifies PowerShell script block content where a command is built from concatenated string literals and executed through dynamic invocation using the call operator (&) or dot invocation (.). This technique can hide the true command name (for example, splitting cmdlet, function, alias, or script names into fragments) and is often paired with additional obfuscation to hinder quick review.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
 
 
 *Possible investigation steps*
 
 
-- Review the `powershell.file.script_block_text` field to understand the content and purpose of the script, focusing on the concatenated strings and dynamic command invocations.
-- Check the `host.name` and `user.id` fields to identify the machine and user account associated with the execution of the suspicious script, which can help determine if the activity is expected or anomalous.
-- Analyze the `file.path` field to locate the script's source or storage location, which may provide additional context or indicate if the script is part of a known application or process.
-- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution sequence and correlate it with other related PowerShell activities, which might reveal a broader pattern of behavior.
-- Assess the `agent.id` field to determine the specific endpoint agent involved, which can assist in further endpoint-specific investigations or actions.
+- Establish scope and execution context:
+  - Review `host.name` and `host.id` to understand where the script ran, and identify whether the host is an admin workstation, server, or user endpoint.
+  - Review `user.name`, `user.domain`, and `user.id` to understand who initiated the activity and whether PowerShell use is expected for that identity.
+  - Use the alert timestamp to bound the activity window for correlation and scoping.
+
+- Reconstruct the dynamically invoked command(s):
+  - Review `powershell.file.script_block_text` and use `Esql.script_block_tmp` to quickly locate the dynamic invocation expression(s) inside the script block.
+  - Identify each invocation using `&(...)` or `.(...)` where multiple quoted strings are joined with `+`.
+  - Concatenate the quoted string fragments in their observed order to derive the effective command/function/script name being invoked.
+  - Use `Esql.script_block_pattern_count` to prioritize review; multiple dynamic concatenation invocations in the same script block generally indicate stronger intent to obscure execution.
+
+- Determine whether the operator changes execution semantics:
+  - For `&(...)` (call operator), focus on the command being executed and any arguments passed immediately before/after the invocation.
+  - For `.(...)` (dot invocation), assess whether the script is intended to run in the current scope (for example, to define or modify functions/variables) and whether that scope change is expected for the host and user context.
+
+- Reassemble full script content when fragmented:
+  - Pivot on `powershell.file.script_block_id` to locate other fragments of the same script block.
+  - If `powershell.total` indicates the content is split across multiple events, use `powershell.sequence` and `powershell.total` to reconstruct the full script block in order before making a determination.
+
+- Identify script origin and persistence opportunities:
+  - If `file.path`, `file.directory`, or `file.name` are present, determine whether the script block is associated with an on-disk script and whether its location aligns with approved administrative tooling or known automation paths.
+  - Treat unusual user-writable or temporary locations as higher risk, especially when paired with high `Esql.script_block_pattern_count`.
+
+- Evaluate obfuscation characteristics and intent:
+  - Use `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_length` to assess how atypical the content is compared to known-good scripts in your environment.
+  - Review surrounding logic in `powershell.file.script_block_text` for additional obfuscation patterns (for example, layered string operations, indirect invocation, or hidden payload material) that may not be captured by this specific match.
+
+- Correlate with adjacent endpoint activity (if available):
+  - Pivot using `host.id` and the alert time window to identify the PowerShell host process, its parent process, and any child processes that indicate follow-on execution.
+  - Review network, file, and registry activity on `host.id` around the same time for signs of payload retrieval, on-disk staging, persistence, or system configuration changes.
+  - Review authentication activity associated with `user.id` around the same time window for anomalous logons, new session sources, or unusual access patterns.
+  - Pivot on `user.id` to identify similar activity across other hosts, which may indicate shared automation, credential reuse, or lateral movement.
+
+- Capture and operationalize investigation artifacts:
+  - Document the reconstructed command strings, notable script fragments, and any referenced file locations (`file.path`) for escalation and threat hunting.
+  - Use those artifacts to search for additional occurrences across the environment, focusing on the same `user.id`, `host.id`, and similar `powershell.file.script_block_text` patterns.
 
 
 *False positive analysis*
 
 
-- Scripts with legitimate concatenated strings for dynamic command execution may trigger the rule. Review the script context to determine if the concatenation serves a valid administrative purpose.
-- Automated scripts from trusted sources that use concatenation for modularity or readability might be flagged. Consider adding these scripts to an allowlist if they are verified as safe.
-- Development or testing environments where PowerShell scripts are frequently modified and tested could generate false positives. Implement exceptions for known development hosts or user accounts.
-- Security tools or monitoring solutions that use PowerShell for legitimate operations may inadvertently match the pattern. Identify these tools and exclude their operations from the rule.
-- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity.
+- Administrative scripts, modules, or internal frameworks that dynamically assemble short command names (cmdlets, functions, aliases) via string concatenation before invoking them for indirection or compatibility.
+- Legitimate automation that uses dot invocation to load or execute helper logic in the current scope, including scripts that intentionally reduce readability for code protection.
 
 
 *Response and remediation*
 
 
-- Isolate the affected host immediately to prevent further execution of potentially malicious scripts and limit lateral movement within the network.
-- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of obfuscated commands.
-- Conduct a thorough review of the script block text and associated script block ID to understand the intent and potential impact of the obfuscated commands.
-- Remove any unauthorized or malicious scripts from the affected system and ensure that all legitimate scripts are verified and signed.
-- Restore the affected system from a known good backup if any malicious activity is confirmed, ensuring that all data integrity checks are performed.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems have been compromised.
-- Update endpoint protection and monitoring tools to enhance detection capabilities for similar obfuscation techniques, leveraging insights from the MITRE ATT&CK framework.
+- If the activity is confirmed or strongly suspected to be malicious or unauthorized:
+  - Contain the affected host identified by `host.id` to prevent further execution and potential lateral movement.
+  - Preserve evidence, including the full reconstructed `powershell.file.script_block_text` (using `powershell.sequence`/`powershell.total` if needed) and any associated on-disk script referenced by `file.path`.
 
+- If an on-disk script is involved (`file.path` present):
+  - Acquire the referenced script file for analysis and validate its provenance.
+  - Remove or quarantine the script if it is unauthorized, and assess for additional copies using the same `file.name` or `file.path` patterns across hosts.
 
-==== Setup
+- If account misuse is suspected:
+  - Scope recent activity for the implicated `user.id` across hosts, prioritize investigation for privileged accounts, and reset credentials per policy.
+  - Review and reduce unnecessary privileges associated with the account, especially if PowerShell access is not required.
 
+- Eradication and recovery:
+  - Identify and remediate follow-on artifacts discovered during scoping (for example, dropped scripts/binaries or persistence mechanisms) using established response procedures.
+  - Increase monitoring for recurrence by hunting for similar dynamic concatenation patterns (high `Esql.script_block_pattern_count`) on the same `host.id` and `user.id`.
 
+- Post-incident hardening:
+  - Ensure PowerShell Script Block Logging coverage is consistently enabled and centrally collected for systems where PowerShell use is permitted.
+  - Limit PowerShell use to approved users and hosts, and review controls that reduce the impact of dynamic invocation and obfuscation in your environment.
 
-*Setup*
+
+==== Setup
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
 
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
+*Setup*
 
-Steps to implement the logging policy via registry:
 
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
@@ -139,6 +184,7 @@ from logs-windows.powershell_operational* metadata _id, _version, _index
     _version,
     _index,
     host.name,
+    host.id,
     agent.id,
     user.id
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc
index 409431721a..8f7b5e15bf 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc
@@ -1,7 +1,7 @@
 [[potential-powershell-obfuscation-via-high-numeric-character-proportion]]
 === Potential PowerShell Obfuscation via High Numeric Character Proportion
 
-Identifies PowerShell scripts with a disproportionately high number of numeric characters, often indicating the presence of obfuscated or encoded payloads. This behavior is typical of obfuscation methods involving byte arrays, character code manipulation, or embedded encoded strings used to deliver and execute malicious content.
+Detects long PowerShell script block content with unusually high numeric character density (high digit-to-length ratio), often produced by byte arrays, character-code reconstruction, or embedded encoded blobs. Attackers use numeric-heavy obfuscation to conceal payloads and rebuild them at runtime to avoid static inspection.
 
 *Rule type*: esql
 
@@ -28,7 +28,7 @@ Identifies PowerShell scripts with a disproportionately high number of numeric c
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 10
+*Version*: 11
 
 *Rule authors*: 
 
@@ -40,48 +40,74 @@ Identifies PowerShell scripts with a disproportionately high number of numeric c
 ==== Investigation guide
 
 
- ## Triage and analysis
+
+*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.
+> 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 Obfuscation via High Numeric Character Proportion*
 
 
-PowerShell is a powerful scripting language used for system administration, but adversaries exploit its capabilities to obfuscate malicious scripts. Obfuscation often involves encoding payloads using numeric characters, making detection challenging. The detection rule identifies scripts with a high proportion of numeric characters, signaling potential obfuscation. By analyzing script length and numeric density, it flags suspicious activity, aiding in defense evasion detection.
+This rule flags long PowerShell script blocks with unusually digit-dense content. Numeric-heavy script blocks are often used to conceal payloads as byte arrays or character codes that are decoded at runtime. Triage should focus on reconstructing the full script content, determining how it was initiated, and identifying any decoded or executed secondary content.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_ratio`: Proportion of the script block's characters that match the alert's target character set, divided by total script length (0-1).
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
 
 
 *Possible investigation steps*
 
 
-- Review the script block text from the alert to understand the context and identify any obvious signs of obfuscation or malicious intent.
-- Examine the file path and host name fields to determine the origin and location of the script execution, which can help assess the potential impact and scope.
-- Check the user ID and agent ID fields to identify the user and system involved, which may provide insights into whether the activity is expected or suspicious.
-- Analyze the powershell.sequence and powershell.total fields to understand the sequence of script execution and the total number of scripts executed, which can indicate whether this is part of a larger pattern of behavior.
-- Investigate any related logs or alerts from the same host or user to identify patterns or correlations that might suggest broader malicious activity.
+- Review `powershell.file.script_block_text` to characterize the numeric content:
+  - Look for long comma-separated numbers, repeated digit sequences, or `0x`-prefixed values that may represent reconstructed bytes.
+  - Identify string reconstruction patterns (for example, casting numeric values to characters) and any subsequent decoding or decompression logic.
+  - Note any execution primitives that would run derived content (for example, invoking dynamically built commands or loading content into memory).
+- If the script is fragmented, use `powershell.sequence` and `powershell.total` to collect the related script block events on the same `host.name` and `user.id` and reconstruct the complete content in the correct order before drawing conclusions.
+- Establish execution context and scope using `host.name`, `host.id`, `agent.id`, and `user.id`:
+  - Determine whether the user context is expected to run PowerShell and whether similar script blocks have occurred recently on the same host or by the same user.
+  - Look for other alerts on the same host or user that could indicate staging, persistence, or lateral movement.
+- Assess script origin using `file.path` and `file.directory` when present:
+  - Determine whether the script is sourced from a location consistent with approved administration or automation workflows.
+  - If the script is file-backed, check for other security telemetry referencing the same path to identify file creation, modification, or repeated execution patterns.
+- Correlate with adjacent telemetry (as available in your environment) using the host and user pivots above:
+  - Process execution telemetry near the alert time to identify the PowerShell host process and its parent, and to understand how PowerShell was launched.
+  - Network telemetry for outbound connections or downloads that could support payload retrieval or command and control.
+  - File activity for dropped payloads or staging artifacts related to the script content or its on-disk source.
 
 
 *False positive analysis*
 
 
-- Scripts with legitimate numeric-heavy content such as data processing or mathematical calculations may trigger the rule. To handle this, identify and whitelist specific scripts or script patterns that are known to be safe.
-- Automated scripts that generate or manipulate large datasets often contain high numeric content. Consider creating exceptions for scripts executed by trusted users or from known safe directories.
-- PowerShell scripts used for legitimate software installations or updates might include encoded data blocks. Review and exclude these scripts by verifying their source and purpose.
-- Scripts containing large hexadecimal strings for legitimate purposes, such as cryptographic operations, may be flagged. Use the exclusion pattern to filter out these known safe operations.
-- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate scripts that may be introduced.
+- Legitimate scripts that embed binary content as numeric arrays (for example, packaging resources into scripts or deploying configuration blobs) can appear digit-dense.
+- Administrative tooling that generates large reports, inventories, or exports may include extensive numeric identifiers and constants.
+- Some legitimate security or management products may produce numeric-heavy PowerShell content as part of automation; validate against known software, expected execution accounts, and change windows.
 
 
 *Response and remediation*
 
 
-- Immediately isolate the affected host to prevent further execution of potentially malicious scripts and limit lateral movement within the network.
-- Review the PowerShell script block text and script block ID to identify any malicious payloads or encoded strings. If confirmed malicious, remove or quarantine the script.
-- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to detect and remove any additional threats or remnants of the obfuscated script.
-- Analyze the file path and user ID associated with the script execution to determine if unauthorized access or privilege escalation occurred. Revoke any suspicious user access and reset credentials if necessary.
-- Escalate the incident to the security operations center (SOC) for further investigation and correlation with other alerts to assess the scope and impact of the threat across the network.
-- Implement enhanced monitoring and logging for PowerShell activities on all endpoints to detect similar obfuscation attempts in the future, focusing on scripts with high numeric character proportions.
-- Review and update endpoint protection policies to restrict the execution of scripts with high numeric density, ensuring compliance with security best practices and reducing the risk of obfuscation-based attacks.
+- If malicious behavior is suspected, contain the affected host to prevent further execution and reduce the risk of follow-on activity.
+- Preserve the script content from `powershell.file.script_block_text` (and any reconstructed multi-part content) for deeper analysis and to support incident response and retrospective hunting.
+- If `file.path` is present and the source is not authorized, remove or quarantine the script and investigate related host artifacts and execution mechanisms.
+- Investigate potential account compromise for the associated `user.id` by reviewing recent authentication and endpoint activity; take credential and session remediation actions in line with your procedures.
+- Hunt for related activity using `host.id`, `agent.id`, `user.id`, and distinctive script patterns identified during triage to find additional impacted systems.
+- Apply preventive controls based on findings, such as tightening PowerShell usage for affected accounts, improving script provenance controls, and enhancing monitoring for similar obfuscation patterns.
 
 
 ==== Setup
@@ -91,21 +117,8 @@ PowerShell is a powerful scripting language used for system administration, but
 *Setup*
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
-
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
-
-Steps to implement the logging policy via registry:
-
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
@@ -145,11 +158,12 @@ from logs-windows.powershell_operational* metadata _id, _version, _index
     _version,
     _index,
     host.name,
+    host.id,
     agent.id,
     user.id
 
 // Filter for scripts with high numeric character ratio
-| where Esql.script_block_ratio > 0.35
+| where Esql.script_block_ratio > 0.5
 
 // Exclude Windows Defender Noisy Patterns
 | where not (
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-high-special-character-proportion.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-high-special-character-proportion.asciidoc
index dd7ceebbb0..b57d67d972 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-high-special-character-proportion.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-high-special-character-proportion.asciidoc
@@ -1,7 +1,7 @@
 [[potential-powershell-obfuscation-via-high-special-character-proportion]]
 === Potential PowerShell Obfuscation via High Special Character Proportion
 
-Identifies PowerShell scripts with an abnormally high proportion of non-alphanumeric characters, often resulting from encoding, string mangling, or dynamic code generation.
+Identifies PowerShell script block content with an unusually high proportion of non-alphanumeric characters, often produced by encoding, string mangling, or dynamic code generation. Attackers use special-character heavy obfuscation to conceal payloads and hinder static analysis and AMSI.
 
 *Rule type*: esql
 
@@ -27,8 +27,9 @@ Identifies PowerShell scripts with an abnormally high proportion of non-alphanum
 * Tactic: Defense Evasion
 * Data Source: PowerShell Logs
 * Rule Type: BBR
+* Resources: Investigation Guide
 
-*Version*: 8
+*Version*: 9
 
 *Rule authors*: 
 
@@ -37,28 +38,118 @@ Identifies PowerShell scripts with an abnormally high proportion of non-alphanum
 *Rule license*: Elastic License v2
 
 
-==== Setup
+==== Investigation guide
 
 
 
-*Setup*
+*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 Obfuscation via High Special Character Proportion*
+
+
+This rule alerts on PowerShell Script Block Logging content where non-alphanumeric characters make up an unusually large share of the script text. This pattern is frequently produced by encoding, aggressive escaping, string mangling, or dynamic code generation intended to hinder inspection.
+
+The alert includes scoring and script-shape fields that help distinguish benign embedded data from suspicious deobfuscation/execution logic. Treat the script block text as potentially untrusted content and focus on reconstructing the full script and identifying downstream behavior through correlation.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_ratio`: Proportion of the script block's characters that match the alert's target character set, divided by total script length (0-1).
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
+
+
+*Possible investigation steps*
+
+
+- Establish scope and execution context:
+  - Review `@timestamp` to set an investigation window and identify preceding/follow-on activity.
+  - Identify the affected `host.id`/`host.name` and the executing `user.id`/`user.name`/`user.domain`.
+  - Determine whether the user/host pairing is expected for PowerShell usage in your environment and whether the account is privileged or widely used.
+
+- Interpret the alert scoring and "shape" signals:
+  - Review `Esql.script_block_ratio` and `Esql.script_block_pattern_count` alongside `powershell.file.script_block_length` to understand how extreme the special-character density is.
+  - Use `Esql.script_block_tmp` to quickly assess whether the special characters cluster in a single region (for example, one embedded blob) or are distributed throughout the script (for example, pervasive mangling).
+  - Use `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_surprisal_stdev` to guide prioritization:
+    - High entropy with many unique symbols commonly aligns with encoded/compressed/encrypted blobs embedded in the script.
+    - High special-character ratio with lower entropy can align with heavy escaping, string concatenation, or code generation.
+    - Low surprisal variability (low standard deviation) can indicate uniformly random-looking content typical of dense encoding.
 
+- Reconstruct the full script block before making a determination:
+  - Pivot on `powershell.file.script_block_id` to collect all fragments for the script block.
+  - Reassemble fragments in order using `powershell.sequence` and confirm completeness using `powershell.total`.
+  - If fragments are missing, treat the visible content as incomplete and continue collection/scoping before concluding intent.
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
+- Analyze `powershell.file.script_block_text` for intent and technique:
+  - Identify whether the content is primarily data (for example, long opaque strings) or executable logic (functions, control flow, and invocation).
+  - Look for common deobfuscation and dynamic execution patterns, such as:
+    - Decoding/decompression routines (for example, Base64 decoding, byte/char transformations, compression streams).
+    - Dynamic invocation or staged execution (for example, `Invoke-Expression`/`IEX`, reflection, `.Invoke()`, `Add-Type`).
+    - Retrieval of remote content or secondary payloads (for example, web request/client usage, download-and-execute flow).
+  - If the script includes clear indicators (domains, URLs, IP addresses, file paths, file names), capture them from the script text for pivoting and scoping.
 
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
+- Determine provenance and expectedness using available file context:
+  - If `file.path`/`file.directory`/`file.name` are present, assess whether the location and naming align with known administrative scripts or approved automation.
+  - If file fields are absent, treat the activity as potentially interactive or in-memory and prioritize identifying what initiated PowerShell through adjacent host telemetry.
+
+- Correlate with adjacent telemetry (as available in your environment) to confirm impact:
+  - Process activity on the same host and time window to determine the initiating process and whether PowerShell was launched indirectly.
+  - Network activity to identify outbound connections consistent with download, staging, or command-and-control behavior.
+  - File and registry activity to identify dropped artifacts or persistence-related changes.
+  - Authentication activity for the same `user.id` to identify suspicious logons or lateral movement preceding the script execution.
+
+- Expand scope across the environment:
+  - Search for additional script block events on the same `host.id` and `user.id` near the alert time to identify staged execution (for example, decoding in one block, execution in another).
+  - Hunt for similar script content using stable substrings from `powershell.file.script_block_text`, and group by `file.name` or `file.path` when present to identify reuse.
+
+
+*False positive analysis*
+
+
+- False positives are most likely when scripts embed or manipulate large non-code payloads (for example, serialized objects, structured data, certificates, or compressed content) or when tooling auto-generates scripts with heavy escaping and templating.
+- Validate benign hypotheses by confirming a consistent execution pattern over time (recurring `host.id` and `user.id`), expected provenance (`file.path`/`file.name` when present), and script content that performs known administrative functions rather than decoding and executing newly generated code.
+- Treat unexpected execution context (new user/host pairing) combined with high entropy and opaque content as higher risk, even if the script text does not immediately reveal its final payload.
+
+
+*Response and remediation*
+
+
+- If malicious or suspicious activity is confirmed:
+  - Contain the affected host to prevent additional execution and lateral movement.
+  - Preserve evidence from the alert, including `powershell.file.script_block_text`, reconstructed fragments (if applicable), `powershell.file.script_block_id`, and the scoring fields (`Esql.script_block_ratio`, `Esql.script_block_pattern_count`, `powershell.file.script_block_entropy_bits`).
+  - Identify and remediate follow-on behavior discovered during correlation (downloaded payloads, dropped files, persistence changes, or suspicious network destinations).
+  - Scope the intrusion by searching for similar script content across the environment using stable substrings from `powershell.file.script_block_text`, and by pivoting on `user.id`, `host.id`, `file.path`, and `file.name`.
+  - If account compromise is suspected, reset credentials for the affected user and review other recent activity for that `user.id`.
+
+- If the activity is determined benign:
+  - Document the responsible script or workflow, expected execution context, and typical frequency.
+  - Monitor for deviations such as new hosts, new users, or materially different script content that may indicate abuse of a legitimate mechanism.
+
+
+==== Setup
+
+
+
+*Setup*
 
-Steps to implement the logging policy via registry:
 
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
@@ -99,6 +190,7 @@ from logs-windows.powershell_operational* metadata _id, _version, _index
     _version,
     _index,
     host.name,
+    host.id,
     agent.id,
     user.id
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc
index 5a2970da9f..b61141b5f7 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc
@@ -1,15 +1,15 @@
 [[potential-powershell-obfuscation-via-invalid-escape-sequences]]
 === Potential PowerShell Obfuscation via Invalid Escape Sequences
 
-Identifies PowerShell scripts that use invalid escape sequences as a form of obfuscation. This technique introduces backticks (`) between characters in a way that does not correspond to valid PowerShell escape sequences, breaking up strings and bypassing pattern-based detections while preserving execution logic. This is designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).
+Detects PowerShell scripts with repeated invalid backtick escapes between word characters (letters, digits, underscore, or dash), splitting tokens while preserving execution. Attackers use this obfuscation to fragment keywords and evade pattern-based detection and AMSI.
 
 *Rule type*: esql
 
 *Rule indices*: None
 
-*Severity*: low
+*Severity*: medium
 
-*Risk score*: 21
+*Risk score*: 47
 
 *Runs every*: 5m
 
@@ -28,7 +28,7 @@ Identifies PowerShell scripts that use invalid escape sequences as a form of obf
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 10
+*Version*: 11
 
 *Rule authors*: 
 
@@ -40,78 +40,113 @@ Identifies PowerShell scripts that use invalid escape sequences as a form of obf
 ==== Investigation guide
 
 
- ## Triage and analysis
+
+*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.
+> 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 Obfuscation via Invalid Escape Sequences*
 
 
-PowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques to evade detection. By inserting invalid escape sequences, attackers can obscure malicious scripts, bypassing static analysis and security tools like AMSI. The detection rule identifies such obfuscation by analyzing script patterns, specifically targeting unusual backtick usage, to flag potential threats.
+This rule flags PowerShell script block content that repeatedly inserts invalid backtick escape sequences within otherwise contiguous word characters. This can fragment tokens (cmdlets, parameters, variable names, strings) while preserving execution and readability to the interpreter, which can hinder content inspection and pattern-based detections.
 
+Analyst goals:
+- Reconstruct complete script block content when split across multiple events.
+- Normalize the content (remove or correct invalid escapes) to reveal the underlying logic.
+- Determine execution context (host, user, script origin) and correlate with adjacent activity to assess intent and impact.
 
-*Possible investigation steps*
 
+*Key alert fields to review*
 
-- Review the `powershell.file.script_block_text` field to understand the context and content of the script block that triggered the alert. Look for patterns of invalid escape sequences and assess whether they appear intentionally obfuscated.
-- Examine the `file.name` and `file.path` fields to determine the origin and location of the script. This can help identify whether the script is part of a legitimate application or potentially malicious.
-- Check the `host.name` and `agent.id` fields to identify the affected system and the agent responsible for logging the event. This information is crucial for understanding the scope of the potential threat.
-- Analyze the `user.id` field to ascertain which user executed the script. This can provide insights into whether the user has a history of executing suspicious scripts or if their account may be compromised.
-- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution sequence and correlate it with other related script blocks, which may reveal additional obfuscation or malicious activity.
-- Assess the `count` field to evaluate the extent of obfuscation detected. A higher count may indicate more aggressive obfuscation techniques, warranting further scrutiny.
 
+- `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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
 
-*False positive analysis*
 
+*Possible investigation steps*
 
-- Scripts from Visual Studio Code's PowerShell extension may trigger false positives due to its shell integration. To handle this, exclude scripts containing the pattern "$([char]0x1b)]633" from detection.
-- PowerShell modules with names starting with "TSS_" may be flagged incorrectly. Exclude these by adding a condition to ignore files matching the pattern "TSS_*.psm1".
-- Legitimate scripts that use backticks for formatting or other non-obfuscation purposes might be detected. Review such scripts and, if verified as safe, add them to an exception list based on their script block ID or file path.
-- Regularly update the exclusion list to reflect changes in legitimate script usage patterns, ensuring that new false positives are addressed promptly.
 
+- Establish timeline and ownership:
+  - Anchor the activity using `@timestamp`, then record `host.name`, `host.id`, and `agent.id`.
+  - Identify the execution context with `user.name`, `user.domain`, and `user.id`. Note whether the account is expected to run PowerShell on this host and whether the host is commonly used for scripting.
 
-*Response and remediation*
+- Assess the likelihood of intentional obfuscation:
+  - Review `Esql.script_block_pattern_count` to understand how heavily the content is fragmented. Higher counts generally increase confidence that this is deliberate obfuscation rather than incidental escaping.
+  - Use `powershell.file.script_block_length` as size context and review `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_surprisal_stdev` to characterize the content (simple text vs. mixed/randomized payloads).
+  - Compare `Esql.script_block_tmp` to `powershell.file.script_block_text` to understand where obfuscation is concentrated (localized string vs. widespread token fragmentation).
 
+- Reconstruct complete content when split across events:
+  - If `powershell.total` is greater than 1, pivot on `powershell.file.script_block_id` and rebuild the script by ordering segments on `powershell.sequence`.
+  - Validate the reconstructed set is complete (sequence 1 through `powershell.total`). Missing segments should be treated as an investigative gap and may require additional scoping.
 
-- Isolate the affected host immediately to prevent lateral movement and further execution of potentially malicious scripts. Disconnect the host from the network and disable remote access.
+- Determine script origin and delivery:
+  - If `file.path`, `file.directory`, and `file.name` are present, treat the script block as file-associated. Evaluate whether the location and naming are consistent with approved scripts or expected tooling for the endpoint.
+  - If file fields are absent, treat the script as inline or dynamically generated content and prioritize correlation by `host.id`, `user.id`, and time.
 
-- Analyze the script block text and file path to identify the source and nature of the obfuscated script. Determine if the script is part of a larger attack or if other systems are affected.
+- Normalize and interpret the script content safely:
+  - In a controlled analysis workflow, normalize the script by removing or correcting invalid backtick insertions so that split tokens become readable. Keep both the original and normalized versions for reporting.
+  - Review the normalized text for behaviors that indicate malicious intent (secondary payload retrieval, dynamic execution, decoding/decompression, data collection, persistence logic, or remote interaction).
+  - Extract and document indicators present in the content (network destinations, file paths/names, unique strings, or embedded encoded blobs) for scoping.
 
-- Remove or quarantine the identified malicious script and any associated files from the host. Ensure that all remnants of the obfuscated code are eliminated to prevent re-execution.
+- Correlate within PowerShell telemetry:
+  - Pivot on `host.id` and `user.id` to identify additional `powershell.file.script_block_text` events shortly before and after the alert time to capture staging, follow-on commands, and potential cleanup.
+  - Check for the same `powershell.file.script_block_id` appearing across hosts, or for repeated normalized strings, to identify automation reuse or broader activity.
 
-- Conduct a thorough scan of the host using updated antivirus and antimalware tools to detect and remove any additional threats or indicators of compromise.
+- Correlate with adjacent endpoint activity (if available in your environment):
+  - Review process execution around `@timestamp` on `host.name` to identify the PowerShell host process and its parent, then assess whether the launch chain aligns with expected activity for the user and endpoint.
+  - Review network activity around the alert time for connections that align with indicators extracted from the script content.
+  - Review file and registry activity around the same time window for artifacts consistent with the script (new or modified scripts, dropped files, or persistence-related changes).
+  - Review authentication activity associated with `user.id` around the alert time for suspicious logons or remote access that may align with script execution.
 
-- Review and update PowerShell execution policies and security settings to restrict the execution of scripts with invalid escape sequences. Implement stricter controls to prevent similar obfuscation techniques.
+- Scope impact:
+  - Search for other alerts/events with similar obfuscation characteristics on the same host and for the same user to determine whether this is a one-off execution or a repeated pattern.
+  - If multiple hosts are involved, prioritize investigation for critical assets and accounts with elevated privileges.
 
-- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and monitoring. Provide detailed logs and findings to assist in understanding the scope and impact of the threat.
 
-- Implement enhanced logging and monitoring for PowerShell activities across the network to detect and respond to similar obfuscation attempts promptly. Use the identified patterns to refine detection capabilities.
+*False positive analysis*
 
 
-==== Setup
+- Legitimate scripts can contain backticks for formatting, string construction, or content generation; however, repeated invalid escape sequences embedded inside alphanumeric tokens are uncommon. Validate whether the execution context (`host.id`, `user.id`) aligns with known administrative or developer activity.
+- Some commercial or internal tools intentionally obfuscate PowerShell to protect intellectual property. Confirm whether the script origin (`file.path` when present), account context, and prevalence across the environment match an approved application or workflow.
+- Copy/paste artifacts and encoding transformations can introduce unexpected characters. When suspected, compare the normalized content to known-good scripts and assess whether the obfuscation is systematic (repeating across many tokens) versus localized.
 
 
+*Response and remediation*
 
-*Setup*
+
+- If the activity is confirmed or strongly suspected malicious:
+  - Contain affected host(s) to prevent further execution and lateral movement.
+  - Preserve evidence: reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and alert-derived fields (`Esql.script_block_tmp`, `Esql.script_block_pattern_count`, and the script block metrics).
+  - If `file.path` is present, collect and quarantine the referenced script and review the surrounding directory for related artifacts.
+  - Use indicators extracted from normalized content to scope related activity across endpoints (pivot on `host.id`, `user.id`, `file.path`, and unique strings from the script).
+  - Coordinate credential remediation for affected accounts when remote execution, credential material, or post-exploitation behavior is suspected.
+
+- If the activity is benign but requires reduction:
+  - Document the legitimate source (expected hosts/users and `file.path` when applicable).
+  - Apply narrowly scoped tuning using stable attributes available in the alert (such as `host.id`, `user.id`, and `file.path`) and continue monitoring for deviations in script content and execution context.
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
+==== Setup
+
 
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
 
-Steps to implement the logging policy via registry:
+*Setup*
+
 
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
@@ -143,6 +178,7 @@ from logs-windows.powershell_operational* metadata _id, _version, _index
     _version,
     _index,
     host.name,
+    host.id,
     agent.id,
     user.id
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-reverse-keywords.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-reverse-keywords.asciidoc
index a571895dd7..57045878dd 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-reverse-keywords.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-reverse-keywords.asciidoc
@@ -1,7 +1,7 @@
 [[potential-powershell-obfuscation-via-reverse-keywords]]
 === Potential PowerShell Obfuscation via Reverse Keywords
 
-Identifies PowerShell scripts that use reversed strings as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).
+Detects PowerShell scripts containing reversed keyword strings associated with execution or network activity (for example, ekovni, noisserpxe, daolnwod, tcejbo-wen, tcejboimw, etc.). Attackers reverse keywords and reconstruct them at runtime to hide intent and evade static detection and AMSI.
 
 *Rule type*: esql
 
@@ -28,7 +28,7 @@ Identifies PowerShell scripts that use reversed strings as a form of obfuscation
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 9
+*Version*: 10
 
 *Rule authors*: 
 
@@ -40,48 +40,94 @@ Identifies PowerShell scripts that use reversed strings as a form of obfuscation
 ==== Investigation guide
 
 
- ## Triage and analysis
+
+*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.
+> 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 Obfuscation via Reverse Keywords*
 
 
-PowerShell, a powerful scripting language in Windows environments, is often targeted by adversaries for obfuscation to bypass security measures like AMSI. Attackers reverse keywords in scripts to evade static analysis. The detection rule identifies such obfuscation by searching for reversed keywords, replacing them with a unique marker, and counting occurrences. This helps in flagging scripts with multiple obfuscated elements, indicating potential malicious activity.
+This alert indicates PowerShell script block content contains multiple reversed keyword strings commonly associated with execution, string manipulation, environment discovery, or networking. Reversing strings is frequently paired with runtime reconstruction (for example, reversing character arrays or joining string fragments) to reduce readability and evade simple content inspection.
+
+Determine whether the script is part of expected administrative automation, software tooling, or an unauthorized execution chain. Prioritize analysis that reconstructs the full script, deobfuscates the reversed tokens, and identifies any follow-on behaviors such as dynamic execution, network access, or system discovery.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
 
 
 *Possible investigation steps*
 
 
-- Review the `powershell.file.script_block_text` field to understand the context and content of the script that triggered the alert. Look for any suspicious or unexpected behavior in the script logic.
-- Examine the `file.path` field to determine the location of the script on the system. This can provide insights into whether the script is part of a legitimate application or potentially malicious.
-- Check the `powershell.file.script_block_id` and `powershell.sequence` fields to identify if the script is part of a larger sequence of commands. This can help in understanding the full scope of the script's execution.
-- Investigate the `agent.id` field to identify the specific endpoint where the script was executed. This can help in correlating with other alerts or logs from the same machine.
-- Assess the `count` field to determine the extent of obfuscation. A higher count may indicate a more heavily obfuscated script, suggesting a higher likelihood of malicious intent.
+- Identify the execution scope and ownership:
+  - Review `host.name` / `host.id` to confirm the affected endpoint and its criticality.
+  - Review `user.id` (and `user.name` / `user.domain` if available) to understand the account context and whether this user is expected to run PowerShell on this host.
+- Prioritize based on obfuscation signals:
+  - Review `Esql.script_block_pattern_count`; higher counts suggest more extensive keyword hiding and can increase suspicion.
+  - Use `powershell.file.script_block_length`, `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_surprisal_stdev` to gauge how heavily obfuscated or machine-generated the content may be (treat these as supporting context, not proof of maliciousness).
+- Reconstruct the full script content when split:
+  - If `powershell.total` is greater than 1, retrieve all events with the same `powershell.file.script_block_id` and order them by `powershell.sequence` to rebuild the complete script block content.
+  - Preserve both the reconstructed script and the original per-event `powershell.file.script_block_text` to maintain context and ordering.
+- Deobfuscate and interpret intent:
+  - Review `powershell.file.script_block_text` for reversed tokens and reverse them to identify the intended keywords and operations (for example, indicators of dynamic execution, downloads, socket/connection handling, WMI usage, or Win32 references).
+  - Look for runtime string reconstruction patterns in the script content (for example, joins, character array operations, or replace operations) that turn reversed fragments into executable commands or parameters.
+  - Use `Esql.script_block_tmp` to quickly locate the matched areas, then validate findings against `powershell.file.script_block_text`.
+- Evaluate file-origin context (when present):
+  - Review `file.path` (and `file.directory` / `file.name` if available) to determine whether the script is associated with an on-disk file and whether that location aligns with your organization's expected script locations and deployment practices.
+  - If an on-disk script is indicated, coordinate collection of the referenced file for offline analysis and determine whether it is present on other systems.
+- Extract and operationalize indicators:
+  - From `powershell.file.script_block_text`, extract any embedded indicators such as hostnames, IP addresses, URLs, ports, file paths, or encoded blobs.
+  - Use extracted indicators to scope for related activity on the same `host.id` and across other hosts where the same `user.id` is active, focusing on the alert timeframe and immediately adjacent activity.
+- Correlate with adjacent telemetry to identify the execution chain and impact (as available in your environment):
+  - Process activity: identify the PowerShell host process and the initiating parent process to understand whether execution was interactive, scheduled, or launched by another program.
+  - Network activity: look for outbound connections aligned with the alert timestamp, especially if deobfuscated content suggests downloads or socket connections.
+  - File and registry activity: look for payload staging, new or modified files, or persistence-related changes that occur shortly after the script block execution.
+  - Authentication activity: review for suspicious logons, remote session creation, or lateral movement attempts around the same time on the affected host.
+- Determine severity and next actions:
+  - If the deobfuscated content indicates remote retrieval, execution of downloaded content, credential access, persistence, or lateral movement, treat the alert as potentially malicious and escalate for response.
+  - If the script appears benign, document the validated purpose, expected owner, and any recurring identifiers (such as file location patterns) to support future triage.
 
 
 *False positive analysis*
 
 
-- Scripts with legitimate administrative functions may use reversed keywords for benign purposes, such as custom logging or debugging. Review the context of the script to determine if the usage is intentional and non-malicious.
-- Automated scripts generated by legitimate software tools might include reversed keywords as part of their normal operation. Identify these tools and create exceptions for their known script patterns to prevent unnecessary alerts.
-- Developers or IT personnel might use reversed keywords in test environments to simulate obfuscation techniques. Ensure these environments are well-documented and excluded from production monitoring to avoid false positives.
-- PowerShell scripts used in educational or training settings may intentionally include obfuscation techniques for learning purposes. Exclude these scripts by identifying their unique characteristics or file paths.
-- Regularly update the list of excluded scripts or patterns as new legitimate use cases are identified, ensuring the detection rule remains effective without generating excessive false positives.
+- Internal scripts or tooling may use reversed strings as lightweight obfuscation to conceal configuration values or reduce casual readability. Validate the script's ownership, change history, and whether its presence and execution timing are expected for `host.id` and `user.id`.
+- Commercial software, endpoint management agents, or security tooling may generate or embed obfuscated PowerShell during installation, updates, or health checks. Validate whether the activity aligns with known maintenance windows, expected endpoints, and consistent script content and `file.path` patterns.
+- Authorized security testing may intentionally use string reversal. Confirm the scope, timing, and target hosts with the appropriate stakeholders before closing the alert.
 
 
 *Response and remediation*
 
 
-- Isolate the affected system from the network to prevent further spread of potentially malicious scripts.
-- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing malicious activity.
-- Conduct a thorough review of the script block text and associated files to understand the scope and intent of the obfuscation.
-- Remove or quarantine any identified malicious scripts or files from the system to prevent re-execution.
-- Restore affected systems from a known good backup if malicious activity has altered system integrity.
-- Update endpoint protection and security tools to recognize and block similar obfuscation techniques in the future.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and monitoring of potential lateral movement or additional threats.
+- If activity is suspicious or unauthorized, contain the affected host to prevent further script execution and potential follow-on actions.
+- Preserve evidence:
+  - Retain the full `powershell.file.script_block_text` (including all segments reconstructed via `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`).
+  - Retain `file.path` context and the alert metadata needed to pivot (such as `host.id` and `user.id`).
+- Identify and remediate the execution source:
+  - Determine how PowerShell was launched (interactive, scheduled, or by another process) using correlated telemetry, and remove the triggering mechanism.
+  - If an on-disk script is involved, remediate the file at `file.path` and any associated payloads or artifacts identified during analysis.
+- Scope and hunt:
+  - Search for the same or similar obfuscated content and extracted indicators across other endpoints, prioritizing systems accessed by the same `user.id` and systems with similar `file.path` patterns.
+- Account actions:
+  - If account misuse is suspected, follow organizational procedures to contain the account (for example, credential reset and session revocation) and review recent activity for additional suspicious behavior.
+- Recovery and hardening:
+  - Verify PowerShell logging coverage and retention are sufficient for incident response, and monitor for recurrence of similar reversed-keyword patterns on affected hosts and users.
 
 
 ==== Setup
@@ -91,21 +137,8 @@ PowerShell, a powerful scripting language in Windows environments, is often targ
 *Setup*
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
-
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
-
-Steps to implement the logging policy via registry:
-
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
@@ -142,7 +175,10 @@ from logs-windows.powershell_operational* metadata _id, _version, _index
     _id,
     _version,
     _index,
-    agent.id
+    host.name,
+    host.id,
+    agent.id,
+    user.id
 
 // Filter for scripts that match the pattern at least twice
 | where Esql.script_block_pattern_count >= 2
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-special-character-overuse.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-special-character-overuse.asciidoc
index 2871673450..a6cabcd75d 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-special-character-overuse.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-special-character-overuse.asciidoc
@@ -1,15 +1,15 @@
 [[potential-powershell-obfuscation-via-special-character-overuse]]
 === Potential PowerShell Obfuscation via Special Character Overuse
 
-Identifies PowerShell scripts with an unusually high proportion of whitespace and special characters, often indicative of obfuscation. This behavior is commonly associated with techniques such as SecureString encoding, formatting obfuscation, or character-level manipulation designed to bypass static analysis and AMSI inspection.
+Detects PowerShell scripts dominated by whitespace and special characters with low symbol diversity, a profile often produced by formatting or encoding obfuscation. Attackers use symbol-heavy encoding or formatting (for example, SecureString-style blobs or character-level transforms) to hide payloads and evade static analysis and AMSI.
 
 *Rule type*: esql
 
 *Rule indices*: None
 
-*Severity*: low
+*Severity*: medium
 
-*Risk score*: 21
+*Risk score*: 47
 
 *Runs every*: 5m
 
@@ -28,7 +28,7 @@ Identifies PowerShell scripts with an unusually high proportion of whitespace an
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 9
+*Version*: 10
 
 *Rule authors*: 
 
@@ -40,48 +40,95 @@ Identifies PowerShell scripts with an unusually high proportion of whitespace an
 ==== Investigation guide
 
 
- ## Triage and analysis
+
+*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.
+> 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 Obfuscation via Special Character Overuse*
 
 
-PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's flexibility to obfuscate scripts, using excessive special characters to evade detection. The detection rule identifies scripts with high special character density, indicating potential obfuscation, by analyzing script length and character patterns, thus aiding in uncovering malicious activities.
+This rule flags PowerShell script block content that is unusually long and dominated by whitespace and a narrow set of special characters. This profile is often associated with formatting or encoding obfuscation where payload logic is transformed into symbol-heavy strings and reconstructed at runtime. Use the steps below to validate execution context, reconstruct full content, determine likely intent, and scope related activity.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_ratio`: Proportion of the script block's characters that match the alert's target character set, divided by total script length (0-1).
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
 
 
 *Possible investigation steps*
 
 
-- Review the dedup_space_script_block field to understand the script's structure and identify any suspicious patterns or keywords that might indicate obfuscation techniques.
-- Analyze the replaced_with_fire field to assess the density and distribution of special characters, which can provide insights into the obfuscation methods used.
-- Examine the file.path and host.name fields to determine the origin and context of the script execution, which can help identify if the script was run on a critical system or by a privileged user.
-- Check the user.id and agent.id fields to verify the identity of the user or agent executing the script, which can help assess if the activity aligns with expected behavior or if it might be unauthorized.
-- Correlate the powershell.file.script_block_id with other logs or alerts to identify if similar scripts have been executed elsewhere in the environment, indicating a broader attack pattern.
+- Review alert context and scope:
+  - Use `@timestamp` to identify when the activity occurred and to bound the timeline for correlation.
+  - Review `host.name` and `host.id` to understand which endpoint produced the script block.
+  - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to run PowerShell on this host.
+  - If multiple alerts are present, group by `host.id` and `user.id` to identify concentrated or repeat activity.
+
+- Analyze the script block content for obfuscation and intent:
+  - Inspect `powershell.file.script_block_text` to understand what is being executed. Obfuscation commonly presents as large blocks of escaped characters, excessive punctuation, and character-level reassembly.
+  - Use `Esql.script_block_tmp` to quickly locate symbol-dense regions, then interpret the corresponding content in `powershell.file.script_block_text`.
+  - Use `Esql.script_block_ratio`, `powershell.file.script_block_unique_symbols`, `powershell.file.script_block_entropy_bits`, and `powershell.file.script_block_surprisal_stdev` to gauge how atypical the content is compared to known-good scripts in your environment.
+  - Identify deobfuscation and runtime execution patterns such as repeated string replacement, concatenation, `[char]` casting, `-join`, formatting operators, reflection, and dynamic invocation (for example, `Invoke-Expression` or executing decoded strings).
+  - Capture any embedded indicators from `powershell.file.script_block_text`, including URLs, hostnames, IP addresses, file paths, registry paths, or scheduled task/service names.
+
+- Reconstruct full script content when logged in chunks:
+  - If `powershell.total` indicates multiple fragments, pivot on `powershell.file.script_block_id` and reassemble the script in `powershell.sequence` order.
+  - Confirm completeness by comparing observed fragments to `powershell.total`. Missing segments can hide key decode or execution stages.
+
+- Validate script origin and expected usage:
+  - Review `file.path`, `file.directory`, and `file.name` (when present) to determine whether the script originated from disk, a module path, or an unusual location.
+  - If the script is file-backed, assess whether the file location and naming are consistent with approved administration and automation practices for the host and user.
+
+- Scope for related PowerShell activity:
+  - Pivot on `powershell.file.script_block_hash` (when available) to identify repeated executions of the same content across hosts and users.
+  - Review additional script blocks on the same `host.id` and `user.id` around the alert time for staging behavior (variable setup, decoding routines, or creation of additional script blocks).
+  - Use stable substrings from `powershell.file.script_block_text` (unique function names or strings) to find related executions that may not match this specific obfuscation profile.
+
+- Correlate with adjacent telemetry to confirm execution chain and impact (if available):
+  - Use `host.id`, `user.id`, and `@timestamp` to pivot into process telemetry and determine which process initiated PowerShell and whether the parent process is expected.
+  - Review activity on the same host around the alert time for signs of follow-on behavior such as outbound connections, file creation/modification, registry changes, or persistence mechanisms consistent with the recovered script logic.
 
 
 *False positive analysis*
 
 
-- Scripts with legitimate use of special characters for formatting or encoding may trigger false positives. Review the script's purpose and context to determine if the use of special characters is justified.
-- Automated scripts that heavily rely on string manipulation or dynamic content generation might be flagged. Consider adding exceptions for known scripts or trusted sources to reduce unnecessary alerts.
-- PowerShell scripts used in development or testing environments often contain high special character density. Implement environment-based exclusions to prevent these from being flagged in non-production settings.
-- Scripts utilizing SecureString or other security-related encoding methods may appear obfuscated. Verify the script's origin and purpose, and whitelist these methods if they are part of standard security practices.
-- Regularly update the detection rule to refine the pattern matching and reduce false positives by incorporating feedback from security analysts and system administrators.
+- Legitimate automation can embed large protected or serialized values (for example, encrypted configuration blobs or SecureString exports) that appear symbol-heavy.
+- Deployment and configuration tooling may generate templated PowerShell with extensive escaping or large here-strings, especially when embedding JSON/XML or code as data.
+- Authorized security testing may use obfuscation techniques that resemble this behavior.
+- To validate a benign source, confirm the script's provenance and repeatability:
+  - Check whether `file.path` (when present) and `powershell.file.script_block_hash` consistently map to an approved script, owner, and expected execution pattern.
+  - Compare the alerting `user.id` and `host.id` against known automation accounts and managed endpoints; unexpected combinations warrant escalation.
 
 
 *Response and remediation*
 
 
-- Isolate the affected host immediately to prevent lateral movement and further execution of potentially malicious scripts.
-- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing malicious activity.
-- Conduct a thorough review of the script block text and associated metadata to understand the intent and potential impact of the obfuscated script.
-- Remove any unauthorized or malicious scripts from the affected system to prevent re-execution.
-- Restore the system from a known good backup if the script has caused significant changes or damage to the system.
-- Update endpoint protection and intrusion detection systems to recognize and block similar obfuscation techniques 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.
+- If malicious or suspicious activity is confirmed:
+  - Contain the affected host according to your incident response procedures to prevent additional execution and lateral movement.
+  - Preserve evidence for triage and forensics, including `powershell.file.script_block_text` (and any reconstructed content), `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, `powershell.file.script_block_hash` (if available), `file.path` (if present), and the execution context (`host.name`, `host.id`, `user.name`, `user.domain`, `user.id`, `agent.id`, `@timestamp`).
+  - Scope the activity by searching for the same `powershell.file.script_block_hash` and any extracted indicators across the environment.
+  - Identify and remediate follow-on actions associated with the script (downloaded payloads, dropped files, persistence changes, or credential access). Apply blocking controls for confirmed indicators where feasible.
+  - If the script content indicates credential material handling or unauthorized automation, rotate affected credentials and review account activity for misuse.
+
+- If the activity is determined to be benign:
+  - Document the script owner, purpose, and expected execution context (hosts, users, and schedule), using `file.path` and `powershell.file.script_block_hash` (when available) as stable identifiers.
+  - Monitor for drift, such as execution by different users/hosts, unexpected file paths, or material changes in the script block content.
 
 
 ==== Setup
@@ -91,21 +138,10 @@ PowerShell is a powerful scripting language used for task automation and configu
 *Setup*
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
+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
 
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
-
-Steps to implement the logging policy via registry:
-
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+This rule uses the following fields that require the Windows Integration v3.3.0 and up: `powershell.file.script_block_unique_symbols`.
 
 
 ==== Rule query
@@ -116,6 +152,9 @@ reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
 from logs-windows.powershell_operational* metadata _id, _version, _index
 | where event.code == "4104"
 
+// filter for scripts with low unique symbol counts, which can indicate special character obfuscation
+| where powershell.file.script_block_unique_symbols < 50
+
 // replace repeated spaces used for formatting after a new line with a single space to reduce FPs
 | eval Esql.script_block_tmp = replace(powershell.file.script_block_text, """\n\s+""", "\n ")
 
@@ -127,7 +166,7 @@ from logs-windows.powershell_operational* metadata _id, _version, _index
 // The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1
 | eval Esql.script_block_tmp = replace(
     Esql.script_block_tmp,
-    """[\s\$\{\}\+\@\=\(\)\^\\\"~\[\]\?\.]""",
+    """[\s\$\{\}\+\@\=\(\)\^\\\"~\[\]\?\./%#\`\'\;\-\!\*]""",
     "🔥"
 )
 
@@ -151,11 +190,12 @@ from logs-windows.powershell_operational* metadata _id, _version, _index
     _version,
     _index,
     host.name,
+    host.id,
     agent.id,
     user.id
 
 // Filter for scripts with high whitespace and special character ratio
-| where Esql.script_block_ratio > 0.75
+| where Esql.script_block_ratio >= 0.75
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-string-concatenation.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-string-concatenation.asciidoc
index 3b5ec23498..da980c524e 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-string-concatenation.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-string-concatenation.asciidoc
@@ -1,15 +1,15 @@
 [[potential-powershell-obfuscation-via-string-concatenation]]
 === Potential PowerShell Obfuscation via String Concatenation
 
-Identifies PowerShell scripts that use string concatenation as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).
+Detects PowerShell scripts that repeatedly concatenates multiple quoted string literals with + to assemble commands or tokens at runtime. Attackers use string concatenation to fragment keywords or URLs and evade static analysis and AMSI.
 
 *Rule type*: esql
 
 *Rule indices*: None
 
-*Severity*: medium
+*Severity*: high
 
-*Risk score*: 47
+*Risk score*: 73
 
 *Runs every*: 5m
 
@@ -28,7 +28,7 @@ Identifies PowerShell scripts that use string concatenation as a form of obfusca
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 9
+*Version*: 10
 
 *Rule authors*: 
 
@@ -40,49 +40,93 @@ Identifies PowerShell scripts that use string concatenation as a form of obfusca
 ==== Investigation guide
 
 
- ## Triage and analysis
+
+*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.
+> 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 Obfuscation via String Concatenation*
 
 
-PowerShell is a powerful scripting language used for task automation and configuration management. Adversaries exploit its flexibility to obfuscate malicious scripts, often using string concatenation to evade detection. The detection rule identifies scripts with excessive concatenation patterns, flagging potential obfuscation by analyzing script length and pattern frequency, thus aiding in uncovering hidden threats.
+This rule identifies PowerShell script block content that uses repeated concatenation of quoted string literals. This technique is commonly used to fragment keywords, URLs, and command text so they are assembled only at runtime. Focus the investigation on reconstructing the final strings, understanding how they are used within the script, and scoping related activity from the same host and user.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
 
 
 *Possible investigation steps*
 
 
-- Review the powershell.file.script_block_text field to understand the content and purpose of the script, focusing on the sections identified by the string concatenation patterns.
-- Examine the file.path field to determine the location of the script on the host system, which can provide context about its origin and potential legitimacy.
-- Check the host.name and agent.id fields to identify the affected system and correlate with other security events or alerts from the same host for broader context.
-- Investigate the user.id field to determine which user executed the script, assessing their role and whether they have a legitimate reason to run such scripts.
-- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution flow and sequence of the script blocks, which may reveal additional obfuscation or malicious behavior.
-- Cross-reference the _id and _index fields with other logs or alerts to identify any related incidents or patterns of activity that might indicate a larger threat campaign.
+- Establish alert context and prioritize review:
+  - Review `host.name` / `host.id` and `user.name` / `user.domain` / `user.id` to understand where and under which account the script executed.
+  - Use `Esql.script_block_pattern_count` to gauge how heavily the script relies on concatenation. Higher counts can indicate more deliberate obfuscation.
+  - Review `powershell.file.script_block_length` and the statistical fields (`powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, `powershell.file.script_block_unique_symbols`) to assess whether the script contains high-variance or high-randomness content that may indicate encoding, packing, or layered obfuscation.
+
+- Identify the most likely script origin:
+  - Review `file.path`, `file.directory`, and `file.name` (when present) to determine whether the script block content was sourced from an on-disk script. Note whether the location is expected for administrative tooling or is user-writable/unusual for the host role.
+  - If file origin fields are not populated, treat the activity as potentially inline/interactive execution and prioritize identifying what initiated it through correlation with surrounding telemetry.
+
+- Recover the assembled strings and intent:
+  - Start with `Esql.script_block_tmp` to find where concatenation patterns occur, then inspect the surrounding text in `powershell.file.script_block_text` for the full logic.
+  - Reconstruct concatenated literals by joining the quoted fragments (preserving ordering and separators) to reveal the final keywords, paths, URLs, arguments, or identifiers the script is attempting to hide.
+  - Look for how reconstructed strings are used, especially:
+    - Dynamic invocation of reconstructed commands or expressions.
+    - Download or retrieval of remote content.
+    - Decoding/decryption routines and second-stage content handling.
+    - Construction of file paths, scheduled execution artifacts, or configuration changes.
+  - Capture any reconstructed indicators (domains, URLs, file names, directories, command fragments) that can be used to scope other activity.
+
+- Reconstruct full script content when split across events:
+  - Pivot on `powershell.file.script_block_id` to collect related script block events from the same execution context.
+  - If `powershell.total` is greater than 1, gather all fragments and order them by `powershell.sequence` to rebuild the complete script content before making a final determination.
+  - Review whether additional script blocks were executed in close succession by the same `user.id` on the same `host.id`, which may indicate staging or multi-step execution.
+
+- Scope the activity across hosts and accounts:
+  - On the same `host.id`, look for other script blocks that share the same `file.path` or distinctive reconstructed strings to determine if this is a single run or repeated behavior.
+  - Pivot on `user.id` to identify the same technique on other endpoints, which can indicate credential misuse or automated distribution.
+
+- Correlate with adjacent telemetry (as available in your environment):
+  - Process execution: identify the PowerShell host process and its parent process near the alert time to determine whether execution was interactive or spawned by another program.
+  - Network activity: if reconstructed strings include URLs/domains, check for outbound connections, downloads, or callbacks that align with the alert timeframe.
+  - Host changes: review nearby file and registry activity for payload drops, persistence creation, or configuration changes that match reconstructed paths or names.
+  - Authentication: review recent logon activity for `user.id` and `host.id` for anomalies that may explain the execution (new logon source, unusual logon type, or unexpected access patterns).
 
 
 *False positive analysis*
 
 
-- Scripts with legitimate string concatenation for logging or configuration purposes may trigger the rule. Review the script context to determine if the concatenation is part of a benign operation.
-- Automated scripts generated by development tools might use string concatenation extensively. Identify these tools and consider excluding their output directories or specific script patterns from the rule.
-- PowerShell scripts used in complex data processing tasks may naturally contain high levels of string concatenation. Analyze the script's purpose and, if deemed safe, add exceptions for specific script block IDs or paths.
-- Frequent administrative scripts that concatenate strings for dynamic command execution could be flagged. Verify the script's source and function, then whitelist known safe scripts by user ID or host name.
-- Consider adjusting the threshold for pattern detection if legitimate scripts frequently exceed the current limit, ensuring that the rule remains effective without generating excessive false positives.
+- Legitimate administrative or operational scripts may concatenate many string literals to generate dynamic content (for example, configuration files, templated output, or complex argument strings). Validate whether the reconstructed strings align with expected internal tooling and whether the execution context (`host.id`, `user.id`, and `file.path`) matches normal operations.
 
 
 *Response and remediation*
 
 
-- Isolate the affected host immediately to prevent further spread of potentially malicious scripts across the network. Disconnect it from the network and any shared resources.
-- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of potentially obfuscated scripts.
-- Conduct a thorough examination of the script block text and associated files to identify and remove any malicious code or artifacts. Use a secure, isolated environment for analysis.
-- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be easily remediated.
-- Update and run a full antivirus and antimalware scan on the affected system to ensure no additional threats are present.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
-- Implement enhanced monitoring and logging for PowerShell activities across the network to detect similar obfuscation attempts in the future, ensuring that alerts are configured to notify the appropriate personnel promptly.
+- If malicious or suspicious activity is confirmed:
+  - Contain the affected host to prevent follow-on execution or lateral movement.
+  - Preserve evidence from the alert, including `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence` / `powershell.total`, and any `file.path` details that indicate script origin.
+  - Use reconstructed strings to scope across the environment for related script blocks and any referenced artifacts (additional scripts, payload files, or remote destinations).
+  - Identify and remediate the initial execution vector by tracing the execution chain (user context and initiating process) and removing any persistence mechanisms discovered during investigation.
+  - If account compromise is suspected, reset credentials for the affected `user.id`, review recent access patterns, and apply least-privilege controls to limit further abuse.
+
+- If the activity is determined to be benign:
+  - Document the script purpose, expected execution context, and the specific concatenated strings that explain the detection.
+  - Monitor for deviations from the established baseline (new hosts, new accounts, unexpected file paths, or substantially different reconstructed content).
 
 
 ==== Setup
@@ -92,21 +136,8 @@ PowerShell is a powerful scripting language used for task automation and configu
 *Setup*
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
-
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
-
-Steps to implement the logging policy via registry:
-
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
@@ -145,6 +176,7 @@ from logs-windows.powershell_operational* metadata _id, _version, _index
     _version,
     _index,
     host.name,
+    host.id,
     agent.id,
     user.id
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-string-reordering.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-string-reordering.asciidoc
index c97c090500..9dfbabbdd7 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-string-reordering.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-obfuscation-via-string-reordering.asciidoc
@@ -1,15 +1,15 @@
 [[potential-powershell-obfuscation-via-string-reordering]]
 === Potential PowerShell Obfuscation via String Reordering
 
-Identifies PowerShell scripts that use string reordering and runtime reconstruction techniques as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).
+Detects PowerShell scripts that uses format placeholders like "{0}{1}" with the -f operator or ::Format to reorder strings at runtime. Attackers use format-based reconstruction to hide commands or payload strings and evade static analysis and AMSI.
 
 *Rule type*: esql
 
 *Rule indices*: None
 
-*Severity*: low
+*Severity*: medium
 
-*Risk score*: 21
+*Risk score*: 47
 
 *Runs every*: 5m
 
@@ -28,7 +28,7 @@ Identifies PowerShell scripts that use string reordering and runtime reconstruct
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 11
+*Version*: 12
 
 *Rule authors*: 
 
@@ -40,71 +40,106 @@ Identifies PowerShell scripts that use string reordering and runtime reconstruct
 ==== Investigation guide
 
 
- ## Triage and analysis
+
+*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.
+> 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 Obfuscation via String Reordering*
 
 
-PowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques like string reordering to evade detection. This involves rearranging strings and reconstructing them at runtime, bypassing static analysis and security measures. The detection rule identifies scripts with excessive length and specific patterns, flagging those with multiple occurrences of string format expressions, which are indicative of obfuscation attempts. By filtering out known benign patterns, it reduces false positives, focusing on genuine threats.
+This alert indicates a PowerShell script block used indexed format placeholders (for example, "{0}{1}") with runtime formatting (for example, the `-f` operator or `::Format`) to reorder and reconstruct strings. This technique can hide meaningful strings (commands, URLs, artifact names) from straightforward text inspection and can be used as part of staged execution.
+
+Because the detection requires repeated occurrences of these patterns in a larger script block, triage should focus on (1) execution context (host and user), (2) script origin (file-backed vs. in-memory/interactive), and (3) what strings are being reconstructed and what actions they enable.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
 
 
 *Possible investigation steps*
 
 
-- Review the script block text by examining the powershell.file.script_block_text field to understand the nature of the obfuscation and identify any potentially malicious commands or patterns.
-- Check the file.path and file.name fields to determine the origin and context of the script, which can provide insights into whether the script is part of a legitimate application or a potential threat.
-- Investigate the host.name and user.id fields to identify the affected system and user, which can help in assessing the potential impact and scope of the incident.
-- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and history of the script, which may reveal additional suspicious activities or related scripts.
-- Correlate the alert with other security events or logs from the same host or user to identify any patterns or additional indicators of compromise that may suggest a broader attack campaign.
+- Confirm the execution context and initial scope:
+  - Identify the affected endpoint using `host.name` and `host.id`. Check for other security alerts or suspicious activity on the same host around the alert time.
+  - Identify the account context using `user.name`, `user.domain`, and `user.id`. Prioritize alerts where the user is unexpected for the host role or where the user does not typically run PowerShell.
+  - If `file.path` / `file.directory` / `file.name` are present, capture the script location and assess whether the path and filename are expected for that host and user. If file fields are missing, treat the activity as potentially interactive or in-memory and increase emphasis on correlated telemetry.
+
+- Review the script block content and determine what is being reconstructed:
+  - Start with `Esql.script_block_tmp` to quickly locate where formatting patterns occur, then use `powershell.file.script_block_text` as the authoritative source for analysis and evidence.
+  - Identify how formatting is used:
+    - Placeholder-only or placeholder-heavy format strings that primarily consist of `{n}` tokens.
+    - Out-of-order placeholder indexes (for example, `{3}{0}{2}{1}`) and repeated reordering blocks.
+    - Multiple reconstruction stages where formatted output is subsequently reformatted or concatenated.
+  - Reconstruct key strings by mapping placeholder indexes to the arguments/fragments used in each formatting operation. Record any reconstructed strings that indicate follow-on behavior (remote addresses, filenames, persistence identifiers, or execution flow).
+
+- Use the available scoring and statistics fields to guide prioritization:
+  - Review `Esql.script_block_pattern_count` to understand how heavily the script relies on formatting-based reconstruction. Higher counts generally increase suspicion.
+  - Review `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_length` to differentiate structured, readable scripts from highly variable or packed content.
+  - Treat these values as supporting signals; base the decision primarily on reconstructed strings and correlated activity.
+
+- Reconstruct full script content when split across multiple events:
+  - Pivot on `powershell.file.script_block_id` to gather all fragments for the same script block.
+  - Order fragments using `powershell.sequence` and confirm completeness using `powershell.total` before drawing conclusions.
+
+- Correlate and validate impact using adjacent telemetry available in your environment:
+  - Review other PowerShell script blocks from the same `host.id` and `user.id` to identify staging, deobfuscation, or follow-on execution.
+  - Correlate with endpoint telemetry for the same host and timeframe to understand how PowerShell was started and what occurred next (process ancestry, network activity, file/registry changes, and authentication activity). Use reconstructed strings to focus this correlation.
+
+- Expand the hunt to assess prevalence:
+  - Search for the same or similar content in `powershell.file.script_block_text` (shared fragments, repeated placeholder patterns) across other hosts.
+  - Use `Esql.script_block_pattern_count` and the script block statistics fields to identify other high-similarity or high-complexity scripts that may represent the same technique.
 
 
 *False positive analysis*
 
 
-- Scripts related to the Icinga Framework may trigger false positives due to their use of string formatting. To handle this, ensure that the file name "framework_cache.psm1" is excluded from the detection rule.
-- PowerShell scripts that include specific sentinel patterns, such as "sentinelbreakpoints" or paths like ":::::\windows\sentinel", combined with variables like "$local:Bypassed" or "origPSExecutionPolicyPreference", are known to be benign. These should be excluded to reduce noise.
-- Regularly review and update the exclusion list to include any new benign patterns that are identified over time, ensuring the rule remains effective without generating unnecessary alerts.
-- Consider implementing a whitelist of known safe scripts or script authors to further minimize false positives, especially in environments with frequent legitimate use of complex PowerShell scripts.
+- Legitimate automation can use indexed placeholders to build dynamic output, reports, or templated configuration content. Benign usage is more likely when the resulting strings are human-readable and the script has an expected on-disk origin (`file.path` / `file.name`) and consistent execution over time.
+- Some internally developed frameworks generate PowerShell dynamically and may include repeated formatting patterns. Validate ownership of the script source and whether execution by the identified `user.id` on the identified `host.id` is expected.
+- Localization or templating logic may use indexed placeholders. This is typically associated with readable templates and stable execution patterns rather than multi-stage reconstruction of operational strings.
 
 
 *Response and remediation*
 
 
-- Isolate the affected system from the network to prevent further spread of potentially malicious scripts.
-- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity.
-- Conduct a thorough review of the PowerShell script block text flagged by the alert to understand the intent and potential impact of the obfuscated script.
-- Remove any malicious scripts or files identified during the investigation from the affected system to prevent re-execution.
-- Restore the system from a known good backup if the script has caused significant changes or damage to the system.
-- Update and strengthen endpoint protection measures, ensuring that AMSI and other security tools are fully operational and configured to detect similar obfuscation techniques.
-- 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 malicious or suspicious activity is confirmed:
+  - Contain the affected endpoint identified by `host.name` / `host.id` to prevent further execution and limit lateral movement.
+  - Preserve evidence, including `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and the alert enrichment fields (`Esql.script_block_tmp`, `Esql.script_block_pattern_count`, and script block statistics).
+  - Use reconstructed strings to drive scoping and impact assessment (look for related activity on the same host, and search for the same indicators across other hosts and users).
 
-==== Setup
+- Eradication and recovery:
+  - Identify the execution mechanism and remove it (for example, an unexpected script file, a startup trigger, or other persistence identified during correlation).
+  - Remove or quarantine related artifacts discovered during analysis and validate that similar activity is not occurring on other endpoints.
 
+- If the activity is determined to be benign:
+  - Document the expected script source (`file.path` / `file.name`), the responsible team, and the expected execution context (`host.id`, `user.id`) to support faster triage of future alerts.
+  - Monitor for deviations from the established baseline (new hosts, new users, or materially different reconstructed strings).
 
 
-*Setup*
+==== Setup
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
 
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
+*Setup*
 
-Steps to implement the logging policy via registry:
 
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
@@ -144,6 +179,7 @@ from logs-windows.powershell_operational* metadata _id, _version, _index
     _version,
     _index,
     host.name,
+    host.id,
     agent.id,
     user.id
 
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-process-injection-via-powershell.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-process-injection-via-powershell.asciidoc
index 34b8f98ef4..75a311e914 100644
--- a/docs/detections/prebuilt-rules/rule-details/potential-process-injection-via-powershell.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/potential-process-injection-via-powershell.asciidoc
@@ -1,7 +1,7 @@
 [[potential-process-injection-via-powershell]]
 === Potential Process Injection via PowerShell
 
-Detects the use of Windows API functions that are commonly abused by malware and security tools to load malicious code or inject it into remote processes.
+Detects PowerShell scripts that combines Win32 APIs for allocation/protection or process access (for example, VirtualAlloc/VirtualProtect/OpenProcess/AdjustTokenPrivileges/LoadLibrary/GetProcAddress) with injection or execution APIs (WriteProcessMemory/CreateRemoteThread/NtCreateThreadEx/QueueUserAPC/ResumeThread). Attackers use these API chains to inject code into remote processes and execute payloads in memory for defense evasion.
 
 *Rule type*: query
 
@@ -37,7 +37,7 @@ Detects the use of Windows API functions that are commonly abused by malware and
 * Resources: Investigation Guide
 * Data Source: PowerShell Logs
 
-*Version*: 216
+*Version*: 217
 
 *Rule authors*: 
 
@@ -53,75 +53,94 @@ Detects the use of Windows API functions that are commonly abused by malware and
 *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 Process Injection via PowerShell*
 
 
-PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code.
+This rule Detects PowerShell scripts that references a combination of Win32 APIs commonly used to open a target process, allocate or change memory protections, write data into another process, and execute it via a remote thread or APC. This behavior is frequently associated with process injection and in-memory payload execution on Windows hosts.
+
+
+*Key alert fields to review*
 
-PowerShell also has solid capabilities to make the interaction with the Win32 API in an uncomplicated and reliable way, like the execution of inline C# code, PSReflect, Get-ProcAddress, etc.
 
-Red Team tooling and malware developers take advantage of these capabilities to develop stagers and loaders that inject payloads directly into the memory without touching the disk to circumvent file-based security protections.
+- `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*
 
 
-- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
-- Investigate the script 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.
-- Examine file or network events from the involved PowerShell process for suspicious behavior.
-- Investigate other alerts associated with the user/host during the past 48 hours.
-- Evaluate whether the user needs to use PowerShell to complete tasks.
-- Check if the imported function was executed and which process it targeted.
-- Check if the injected code can be retrieved (hardcoded in the script or on command line logs).
+- Review and preserve the script content:
+  - Inspect `powershell.file.script_block_text` for the full API chain and surrounding logic (function definitions, payload construction, and execution flow).
+  - If the content is split across multiple events, reconstruct it by grouping on `powershell.file.script_block_id`, ordering by `powershell.sequence`, and validating completeness with `powershell.total`. Preserve the reconstructed content for follow-up analysis.
+  - Use `powershell.file.script_block_length` to help gauge whether the script is a small launcher or a larger framework with embedded payloads.
 
+- Identify the injection technique and likely target:
+  - Determine which execution primitive is being used (for example, `CreateRemoteThread`, `NtCreateThreadEx`, `QueueUserAPC`, or thread `SuspendThread`/`ResumeThread` patterns) and whether it suggests immediate or deferred execution.
+  - Look for how the target process is selected (process name strings, PID variables, or process enumeration logic) and capture any referenced process names or IDs for scoping.
+  - Note any privilege manipulation via `OpenProcessToken` and `AdjustTokenPrivileges`, which can indicate attempts to access protected processes.
 
-*False positive analysis*
+- Assess how native APIs are being invoked:
+  - Identify dynamic resolution patterns such as `LoadLibrary*`/`LdrLoadDll` with `GetProcAddress`, which are commonly used to avoid static imports and hinder analysis.
+  - If `GetDelegateForFunctionPointer` is present, review the surrounding text for delegate definitions and indirect invocation logic.
 
+- Validate execution context and script provenance:
+  - Review `user.name`, `user.domain`, and `user.id` for signs of unusual execution (unexpected account type, first-time observation on the host, or activity outside expected administrative workflows).
+  - Review `host.name` and `host.id` to understand the asset impacted and whether the behavior aligns with the host's role in your environment.
+  - If `file.path`, `file.directory`, or `file.name` are populated, assess whether the script originated from a controlled location and naming convention, or from a user-writable or temporary location.
 
-- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+- Scope related PowerShell activity:
+  - On the same `host.id` and `user.id`, review additional script block events near `@timestamp` to identify staging actions that commonly bracket injection attempts (download, decode/decrypt, reflective loading, or cleanup).
+  - Search for repeated use of distinctive substrings from `powershell.file.script_block_text` across other hosts or users to determine prevalence and potential reuse.
 
+- Correlate with adjacent host telemetry (if available in your environment):
+  - Pivot from `host.name` and `@timestamp` to process activity to identify the PowerShell host process, its parent process, and any processes that may have been targeted for injection.
+  - Review network activity from the same `host.name` around the alert time for potential payload retrieval, command-and-control, or lateral movement.
+  - Review file activity related to `file.path` (when present) and for any new or modified scripts or binaries referenced by the script block.
 
-*Related rules*
+- Make a disposition:
+  - Treat as higher risk when the script combines process access (`OpenProcess`), memory modification (`VirtualAlloc*`/`VirtualProtect`), and execution (`CreateRemoteThread`/`NtCreateThreadEx`/`QueueUserAPC`), especially when coupled with privilege adjustment or dynamic API resolution.
+  - Treat as lower risk only when there is a clear, documented administrative or testing justification tied to the same `user.id`, `host.id`, and script origin.
 
 
-- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe
+*False positive analysis*
 
 
-*Response and remediation*
+- Legitimate PowerShell can use Win32 API interop for diagnostics, automation, or compatibility work; however, the combination of remote memory operations and remote execution APIs is uncommon in routine administration.
+- Developer tooling or monitoring frameworks may load libraries or resolve symbols dynamically; validate that the script content aligns with expected tool behavior and that the script origin (`file.path`/`file.name`) is consistent and controlled.
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Isolate the involved hosts to prevent further post-compromise behavior.
-- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
-- 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).
+*Response and remediation*
 
 
-==== Setup
+- If the activity is confirmed or strongly suspected malicious:
+  - Contain the affected host to prevent follow-on actions and lateral movement.
+  - Preserve evidence by retaining the reconstructed `powershell.file.script_block_text` (and associated `powershell.file.script_block_id`) and recording the alert context (`user.*`, `host.*`, and `file.*` where present).
+  - Identify the intended injection target from the script content and investigate that process and its recent activity for signs of compromise or anomalous behavior.
+  - Review the associated user account activity for additional suspicious behavior on the same host and other hosts, and take appropriate account actions if compromise is suspected.
+  - Hunt for the same script patterns across the environment using stable substrings from `powershell.file.script_block_text` and common `file.path`/`file.name` values, and remediate any additional impacted systems.
 
+- If the activity is verified as benign:
+  - Document the script purpose, owner, expected execution context (hosts and accounts), and expected script origin (`file.path`/`file.name`).
+  - Consider controlled rule tuning using stable, high-confidence identifiers from the verified benign workflow to reduce repeat alerts while maintaining coverage for new or unauthorized variants.
 
 
-*Setup*
+==== Setup
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
 
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
+*Setup*
 
-Steps to implement the logging policy via registry:
 
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
diff --git a/docs/detections/prebuilt-rules/rule-details/potential-timestomp-in-executable-files.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-timestomp-in-executable-files.asciidoc
new file mode 100644
index 0000000000..e4b7593459
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/potential-timestomp-in-executable-files.asciidoc
@@ -0,0 +1,166 @@
+[[potential-timestomp-in-executable-files]]
+=== Potential Timestomp in Executable Files
+
+Identifies the modification of a file creation time for executable files in sensitive system directories. Adversaries may modify file time attributes to blend malicious executables with legitimate system files. Timestomping is a technique that modifies the timestamps of a file often to mimic files that are in trusted directories.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-windows.sysmon_operational-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: None
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Defense Evasion
+* Data Source: Sysmon
+* Resources: Investigation Guide
+
+*Version*: 110
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*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 Timestomp in Executable Files*
+
+
+This alert indicates that a process modified the creation timestamp of a file with an executable extension in a sensitive Windows directory or a common persistence location. Timestomping can be used to make recently created or modified files appear older and blend in with legitimate system content.
+
+
+*Possible investigation steps*
+
+- Establish scope and validate context:
+  - Identify the affected endpoint using `host.name` and `host.id`, and determine whether similar alerts or related file-timestamp changes are occurring on the same host.
+  - Review `user.name`, `user.domain`, and `user.id` to understand whether the account typically performs administrative or software management activities on this endpoint.
+  - Use `@timestamp` to bound a focused time window for pivots (for example, shortly before and after the change).
+
+- Assess the timestamp change behavior:
+  - Compare `winlog.event_data.PreviousCreationUtcTime` to `winlog.event_data.CreationUtcTime` and note whether the timestamp was backdated, forward-dated, or aligned to an apparent baseline.
+  - Identify whether multiple files were modified in the same window by searching for additional events on the same `host.id` and `process.entity_id`.
+
+- Evaluate the target file:
+  - Review `file.path`, `file.directory`, `file.name`, and `file.extension` to determine whether the target is expected in that location and whether the name resembles a legitimate component for the directory.
+  - If the file is in a Startup location, treat it as a potential persistence artifact and prioritize determining whether it later executed on the host.
+  - If the file is in a system directory, assess whether the host role and recent maintenance activity could reasonably explain changes to that specific file.
+
+- Investigate the process responsible for the change:
+  - Review `process.executable` and `process.name` for signs of an unusual execution location, unexpected binary name, or a process that does not normally manage files in the target directory.
+  - Pivot using `process.entity_id` (or `process.pid` within a narrow time range) to reconstruct process ancestry and command context using your available process telemetry.
+  - Look for additional activity by the same process in the same time window, such as other file modifications involving the same `file.path` or other executable files in similar directories.
+
+- Check for follow-on execution and related activity:
+  - Search for subsequent activity on the same `host.id` where `process.executable` matches the alerted `file.path`, which can indicate the modified file was executed after timestomping.
+  - If the target is a shortcut (`file.extension` such as `lnk`), look for later execution on the host that aligns with user logon activity for `user.id` and the alert timeline.
+  - Identify whether the same `file.name` and `file.path` appear on other endpoints, which may indicate propagation, a shared deployment mechanism, or a broader intrusion set.
+
+
+*False positive analysis*
+
+- Enterprise software deployment, patching, and self-update mechanisms can rewrite binaries and adjust file metadata as part of normal operations.
+- Backup, restore, profile reset, and file synchronization workflows can preserve or reapply timestamps when placing executables into directories.
+- Administrative troubleshooting or recovery activities (for example, repairing installations or restoring components) may result in unexpected timestamp changes for legitimate files.
+
+
+*Response and remediation*
+
+- If the activity is unexpected or suspicious:
+  - Contain the host to limit further tampering and reduce the risk of execution or persistence.
+  - Preserve evidence for the alert by capturing the values of `file.path`, `process.executable`, `process.entity_id`, `user.id`, and the before/after timestamps, and collect related events on the same `host.id` in the surrounding window.
+  - Determine whether the affected file executed after the change by correlating activity on the same `host.id` and comparing `process.executable` to the alerted `file.path`.
+  - Acquire and analyze the target file and the modifying process binary using your standard tooling to assess reputation, integrity, and suspected origin.
+  - Remove or quarantine malicious files and remediate unauthorized persistence, especially for items placed in Startup locations.
+  - Scope across the environment for the same `file.path`, `file.name`, and `process.executable`, and apply containment actions to additional affected hosts as needed.
+  - If compromise is suspected, review access associated with `user.id` and follow incident response procedures for account containment and recovery.
+
+- If the activity is confirmed benign:
+  - Document the legitimate software or workflow responsible for the timestamp change, including the expected `process.executable` and target paths, to support consistent triage and future tuning.
+
+
+==== Setup
+
+
+
+*Setup*
+
+
+Sysmon must be installed and configured to generate the events used by this rule (Event ID 2).
+Setup instructions: https://ela.st/sysmon-event-2-setup
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+file where host.os.type == "windows" and
+  event.provider == "Microsoft-Windows-Sysmon" and event.code == "2" and
+  file.extension : (
+    "exe", "dll", "sys", "msi", "scr", "pif", "lnk"
+  ) and
+  file.path : (
+    "?:\\Windows\\System32\\*",
+    "?:\\Windows\\SysWOW64\\*",
+    "?:\\ProgramData\\*",
+    "?:\\Users\\Public\\*",
+    "?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*",
+    "?:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*"
+  ) and
+  not process.executable : (
+    "?:\\Program Files\\*",
+    "?:\\Program Files (x86)\\*",
+    "?:\\Windows\\system32\\cleanmgr.exe",
+    "?:\\Windows\\system32\\msiexec.exe",
+    "?:\\Windows\\syswow64\\msiexec.exe",
+    "?:\\Windows\\system32\\svchost.exe",
+    "?:\\Windows\\System32\\Robocopy.exe",
+    "?:\\Windows\\SysWOW64\\Robocopy.exe"
+  ) and
+  not (process.executable : "?:\\Windows\\System32\\spoolsv.exe" and file.path : "?:\\Windows\\System32\\spool\\*") and
+  not user.name : ("SYSTEM", "Local Service", "Network Service")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Defense Evasion
+** ID: TA0005
+** Reference URL: https://attack.mitre.org/tactics/TA0005/
+* Technique:
+** Name: Indicator Removal
+** ID: T1070
+** Reference URL: https://attack.mitre.org/techniques/T1070/
+* Sub-technique:
+** Name: Timestomp
+** ID: T1070.006
+** Reference URL: https://attack.mitre.org/techniques/T1070/006/
diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-obfuscation-via-negative-index-string-reversal.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-obfuscation-via-negative-index-string-reversal.asciidoc
index a078191184..36924e2f2a 100644
--- a/docs/detections/prebuilt-rules/rule-details/powershell-obfuscation-via-negative-index-string-reversal.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/powershell-obfuscation-via-negative-index-string-reversal.asciidoc
@@ -1,7 +1,7 @@
 [[powershell-obfuscation-via-negative-index-string-reversal]]
 === PowerShell Obfuscation via Negative Index String Reversal
 
-Identifies PowerShell scripts that use negative index ranges to reverse the contents of a string or array at runtime as a form of obfuscation. This technique avoids direct use of reversal functions by iterating through array elements in reverse order. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).
+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.
 
 *Rule type*: esql
 
@@ -28,7 +28,7 @@ Identifies PowerShell scripts that use negative index ranges to reverse the cont
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 8
+*Version*: 9
 
 *Rule authors*: 
 
@@ -40,49 +40,76 @@ Identifies PowerShell scripts that use negative index ranges to reverse the cont
 ==== Investigation guide
 
 
- ## Triage and analysis
+
+*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.
+> 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 Obfuscation via Negative Index String Reversal*
 
 
-PowerShell, a powerful scripting language, can be exploited by adversaries using obfuscation techniques like negative index string reversal to evade detection. This method manipulates strings or arrays by iterating in reverse, bypassing static analysis tools. The detection rule identifies scripts with obfuscation patterns by analyzing script length and specific indexing patterns, flagging potential threats for further investigation.
+This alert flags PowerShell script block content that uses negative index ranges to reverse strings or arrays and rebuild content at runtime. This pattern can be used to hide command text and reduce readability during review, so the primary goal is to recover the reconstructed content and determine what it does in the observed execution context.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
 
 
 *Possible investigation steps*
 
 
-- Review the `powershell.file.script_block_text` to understand the script's intent and identify any suspicious or malicious behavior.
-- Check the `host.name` and `user.id` fields to determine the affected system and user, assessing if they are high-value targets or have a history of similar alerts.
-- Analyze the `file.path` to identify the location of the script and assess if it is in a common or suspicious directory.
-- Investigate the `powershell.file.script_block_id` and `powershell.sequence` to trace the execution flow and determine if this script is part of a larger, potentially malicious sequence.
-- Correlate the `agent.id` with other logs to see if there are additional related activities or alerts from the same endpoint.
-- Examine the `count` of detected patterns to assess the level of obfuscation and potential threat severity.
+- Review `powershell.file.script_block_text` and locate the reversal logic. Use `Esql.script_block_tmp` to quickly find match positions, then identify:
+  - The variable or array being reversed
+  - The reconstructed output (string, byte array, or command fragment)
+  - The sink where the output is used (for example, passed into a dynamic execution routine, used as a URL, or written to disk)
+- Reconstruct the final value produced by the reversal. Focus on what the script is trying to rebuild (commands, URLs, file paths, registry paths, encoded blobs, or arguments) and record the recovered strings for scoping.
+- If the script block is fragmented, pivot on `powershell.file.script_block_id` and use `powershell.sequence` and `powershell.total` to rebuild the full script in order. Reassess intent based on the complete content rather than a single fragment.
+- Use `Esql.script_block_pattern_count` to prioritize reviews:
+  - Single-use reversal may be utility logic and requires context to judge
+  - Repeated reversal across a long script is more consistent with obfuscation wrappers
+- Use script complexity signals to guide triage:
+  - High `powershell.file.script_block_entropy_bits` and high `powershell.file.script_block_unique_symbols` can indicate encoded or staged content
+  - Compare `powershell.file.script_block_surprisal_stdev` with the script content to determine whether the script mixes readable logic with high-randomness segments
+- Validate execution context with `user.name`, `user.domain`, `user.id`, `host.name`, and `host.id`. Prioritize investigation when the user is unexpected for the host, the host is sensitive, or similar activity is new for that account.
+- Review `file.path`, `file.directory`, and `file.name` (if present) to understand script origin. Treat unknown locations, new or renamed scripts, and ambiguous naming as higher risk, and check for additional script blocks tied to the same path.
+- Scope related activity by searching for additional PowerShell script block events on the same `host.id` and `user.id` around `@timestamp`, and by pivoting on the same `powershell.file.script_block_id`. Look for:
+  - Follow-on script blocks with clearer (deobfuscated) commands
+  - Repeated use of similar reversal segments or reconstructed indicators
+- If other endpoint telemetry is available, correlate activity on the same host and time window to identify what happened next (process launches, network connections, file writes, or other changes) and validate whether outcomes align with the reconstructed content.
 
 
 *False positive analysis*
 
 
-- Scripts containing the keyword "GENESIS-5654" are known false positives and are automatically excluded from triggering alerts. Ensure that any legitimate scripts using this keyword are documented to prevent unnecessary investigations.
-- Legitimate administrative scripts that use negative indexing for valid purposes may trigger false positives. Review these scripts and consider adding them to an exception list if they are frequently flagged but verified as non-malicious.
-- Automated scripts generated by trusted software that use similar obfuscation patterns for performance or compatibility reasons can be excluded by identifying unique identifiers or patterns within these scripts and updating the exclusion criteria accordingly.
-- Regularly update the exclusion list to include new patterns or identifiers from trusted sources as they are identified, ensuring that legitimate activities are not hindered by the detection rule.
-- Collaborate with IT and security teams to maintain a list of known safe scripts and their characteristics, which can be referenced when analyzing potential false positives.
+- Legitimate scripts may reverse arrays or strings for formatting, parsing, or testing. These cases typically remain readable end-to-end and do not rely on multiple layers of reconstruction to produce executable behavior.
+- Developer utilities and automation tooling can include dense string manipulation. Validate whether the observed `file.path` and execution context (`user.name`, `host.name`) align with approved workflows and whether the same script content recurs consistently across expected hosts.
+- If activity is confirmed benign, prefer context-based tuning using stable attributes visible in the alert (for example, consistent `file.path` and recognizable script content patterns) rather than suppressing the technique broadly.
 
 
 *Response and remediation*
 
 
-- Isolate the affected host immediately to prevent further spread of potentially malicious scripts or unauthorized access.
-- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing obfuscation activities.
-- Conduct a thorough review of the PowerShell script block text and related logs to identify any malicious payloads or commands executed.
-- Remove any identified malicious scripts or files from the affected system to prevent re-execution.
-- Reset credentials for any user accounts involved in the alert to mitigate potential unauthorized access.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems are compromised.
-- Update endpoint protection and monitoring tools to enhance detection capabilities for similar obfuscation techniques in the future.
+- If the reconstructed content indicates malicious behavior, isolate the affected host to limit further execution and reduce the risk of lateral movement.
+- Preserve evidence by retaining the full `powershell.file.script_block_text` and all related fragments grouped by `powershell.file.script_block_id`. Capture the reconstructed strings and relevant metadata (`powershell.sequence`, `powershell.total`, `Esql.script_block_pattern_count`) in case notes.
+- Identify and contain the execution source. If an unauthorized on-disk script is referenced by `file.path`, remove or quarantine it and investigate how it was introduced using your standard incident response workflow.
+- Investigate the associated account (`user.id`) for signs of compromise. Apply account controls (credential reset, session invalidation, privilege review) based on your procedures and observed scope.
+- Hunt for additional exposure by pivoting on recovered indicators and on recurrence of the reversal technique across hosts and users. Remediate any additional impacted endpoints identified during scoping.
+- After containment, improve preventative controls appropriate for your environment, such as restricting PowerShell usage to approved users/hosts and enhancing monitoring for obfuscation and dynamic execution patterns.
 
 
 ==== Setup
@@ -92,21 +119,8 @@ PowerShell, a powerful scripting language, can be exploited by adversaries using
 *Setup*
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
-
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
-
-Steps to implement the logging policy via registry:
-
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
@@ -138,6 +152,7 @@ from logs-windows.powershell_operational* metadata _id, _version, _index
     Esql.script_block_length,
     Esql.script_block_tmp,
     powershell.file.*,
+    file.name,
     file.path,
     powershell.sequence,
     powershell.total,
@@ -145,6 +160,7 @@ from logs-windows.powershell_operational* metadata _id, _version, _index
     _version,
     _index,
     host.name,
+    host.id,
     agent.id,
     user.id
 
@@ -154,6 +170,10 @@ from logs-windows.powershell_operational* metadata _id, _version, _index
 // FP Patterns
 | where not powershell.file.script_block_text like "*GENESIS-5654*"
 
+| where file.name not like ("PSFzf.psm1", "Tenable_API_AssetLists_IPv6Seeder.ps1", "Utility.ps1")
+  // ESQL requires this condition, otherwise it only returns matches where file.name exists.
+  or file.name is null
+
 ----------------------------------
 
 *Framework*: MITRE ATT&CK^TM^
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 2da9d767fd..942e09671a 100644
--- a/docs/detections/prebuilt-rules/rule-details/powershell-psreflect-script.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/powershell-psreflect-script.asciidoc
@@ -1,7 +1,7 @@
 [[powershell-psreflect-script]]
 === PowerShell PSReflect Script
 
-Detects the use of PSReflect in PowerShell scripts. Attackers leverage PSReflect as a library that enables PowerShell to access win32 API functions.
+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.
 
 *Rule type*: query
 
@@ -34,7 +34,7 @@ Detects the use of PSReflect in PowerShell scripts. Attackers leverage PSReflect
 * Resources: Investigation Guide
 * Data Source: PowerShell Logs
 
-*Version*: 316
+*Version*: 317
 
 *Rule authors*: 
 
@@ -50,79 +50,86 @@ Detects the use of PSReflect in PowerShell scripts. Attackers leverage PSReflect
 *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*
 
 
-PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code.
+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.
 
-PSReflect is a library that enables PowerShell to access win32 API functions in an uncomplicated way. It also helps to create enums and structs easily—all without touching the disk.
 
-Although this is an interesting project for every developer and admin out there, it is mainly used in the red team and malware tooling for its capabilities.
+*Key alert fields to review*
 
-Detecting the core implementation of PSReflect means detecting most of the tooling that uses Windows API through PowerShell, enabling defenders to discover tools being dropped in the environment.
 
-> **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.
+- `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*
 
 
-- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics. The script content that may be split into multiple script blocks (you can use the field `powershell.file.script_block_id` for filtering).
-- Investigate the script 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.
-- Check for additional PowerShell and command-line logs that indicate that imported functions were run.
-- Investigate other alerts associated with the user/host during the past 48 hours.
-- Evaluate whether the user needs to use PowerShell to complete tasks.
-- Examine the host for derived artifacts that indicate suspicious activities:
-  - Analyze the script 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.
+- 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.
 
+- 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.
 
-*False positive analysis*
+- 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.
 
+- 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`.
 
-- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+- 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.
 
+- 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.
 
-*Related rules*
 
+*False positive analysis*
 
-- PowerShell Suspicious Discovery Related Windows API Functions - 61ac3638-40a3-44b2-855a-985636ca985e
-- PowerShell Keylogging Script - bd2c86a0-8b61-4457-ab38-96943984e889
-- PowerShell Suspicious Script with Audio Capture Capabilities - 2f2f4939-0b34-40c2-a0a3-844eb7889f43
-- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d
-- Suspicious .NET Reflection via PowerShell - e26f042e-c590-4e82-8e05-41e81bd822ad
-- PowerShell Suspicious Payload Encoded and Compressed - 81fe9dc6-a2d7-4192-a2d8-eed98afc766a
-- PowerShell Suspicious Script with Screenshot Capabilities - 959a7353-1129-4aa7-9084-30746b256a70
+
+- 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.
 
 
 *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.
-- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
-- 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 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).
 
 
 ==== Setup
@@ -132,22 +139,8 @@ Detecting the core implementation of PSReflect means detecting most of the tooli
 *Setup*
 
 
-The 'PowerShell Script Block Logging' logging policy must be configured (Enable).
-
-Steps to implement the logging policy with Advanced Audit Configuration:
-
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
-
-Steps to implement the logging policy via registry:
-
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-script-block-logging-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-script-block-logging-disabled.asciidoc
index ca726cf1cc..6eb235ba71 100644
--- a/docs/detections/prebuilt-rules/rule-details/powershell-script-block-logging-disabled.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/powershell-script-block-logging-disabled.asciidoc
@@ -1,7 +1,7 @@
 [[powershell-script-block-logging-disabled]]
 === PowerShell Script Block Logging Disabled
 
-Identifies attempts to disable PowerShell Script Block Logging via registry modification. Attackers may disable this logging to conceal their activities in the host and evade detection.
+Detects registry changes that disable PowerShell Script Block Logging. Attackers may disable this logging to conceal their activities in the host and evade detection.
 
 *Rule type*: eql
 
@@ -43,7 +43,7 @@ Identifies attempts to disable PowerShell Script Block Logging via registry modi
 * Data Source: SentinelOne
 * Data Source: Crowdstrike
 
-*Version*: 314
+*Version*: 315
 
 *Rule authors*: 
 
@@ -59,53 +59,87 @@ Identifies attempts to disable PowerShell Script Block Logging via registry modi
 *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 Script Block Logging Disabled*
 
 
-PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks, making it available in various environments and creating an attractive way for attackers to execute code.
+This alert indicates a registry modification that set `EnableScriptBlockLogging` to a disabled value (`registry.data.strings` of `0` or `0x00000000`). Disabling Script Block Logging reduces visibility into PowerShell execution and is commonly used to evade detection, especially when followed by script-driven activity.
+
+
+*Key alert fields to review*
 
-PowerShell Script Block Logging is a feature of PowerShell that records the content of all script blocks that it processes, giving defenders visibility of PowerShell scripts and sequences of executed commands.
+
+- `process.executable`: The process responsible for modifying the registry value.
+- `registry.value`: The registry value name that was changed (`EnableScriptBlockLogging`).
+- `registry.data.strings`: The new data indicating the setting was disabled.
+- `registry.path`: The full registry path of the modified value.
+- `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.
 
 
 *Possible investigation steps*
 
 
-- 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.
-- Check whether it makes sense for the user to use PowerShell to complete tasks.
-- Investigate if PowerShell scripts were run after logging was disabled.
+- Establish the affected endpoint and time window:
+  - Use `host.name`, `host.id`, and `@timestamp` to identify the impacted endpoint and define a review window (include activity immediately before and after the change).
+  - Prioritize based on endpoint role and criticality (for example, servers and admin workstations).
 
+- Validate the registry change and its scope:
+  - Review `registry.path`, `registry.value`, and `registry.data.strings` to confirm the setting was disabled and to understand where it was applied.
+  - Compare `registry.path` to common policy locations for Script Block Logging (for example, `HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging\EnableScriptBlockLogging`).
+  - Determine whether the change is likely machine-wide or user-scoped based on the hive reflected in `registry.path`, and assess the blast radius accordingly.
+  - Check for repeated changes (toggling) to the same `registry.path` and `registry.value` around the alert time, which can indicate attempted evasion or policy enforcement conflicts.
 
-*False positive analysis*
+- Identify the modifying process and execution context:
+  - Review `process.executable` for legitimacy (expected binary name, expected install path) and whether it typically performs configuration changes.
+  - Pivoting using `process.entity_id`, review `process.command_line` to understand how the value was set and whether the command line suggests interactive administration, scripts, or automation.
+  - Using nearby endpoint process telemetry on the same host, reconstruct the process tree to identify the initiating process (parent) and any immediate follow-on execution that may have benefited from reduced PowerShell logging.
 
+- Assess the user context and authorization:
+  - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to manage logging or policy settings on this endpoint.
+  - If the change is attributed to a service or system context, identify the associated service, scheduled activity, or management workflow that could have performed the modification.
+  - Scope the user across other hosts for similar activity during the same window to identify potential credential misuse.
 
-- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+- Hunt for related activity that may be masked by reduced logging:
+  - Review host activity immediately before the change for suspicious behavior that could explain the need to disable Script Block Logging (initial access, privilege escalation, or tool staging).
+  - Review host activity after the change for suspicious process launches, script interpreter activity, persistence attempts, credential access behavior, or lateral movement indicators.
+  - Review network activity from the host around the change for connections consistent with payload retrieval, remote access, or command and control.
+  - Review other registry changes around the same time that may further impair visibility or weaken defenses.
 
+- Scope and impact assessment across the environment:
+  - Search for other instances where `registry.value` is `EnableScriptBlockLogging` and `registry.data.strings` indicates a disabled state to determine whether this is isolated or widespread.
+  - Pivot on `process.executable` and `user.id` to identify other endpoints where the same process or account modified this setting.
+  - Identify whether the setting was later restored on the same host by looking for subsequent changes to the same `registry.path` and `registry.value`.
 
-*Related rules*
+
+*False positive analysis*
 
 
-- PowerShell Suspicious Discovery Related Windows API Functions - 61ac3638-40a3-44b2-855a-985636ca985e
-- PowerShell Keylogging Script - bd2c86a0-8b61-4457-ab38-96943984e889
-- PowerShell Suspicious Script with Audio Capture Capabilities - 2f2f4939-0b34-40c2-a0a3-844eb7889f43
-- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d
-- Suspicious .NET Reflection via PowerShell - e26f042e-c590-4e82-8e05-41e81bd822ad
-- PowerShell Suspicious Payload Encoded and Compressed - 81fe9dc6-a2d7-4192-a2d8-eed98afc766a
-- PowerShell Suspicious Script with Screenshot Capabilities - 959a7353-1129-4aa7-9084-30746b256a70
+- Authorized policy, baseline, or hardening changes that intentionally modify PowerShell logging settings, supported by change records and consistent execution by expected accounts and tooling.
+- Provisioning or imaging workflows where configuration changes occur during early host lifecycle stages and are consistent across a known deployment batch.
+- Short-lived administrative troubleshooting where the setting is temporarily changed and promptly restored, with supporting documentation.
 
 
 *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.
-- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed.
-- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
-- 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 the change is unexpected or suspicious:
+  - Treat as potential defense evasion and escalate according to incident response procedures.
+  - Contain the endpoint if there are indicators of follow-on malicious activity in the surrounding timeframe.
+  - Preserve evidence related to the change, including `process.executable`, `process.command_line`, user context, and any correlated endpoint telemetry.
+
+- Restore and enforce PowerShell visibility:
+  - Re-enable Script Block Logging using approved administrative processes and verify the setting persists through policy enforcement.
+  - Monitor for repeated attempts to disable Script Block Logging, especially from the same user or originating process.
+
+- Remediate root cause and reduce recurrence:
+  - Identify and remove unauthorized tooling or persistence associated with the modifying process.
+  - Investigate potential account compromise for the associated user and take appropriate actions (credential reset and access review), prioritizing privileged accounts.
+  - Hunt for additional endpoints impacted by the same user or process and remediate as needed.
+  - Apply least-privilege controls to limit who can modify logging-related registry settings and improve alerting for additional defense impairment behaviors observed during the investigation window.
 
 
 ==== Rule query
@@ -120,12 +154,14 @@ registry where host.os.type == "windows" and event.type == "change" and
           "?:\\Windows\\System32\\svchost.exe",
           "?:\\Windows\\System32\\DeviceEnroller.exe",
           "?:\\Windows\\system32\\omadmclient.exe",
+          "?:\\Program Files\\Trend Micro\\Cloud Endpoint\\CloudEndpointService.exe",
           "?:\\Program Files (x86)\\N-able Technologies\\AutomationManagerAgent\\AutomationManager.AgentService.exe",
           
           /* Crowdstrike specific exclusion as it uses NT Object paths */
           "\\Device\\HarddiskVolume*\\Windows\\System32\\svchost.exe",
           "\\Device\\HarddiskVolume*\\Windows\\System32\\DeviceEnroller.exe",
           "\\Device\\HarddiskVolume*\\Windows\\system32\\omadmclient.exe",
+          "\\Device\\HarddiskVolume*\\Program Files\\Trend Micro\\Cloud Endpoint\\CloudEndpointService.exe",
           "\\Device\\HarddiskVolume*\\Program Files (x86)\\N-able Technologies\\AutomationManagerAgent\\AutomationManager.AgentService.exe"
     )
 
diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-archive-compression-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-archive-compression-capabilities.asciidoc
index d456c43979..1e870f5521 100644
--- a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-archive-compression-capabilities.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-archive-compression-capabilities.asciidoc
@@ -1,7 +1,7 @@
 [[powershell-script-with-archive-compression-capabilities]]
 === PowerShell Script with Archive Compression Capabilities
 
-Identifies the use of Cmdlets and methods related to archive compression activities. Adversaries will often compress and encrypt data in preparation for exfiltration.
+Identifies PowerShell script block content that uses archive compression cmdlets or .NET compression classes (for example, Compress-Archive, ZipFile, GZipStream, DeflateStream) to build compressed artifacts. Attackers compress or package data to stage it for collection or exfiltration.
 
 *Rule type*: query
 
@@ -30,8 +30,9 @@ Identifies the use of Cmdlets and methods related to archive compression activit
 * Tactic: Collection
 * Data Source: PowerShell Logs
 * Rule Type: BBR
+* Resources: Investigation Guide
 
-*Version*: 211
+*Version*: 212
 
 *Rule authors*: 
 
@@ -40,28 +41,138 @@ Identifies the use of Cmdlets and methods related to archive compression activit
 *Rule license*: Elastic License v2
 
 
-==== Setup
+==== Investigation guide
 
 
 
-*Setup*
+*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 Script with Archive Compression Capabilities*
+
+
+This alert identifies PowerShell script block content that references archive compression functionality. Matches can be driven by the `Compress-Archive` cmdlet or by .NET compression classes (for example, `IO.Compression.ZipFile`, `IO.Compression.ZipArchive`, `GZipStream`, `DeflateStream`, `BrotliStream`, `ZLibStream`) paired with compression configuration terms (for example, `CompressionLevel`, `CompressionMode`, `ZipArchiveMode`). Compression is common in legitimate automation, but it can also be used to package collected data for staging and potential exfiltration.
+
+Prioritize understanding (1) who ran the script and where, (2) what data was targeted for compression, (3) where the resulting archive or compressed data was staged, and (4) whether there is follow-on activity consistent with collection or transfer.
+
+
+*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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.
+- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
+
+
+*Possible investigation steps*
+
+
+- Establish initial context and priority:
+  - Identify the affected host and user (`host.name`, `host.id`, `user.name`, `user.domain`, `user.id`).
+  - Assess whether the user is expected to run PowerShell that creates archives on this host. Unexpected host-user pairings or rare activity on sensitive systems should be prioritized.
+  - Review the alert time in relation to known operational activity (for example, maintenance windows, support cases, backup or migration tasks).
+
+- Quickly understand what matched:
+  - Review `Esql.script_block_tmp` to locate the matched compression indicators within the script block.
+  - Use `Esql.script_block_pattern_count` to understand whether the script contains repeated compression indicators (often seen in loops or multi-step staging).
+  - Review `powershell.file.script_block_text` to determine whether the activity is `Compress-Archive` usage, .NET compression usage, or both.
+
+- Assess script complexity and likelihood of obfuscation:
+  - Review `powershell.file.script_block_length` to understand whether the script block is small and targeted or large and multi-purpose.
+  - Use `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_unique_symbols` to triage for suspicious encoding/obfuscation:
+    - High entropy with low variability can indicate embedded encoded content.
+    - High variability can indicate a mix of readable logic and opaque data blobs.
+  - If metrics suggest obfuscation, prioritize deeper review and broader scoping for related script blocks from the same host and user.
 
+- Reconstruct full script block content when fragmented:
+  - Pivot on `powershell.file.script_block_id` and collect all fragments for that ID.
+  - Order fragments by `powershell.sequence` and validate completeness using `powershell.total` when present.
+  - Re-review the reconstructed script to understand inputs, outputs, and any follow-on behavior.
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
+- Identify what data is being compressed and where it is staged:
+  - In `powershell.file.script_block_text`, identify source paths, file selection logic (for example, recursion, wildcards, extension filters), and loops that suggest bulk collection vs a single archive operation.
+  - Identify the output archive name and destination directory (if specified). Focus on archives staged in user-writable or temporary directories, newly created staging folders, or remote locations.
+  - Determine whether compression produces an on-disk archive, in-memory compressed data, or both (for example, stream-based compression used with output streams or byte arrays).
 
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
+- Determine script origin and delivery path:
+  - If `file.path`, `file.directory`, or `file.name` are present, assess whether the script origin aligns with expected administrative tooling for the host role.
+  - Review whether the script file appears newly introduced or recently modified relative to the alert time and whether similar scripts exist on other expected hosts.
+  - If file origin fields are absent, treat the activity as potentially interactive or remotely delivered and prioritize identifying the initiating process/source using adjacent endpoint telemetry.
 
-Steps to implement the logging policy via registry:
+- Correlate with adjacent host activity to validate intent and impact (as available):
+  - Process context:
+    - Identify the PowerShell host process associated with the script block and determine the parent process or initiation source near the alert time.
+    - Increase suspicion for unusual launch chains, unexpected automation context, or repeated executions by the same user across multiple hosts.
+  - File activity:
+    - Look for archive creation or modification events consistent with the output identified in the script block.
+    - Review whether the archive is renamed, moved, copied to shared locations, or deleted shortly after creation.
+  - Network activity:
+    - Review outbound connections from the same host following the suspected archive creation window, especially new or rare destinations, large transfers, or repeated connections shortly after staging.
+  - Authentication activity:
+    - Review nearby logon activity for the same user, including new logons to other hosts around the same time, which may indicate coordinated collection and staging.
 
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+- Assess prevalence and scope:
+  - Search for the same `file.path`/`file.name` or distinctive substrings from `powershell.file.script_block_text` across hosts to determine whether the behavior is isolated or widespread.
+  - Identify whether similar compression activity occurs across multiple hosts under the same user context or within a short time window.
+
+
+*False positive analysis*
+
+
+- This activity can be benign when compression is used for routine operations such as packaging logs, diagnostics, backups, software deployment artifacts, or data migration.
+- Benign activity is more likely when:
+  - The script origin (`file.path`/`file.directory`/`file.name`) aligns with approved administrative workflows and expected host roles.
+  - The compressed inputs are narrow and operationally relevant rather than broad user or shared data sets.
+  - Execution is consistent over time (repeatable cadence, consistent hosts, consistent users) and is not followed by suspicious file movement or unusual outbound network activity.
+- Escalate for further review when:
+  - Script block characteristics suggest obfuscation or embedded opaque content (entropy and symbol distribution inconsistent with typical administrative scripts).
+  - Compression targets broad directories, multiple paths, or patterns suggestive of data harvesting.
+  - Archives are staged in unusual locations or closely followed by movement off-host, deletion, or network activity indicative of transfer.
+
+
+*Response and remediation*
+
+
+- If malicious or suspicious activity is confirmed:
+  - Contain the affected host to prevent additional staging or transfer.
+  - Preserve evidence:
+    - Full `powershell.file.script_block_text` (reconstructed using `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total` when needed).
+    - `file.path`/`file.name` for any on-disk script source and the archive output path and filename identified in the script content.
+    - Host and user identifiers (`host.id`, `host.name`, `user.id`, `user.name`, `user.domain`).
+  - Identify potential data exposure:
+    - Determine what directories and file patterns were included and whether the archive was copied or transmitted externally.
+  - Expand scoping:
+    - Hunt for similar script block content and archive staging behavior across endpoints, especially under the same user context.
+  - Remediate root cause:
+    - Remove unauthorized scripts and staged archives.
+    - If credential misuse is suspected, reset impacted credentials and review recent account activity for additional misuse.
+
+- If the activity is verified benign:
+  - Document the legitimate owner, purpose, and expected host/user scope for future triage.
+  - Consider adding operational context (for example, asset criticality, expected administrative accounts, or known script repositories) to reduce repeated investigation while preserving coverage for unexpected archive staging behavior.
+
+
+==== 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
@@ -95,7 +206,8 @@ not file.directory : (
   "C:\Program Files\Microsoft Dependency Agent\plugins\lib" or
   "C:\Program Files\WindowsPowerShell\Modules\icinga-powershell-framework\cache" or
   "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads"
-)
+) and
+not user.id : "S-1-5-18"
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-encryption-decryption-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-encryption-decryption-capabilities.asciidoc
index 9e6d39f57f..98ae3612f1 100644
--- a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-encryption-decryption-capabilities.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-encryption-decryption-capabilities.asciidoc
@@ -1,7 +1,7 @@
 [[powershell-script-with-encryption-decryption-capabilities]]
 === PowerShell Script with Encryption/Decryption Capabilities
 
-Identifies the use of Cmdlets and methods related to encryption/decryption of files in PowerShell scripts, which malware and offensive security tools can abuse to encrypt data or decrypt payloads to bypass security solutions.
+Identifies PowerShell script block content that uses .NET cryptography APIs for file encryption or decryption. Attackers abuse these routines to encrypt data for impact or decrypt staged payloads to evade defenses.
 
 *Rule type*: query
 
@@ -31,7 +31,7 @@ Identifies the use of Cmdlets and methods related to encryption/decryption of fi
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 111
+*Version*: 112
 
 *Rule authors*: 
 
@@ -47,41 +47,91 @@ Identifies the use of Cmdlets and methods related to encryption/decryption of fi
 *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 Script with Encryption/Decryption Capabilities*
 
 
-PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks, making it available for use in various environments, creating an attractive way for attackers to execute code.
+This rule identifies PowerShell script block content that implements cryptographic encryption or decryption using .NET APIs. Matching script blocks commonly include symmetric cryptography classes (for example, AES/Rijndael or the SymmetricAlgorithm base type), key derivation helpers (for example, PasswordDeriveBytes or Rfc2898DeriveBytes), explicit cipher configuration (CipherMode and PaddingMode), and calls that create an encryptor or decryptor.
+
+This behavior can be legitimate (protecting configuration values, packaging content, or controlled encryption for business workflows). It can also indicate malicious activity such as encrypting local data for impact or decrypting staged content to reduce static visibility before follow-on execution. Prioritize determining what data is being transformed, where outputs are written, and whether the user/host/script origin aligns with expected activity.
+
 
-PowerShell offers encryption and decryption functionalities that attackers can abuse for various purposes, such as concealing payloads, C2 communications, and encrypting data as part of ransomware operations.
+*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*
 
 
-- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
-- Investigate the script 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.
-- Examine file or network events from the involved PowerShell process for suspicious behavior.
-- Investigate other alerts associated with the user/host during the past 48 hours.
-- Evaluate whether the user needs to use PowerShell to complete tasks.
+- Review `powershell.file.script_block_text` to understand the cryptographic intent and data flow:
+  - Identify whether the logic is primarily encrypting, decrypting, or doing both.
+  - Note which cryptographic primitives are used (for example, AES/Rijndael, hashing helpers, and key derivation routines) and how keys/IVs are produced (hard-coded values, derived from passwords, generated randomly, or passed in).
+  - Identify the transformed data source and destination:
+    - File-oriented operations: look for path construction, directory traversal patterns, repeated read/write loops, file extension changes, renames, or deletion of originals.
+    - In-memory operations: look for large embedded blobs, byte arrays, stream usage, or logic that converts decrypted content into executable form or writes it to a new artifact.
+  - Extract and preserve any embedded secrets or deterministic derivation parameters (password strings, salts, iteration counts, static IVs, or key material), as these can be critical for impact assessment and recovery.
+
+- Determine whether the alert contains the full implementation or only a fragment:
+  - Use `powershell.file.script_block_length` to gauge whether this is a complete routine (larger blocks) versus a wrapper or function invocation (smaller blocks).
+  - If the script appears incomplete, pivot on `powershell.file.script_block_id` and use `powershell.sequence` / `powershell.total` to retrieve and order all fragments before concluding intent.
+
+- Validate execution context and provenance:
+  - Review `user.name`, `user.domain`, and `user.id` to determine whether this account typically performs encryption/decryption tasks and whether the account scope matches the host role.
+  - Review `host.name` and `host.id` to determine asset criticality and whether similar activity is expected on this system (for example, administrative hosts may have more automation than standard endpoints).
+  - If `file.path` / `file.name` is present, evaluate whether the script origin is expected:
+    - Compare the path and name to approved automation locations and naming conventions.
+    - Treat unexpected paths, user-writable directories, or newly observed script locations as higher risk.
+
+- Scope the activity using alert fields:
+  - On the same host, search for additional script blocks tied to the same `powershell.file.script_block_id` to find related functions or setup code not visible in the initial alert fragment.
+  - Search across hosts for repeating patterns in `powershell.file.script_block_text` and for the same `file.name` to determine whether this is a widely deployed administrative script or isolated activity.
+  - Pivot on `user.id` to identify whether similar script blocks appear on multiple hosts, which may indicate coordinated activity.
+
+- Correlate with adjacent telemetry around `@timestamp` for the same `host.id` and `user.id` (if available in your environment):
+  - Process execution telemetry to identify the PowerShell host process and what initiated it, helping distinguish interactive use from automation or remotely initiated activity.
+  - File activity telemetry to identify bursts of file modifications/creations consistent with bulk encryption/decryption and to determine which directories and file types were affected.
+  - Network telemetry to identify connections that could support retrieval of encrypted content, exchange of key material, or staging/downloading of additional payloads.
+  - Authentication telemetry to identify unusual logons or session types for the user preceding execution.
+
+- Determine disposition and urgency:
+  - Treat as higher severity if the script indicates broad file processing, writes many outputs, modifies user data locations, or includes embedded key material/blobs associated with staged content.
+  - Treat as lower severity if the script is clearly tied to approved operations, originates from a known `file.path`, is executed by expected accounts, and shows consistent recurrence patterns with expected scope.
 
 
 *False positive analysis*
 
 
-- This is a dual-use mechanism, meaning its usage is not inherently malicious. Analysts can dismiss the alert if the script doesn't contain malicious functions or potential for abuse, no other suspicious activity was identified, and there are justifications for the execution.
+- Legitimate PowerShell automation may implement encryption/decryption for secure configuration handling, packaging, data protection, or interoperability with other systems.
+- Benign activity is more likely to have consistent `file.path` / `file.name` values, execute under expected administrative accounts, and recur on appropriate hosts with stable script content.
+- If the script is determined to be benign, document what data it protects, where it is expected to run, which accounts execute it, and what normal recurrence looks like to reduce future triage time.
 
 
 *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.
-- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
-- 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 the activity is suspicious or malicious:
+  - Contain the host to prevent further encryption/decryption activity and reduce the risk of spread or data impact.
+  - Preserve evidence from the alert, including the full `powershell.file.script_block_text` and any reconstructed fragments correlated via `powershell.file.script_block_id`.
+  - If `file.path` is present, collect the referenced script from disk and preserve it for forensic review and scoping.
+  - Identify impacted systems and data:
+    - If file-impact is suspected, prioritize backup protection, incident response escalation, and recovery planning.
+    - If payload staging is suspected, prioritize identifying the decrypted output or follow-on execution artifacts.
+  - Scope and hunt across the environment for related activity using `user.id`, `host.id`, recurring `file.name`, and distinctive fragments of `powershell.file.script_block_text`.
+  - Remediate the associated account and access path: validate legitimacy, reset credentials if compromise is suspected, and apply least-privilege controls where appropriate.
+  - Remove or block the identified script and any related artifacts discovered during analysis, and monitor for recurrence.
+
+- If the activity is confirmed benign:
+  - Record the expected `file.path` / `file.name`, the responsible `user.id`, and normal execution patterns to support consistent future triage and tuning decisions.
 
 
 ==== Rule query
diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-log-clear-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-log-clear-capabilities.asciidoc
index e90485436c..12fbedee6f 100644
--- a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-log-clear-capabilities.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-log-clear-capabilities.asciidoc
@@ -1,7 +1,7 @@
 [[powershell-script-with-log-clear-capabilities]]
 === PowerShell Script with Log Clear Capabilities
 
-Identifies the use of Cmdlets and methods related to Windows event log deletion activities. This is often done by attackers in an attempt to evade detection or destroy forensic evidence on a system.
+Identifies PowerShell script block content that clears Windows event logs using Clear-EventLog, Remove-EventLog, or EventLogSession/EventLog Clear methods. Attackers clear local logs to evade detection and destroy forensic evidence.
 
 *Rule type*: query
 
@@ -33,8 +33,9 @@ Identifies the use of Cmdlets and methods related to Windows event log deletion
 * Tactic: Defense Evasion
 * Data Source: PowerShell Logs
 * Rule Type: BBR
+* Resources: Investigation Guide
 
-*Version*: 210
+*Version*: 211
 
 *Rule authors*: 
 
@@ -43,28 +44,101 @@ Identifies the use of Cmdlets and methods related to Windows event log deletion
 *Rule license*: Elastic License v2
 
 
-==== Setup
+==== Investigation guide
 
 
 
-*Setup*
+*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 Script with Log Clear Capabilities*
+
+
+This alert identifies PowerShell script block content associated with clearing Windows event logs through cmdlets or .NET methods. Clearing local logs can reduce forensic visibility and interrupt security monitoring. Because script block logging records executed content, confirm whether log clearing occurred and identify the broader activity that led to this action.
+
+
+*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*
+
+
+- Analyze `powershell.file.script_block_text` to determine intent and scope:
+  - Identify the clearing technique used (for example, `Clear-EventLog`, `Remove-EventLog`, `EventLogSession.ClearLog`, or `Diagnostics.EventLog.Clear`).
+  - Extract referenced log names/channels and any values that indicate breadth (single log vs multiple logs, loops, or log enumeration).
+  - Note any remote targets, session objects, or hostnames that suggest log clearing on other systems.
+  - If `Remove-EventLog` is used, treat it as higher impact and determine whether it targets built-in logs or custom logs/event sources.
+
+- Reconstruct full content when the script block is split:
+  - Pivot on `powershell.file.script_block_id` to collect all fragments.
+  - Order by `powershell.sequence` and confirm completeness using `powershell.total`.
+  - Use `powershell.file.script_block_length` to identify unusually large content that may include additional actions beyond log clearing.
 
+- Establish execution context and likely origin:
+  - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to perform log maintenance and whether the timing is consistent with approved activity.
+  - Review `host.name` and `host.id` to determine whether the affected system is high value (for example, servers or shared systems) and to scope other alerts on the same host.
+  - If `file.path`, `file.directory`, or `file.name` are present, capture the script location/name and evaluate whether it aligns with known administrative scripts or automation.
+  - If file context is absent, treat the activity as inline or dynamically generated and prioritize identifying how PowerShell was launched (interactive session, scheduled execution, service, or parent process) using adjacent endpoint telemetry.
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
+- Confirm whether logs were actually cleared and identify what was impacted:
+  - Review available Windows logging for records indicating event logs were cleared around `@timestamp`, and document which logs were affected.
+  - Look for gaps in event coverage or abrupt changes in event volume beginning at or shortly after the alert time on the same `host.id`.
 
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
+- Correlate with adjacent activity around `@timestamp` (as available in your environment):
+  - Process execution: identify the PowerShell host process, its parent process, and any related automation that triggered the script.
+  - Authentication and remote access: identify new or unusual logons, session establishment, or privilege changes leading up to the event.
+  - Network activity: review connections consistent with remote administration or lateral movement preceding the log clearing.
+  - Additional PowerShell activity: review other script block events for the same `host.id` and `user.id` before and after the alert to identify precursor actions and follow-on cleanup.
+
+- Scope across the environment:
+  - Search for the same or similar `powershell.file.script_block_text` patterns on other hosts to determine whether this is isolated behavior, shared tooling, or coordinated activity.
+  - Pivot on `user.id` to identify whether the same account performed similar activity on multiple hosts within a short time window.
+
+
+*False positive analysis*
+
+
+- Authorized administrators may clear logs during troubleshooting, controlled testing, or specific maintenance procedures. Validate against change records, maintenance windows, and documented responsibilities for the account in `user.name`.
+- Endpoint provisioning, imaging, or environment resets (for example, labs or short-lived systems) can include log clearing as part of baseline preparation. Validate whether `host.name` is part of an expected rebuild or reset workflow.
+- Operational scripts may clear specific logs to address performance or retention constraints. Benign activity is more likely when `file.path` and `file.name` are from a controlled script repository and no additional suspicious activity is present for the same `user.id` and `host.id`.
+
+
+*Response and remediation*
+
+
+- If activity is unauthorized or suspicious:
+  - Treat this as potential evidence destruction. Preserve remaining forensic data and collect relevant telemetry from the affected host.
+  - Preserve the full script content by capturing all fragments linked by `powershell.file.script_block_id` (use `powershell.sequence` and `powershell.total` for ordering) and retain it with the case record.
+  - Contain the involved account and host according to incident response procedures (for example, restrict access, reset credentials, and isolate the endpoint if required).
+  - Investigate for additional post-compromise activity on the same `host.id` and by the same `user.id`, prioritizing persistence, credential access, and lateral movement around the alert time.
+  - Assess logging resilience: verify critical logs are centrally forwarded and retained, and review access controls that allow event log clearing to ensure they are limited to necessary administrative roles.
+
+- If activity is confirmed benign:
+  - Document the authorized workflow (who, what, where, and when), including expected `host.name`, `user.name`, and any associated script identifiers (`file.name`/`file.path`).
+  - Maintain monitoring for deviations from the approved pattern (unexpected accounts, hosts, timing, or expanded targeting) to reduce noise without losing coverage.
+
+
+==== Setup
+
+
+
+*Setup*
 
-Steps to implement the logging policy via registry:
 
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-password-policy-discovery-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-password-policy-discovery-capabilities.asciidoc
index cb2917bff4..b832458956 100644
--- a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-password-policy-discovery-capabilities.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-password-policy-discovery-capabilities.asciidoc
@@ -1,7 +1,7 @@
 [[powershell-script-with-password-policy-discovery-capabilities]]
 === PowerShell Script with Password Policy Discovery Capabilities
 
-Identifies the use of Cmdlets and methods related to remote execution activities using WinRM. Attackers can abuse WinRM to perform lateral movement using built-in tools.
+Identifies PowerShell script block content that queries Active Directory password policy settings using AD cmdlets, GPP password helpers, or directory searcher attributes. Attackers collect password policy details to tune credential attacks and target weak configurations.
 
 *Rule type*: query
 
@@ -31,8 +31,9 @@ Identifies the use of Cmdlets and methods related to remote execution activities
 * Tactic: Execution
 * Data Source: PowerShell Logs
 * Rule Type: BBR
+* Resources: Investigation Guide
 
-*Version*: 110
+*Version*: 111
 
 *Rule authors*: 
 
@@ -41,28 +42,93 @@ Identifies the use of Cmdlets and methods related to remote execution activities
 *Rule license*: Elastic License v2
 
 
-==== Setup
+==== Investigation guide
 
 
 
-*Setup*
+*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 Script with Password Policy Discovery Capabilities*
+
+
+This alert identifies PowerShell script block content consistent with querying Active Directory password policy settings, including default domain policy requirements, fine-grained password policies, or related directory attributes. Adversaries may use these details to tune password guessing attempts and prioritize targets; administrators may also collect this information for auditing and troubleshooting.
+
+
+*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*
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
+- Review `powershell.file.script_block_text` and identify the discovery method:
+  - AD password policy cmdlets/functions such as `Get-ADDefaultDomainPasswordPolicy`, `Get-ADFineGrainedPasswordPolicy`, `Get-ADUserResultantPasswordPolicy`, `Get-DomainPolicy`, or `Get-PassPol`.
+  - Directory searcher patterns such as `defaultNamingContext`, `ActiveDirectory.DirectoryContext`, or `ActiveDirectory.DirectorySearcher`, and referenced properties/attributes like `.MinLengthPassword`, `.MinPasswordAge`, `.MaxPasswordAge`, `minPwdLength`, `minPwdAge`, `maxPwdAge`, or `msDS-PasswordSettings`.
+  - Helper function use that may attempt to access Group Policy Preference password data (for example, `Get-GPPPassword`).
+- Determine scope and intent from the script content:
+  - Domain-wide enumeration vs querying a specific user/resultant policy.
+  - Enumeration of fine-grained policy objects (`msDS-PasswordSettings`), which can indicate targeted reconnaissance for weaker settings.
+  - Evidence of output collection (formatting, exporting, or writing results) that may support later use.
+- Validate the execution context using `host.name`, `host.id`, `user.name`, `user.domain`, and `user.id`:
+  - Confirm the host is an expected location for administrative or audit activity (for example, an admin workstation or management server).
+  - Assess whether the account context aligns with expected job function and normal host access patterns.
+- Determine script origin and how it was introduced when `file.path`, `file.directory`, or `file.name` are present:
+  - Validate that the script path and name align with approved tooling and standard locations for that host.
+  - Treat execution from user-writable or temporary locations, or from unfamiliar script names, as higher risk and scope for additional suspicious activity.
+- Reconstruct the full script content when it is split across multiple events:
+  - Pivot on `powershell.file.script_block_id` and order by `powershell.sequence` to rebuild the full script (use `powershell.total` to confirm all fragments are present).
+  - Preserve the reconstructed content for case notes and scoping.
+- Correlate with other activity from the same host and account near `@timestamp` (if available in your telemetry):
+  - Review additional PowerShell script block logs for related discovery, credential access attempts, or follow-on execution.
+  - Review process activity to determine how PowerShell was launched (parent process, service/automation context, or interactive use) and whether the launch source is expected for the user/host.
+  - Review network activity consistent with directory queries or access to domain infrastructure that may indicate broader reconnaissance.
+  - Review file activity for evidence of staged scripts/modules or stored output containing policy details.
+  - Review authentication activity for spikes in failed logons, account lockouts, or access to multiple hosts following the discovery.
+- Scope and prevalence:
+  - Look for similar `powershell.file.script_block_text` content executed by the same `user.id` on other hosts to determine whether this is isolated or part of a wider discovery phase.
+  - Look for similar content on the same `host.id` from other users to identify shared tooling, automation, or a compromised host used to launch reconnaissance.
 
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
 
-Steps to implement the logging policy via registry:
+*False positive analysis*
+
+- Authorized identity and directory administration activities (for example, validating password policy requirements during audits, troubleshooting, or policy change reviews).
+- Scheduled reporting or compliance workflows that periodically inventory default and fine-grained password policy settings.
+- Support investigations that query resultant password policy for a specific user as part of account lifecycle management or lockout investigations.
+
+
+*Response and remediation*
+
+- If the activity is unexpected or cannot be tied to an approved administrative task:
+  - Isolate the affected host to prevent further reconnaissance.
+  - Restrict or disable the involved account (`user.id`) and reset credentials according to incident response procedures.
+  - Preserve evidence, including the reconstructed `powershell.file.script_block_text`, associated `powershell.file.script_block_id` fragments, and any referenced scripts (`file.path`, `file.name`).
+  - Hunt for follow-on activity associated with password policy discovery, such as password guessing attempts, credential collection, and additional directory enumeration, using the same `user.id`, `host.id`, and timeframe.
+  - If the script content suggests access to Group Policy Preference password data, treat this as potential credential exposure and rotate any identified credentials and remediate insecure configurations.
+- If the activity is confirmed benign:
+  - Document the approved use case (expected accounts, hosts, and script locations) to speed future triage.
+  - Apply least-privilege controls to limit where and by whom directory policy discovery can be performed while maintaining audit visibility.
+
+
+==== Setup
+
+
+
+*Setup*
+
 
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-token-impersonation-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-token-impersonation-capabilities.asciidoc
index 47b3999d70..ee9588cb92 100644
--- a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-token-impersonation-capabilities.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-token-impersonation-capabilities.asciidoc
@@ -1,7 +1,7 @@
 [[powershell-script-with-token-impersonation-capabilities]]
 === PowerShell Script with Token Impersonation Capabilities
 
-Detects scripts that contain PowerShell functions, structures, or Windows API functions related to token impersonation/theft. Attackers may duplicate then impersonate another user's token to escalate privileges and bypass access controls.
+Detects PowerShell scripts that references token manipulation and impersonation APIs such as CreateProcessWithTokenW, DuplicateToken/ImpersonateLoggedOnUser, or AdjustTokenPrivileges (SeDebugPrivilege). Attackers abuse token impersonation to elevate privileges and bypass access controls.
 
 *Rule type*: query
 
@@ -36,7 +36,7 @@ Detects scripts that contain PowerShell functions, structures, or Windows API fu
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 117
+*Version*: 118
 
 *Rule authors*: 
 
@@ -52,91 +52,106 @@ Detects scripts that contain PowerShell functions, structures, or Windows API fu
 *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 Script with Token Impersonation Capabilities*
 
 
-PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code.
+This rule Detects PowerShell scripts that includes token manipulation and impersonation primitives. Such functionality can be used to execute follow-on actions under a different security context, including elevated or alternate user tokens. The primary investigation goals are to (1) reconstruct and understand the script intent, (2) validate whether the activity is authorized, and (3) identify any resulting privileged execution on the host.
+
+
+*Key alert fields to review*
 
-Adversaries can abuse PowerShell to perform token impersonation, which involves duplicating and impersonating another user's token to escalate privileges and bypass access controls. This rule identifies scripts containing PowerShell functions, structures, or Windows API functions related to token impersonation/theft.
 
-> **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.
+- `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*
 
 
-- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
-- Investigate the script 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 PowerShell process creation and script block logs to identify command line arguments or hardcoded information that can indicate which user was the target of the impersonation.
-- Investigate any abnormal behavior by the subject process (PowerShell), such as network connections, registry or file modifications, and any spawned child processes.
-- Evaluate whether the user needs to use PowerShell to complete tasks.
-- Examine the host for derived artifacts that indicate suspicious activities:
-  - Analyze the script 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.
+- Preserve and reconstruct the full script block content:
+  - Capture `powershell.file.script_block_text` from the alert for analysis and evidence retention.
+  - If the script is logged in multiple fragments, pivot on `powershell.file.script_block_id` and reassemble in order using `powershell.sequence`. Use `powershell.total` to confirm you have the complete set of fragments.
+  - Use `powershell.file.script_block_length` to help gauge completeness and identify unusually large blocks that may contain reusable libraries or modules.
+
+- Identify which token technique is present and what outcome the script is attempting:
+  - Review the reconstructed content for indicators of:
+    - Token duplication and impersonation (for example: `DuplicateToken`, `DuplicateTokenEx`, `SetThreadToken`, `ImpersonateLoggedOnUser`, `NtImpersonateThread`).
+    - Named pipe impersonation (`ImpersonateNamedPipeClient`).
+    - Privilege enablement (`AdjustTokenPrivileges` with `SeDebugPrivilege`).
+    - Token-based process creation (for example: `CreateProcessWithTokenW`, `CreateProcessAsUserW`, `CreateProcessAsUserA`) and related extended startup attributes (`STARTUPINFOEX`, `UpdateProcThreadAttribute`).
+    - Higher-level wrappers commonly associated with token manipulation (for example: `Invoke-TokenManipulation`).
+  - Determine whether the script only defines helper functions/types versus actively invoking them. Content that both defines and calls token APIs within the same execution window is higher risk.
+  - Note any embedded targeting details in the script content (for example: intended user context, target process identifiers, or follow-on payload references), and preserve them for scoping and hunting.
+
+- Validate execution context and expectedness:
+  - Use `host.name` and `host.id` to understand where the activity occurred and whether the system role typically requires privileged PowerShell usage.
+  - Use `user.name`, `user.domain`, and `user.id` to identify the executing account and determine whether this user is expected to run scripts that manipulate access tokens on this host.
+  - Prioritize alerts involving unexpected users, unusual hosts (for example, servers with limited admin access), or repeated/recurrent script blocks indicating persistence or automation.
+
+- Assess script provenance when file context is present:
+  - If `file.path` is populated, determine whether the script came from a known module or an on-disk script file, and whether the location and naming are consistent with approved tooling.
+  - If only `file.directory` and `file.name` are populated, use them to pivot to related script blocks and identify other executions from the same origin.
+  - If the origin appears unfamiliar or user-writable, treat the artifact as suspicious and prioritize collecting the referenced file (and any adjacent module content) for deeper analysis.
+
+- Correlate with surrounding host activity to determine impact:
+  - Pivot on `host.name` and the alert `@timestamp` into adjacent telemetry to identify the PowerShell host process and its initiating parent/source (interactive session, remote management, scheduled execution, or another process).
+  - Look for follow-on activity shortly after the alert time that would indicate successful impersonation or privilege escalation, such as:
+    - New process execution under a different user context than `user.name`.
+    - Privileged actions that require elevated rights (for example, service/task changes, registry modifications, or access to protected resources).
+  - If multiple script blocks occur close together for the same `user.id` and `host.id`, review them as a single activity chain to understand staging, execution, and any post-escalation behavior.
+
+- Scope and hunt for related activity:
+  - Search for additional occurrences of distinctive substrings from `powershell.file.script_block_text` (function names, API names, unique strings) across other users and hosts to identify reuse.
+  - Review whether the same `user.id` is associated with similar script blocks on other `host.id` values, which can indicate broad automation or a compromised account used across systems.
+  - If `file.path` is present, check for the same path and file name across the environment, and identify unexpected hosts where the artifact appears.
 
 
 *False positive analysis*
 
 
-- Regular users should not need to impersonate other users, which makes false positives unlikely. In the case of authorized benign true positives (B-TPs), exceptions can be added.
+- Legitimate administrative automation may use token impersonation to run tasks under alternate credentials, perform controlled privilege transitions, or integrate with management workflows.
+- Development and troubleshooting scripts may contain token API references as reusable helpers without being used for malicious outcomes.
 
+To reduce false positives, focus on provenance and behavior: scripts from known, approved sources and executed by expected administrative identities on expected hosts are more likely benign, while ad-hoc or newly introduced scripts, unfamiliar file origins, and follow-on privileged execution increase concern.
 
-*Related Rules*
 
+*Response and remediation*
 
-- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe
-- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d
 
+- If the activity is unauthorized or suspicious:
+  - Contain the host to prevent further privileged execution and limit lateral movement according to your incident response procedures.
+  - Preserve evidence: the reconstructed script block content, associated `powershell.file.script_block_id` fragments, and any referenced on-disk artifacts from `file.path` (or `file.directory`/`file.name`).
+  - Investigate and remediate outcomes of token impersonation, including processes started under unexpected security contexts and any privileged system changes occurring after the alert time.
 
-*Response and Remediation*
+- Reduce attacker access and recurrence:
+  - Review the executing account identified in `user.id`; reset credentials and invalidate active sessions as appropriate.
+  - Review privileged access assignments for the involved accounts and hosts, and remove unauthorized privilege grants where identified.
+  - If the script enabled sensitive privileges (for example, `SeDebugPrivilege`), assess for additional post-exploitation activity that could leverage enhanced access to protected processes and resources.
 
+- Eradicate and recover:
+  - Remove unauthorized scripts/modules and any secondary artifacts or persistence mechanisms discovered during investigation.
+  - Monitor for repeat executions by hunting for the same token manipulation indicators observed in `powershell.file.script_block_text` across the environment.
+  - Ensure PowerShell script block logging is enabled and retained on systems where PowerShell is permitted so future activity can be reconstructed and scoped effectively.
 
-- 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.
-- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
-- 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
 
 
-The 'PowerShell Script Block Logging' logging policy must be configured (Enable).
 
-Steps to implement the logging policy with Advanced Audit Configuration:
+*Setup*
 
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
 
-Steps to implement the logging policy via registry:
+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
 
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
 
 ==== Rule query
 
diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-windows-defender-tampering-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-windows-defender-tampering-capabilities.asciidoc
index d551f89337..86b4287b2a 100644
--- a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-windows-defender-tampering-capabilities.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-windows-defender-tampering-capabilities.asciidoc
@@ -1,7 +1,7 @@
 [[powershell-script-with-windows-defender-tampering-capabilities]]
 === PowerShell Script with Windows Defender Tampering Capabilities
 
-Identifies PowerShell scripts containing cmdlets and parameters that attackers can abuse to disable Windows Defender features. Attackers can tamper with antivirus to reduce the risk of detection when executing their payloads.
+Detects PowerShell scripts that uses Set-MpPreference with parameters that disable or weaken Defender. Attackers tamper with antivirus settings to reduce detection and enable follow-on payload execution.
 
 *Rule type*: query
 
@@ -10,9 +10,9 @@ Identifies PowerShell scripts containing cmdlets and parameters that attackers c
 * winlogbeat-*
 * logs-windows.powershell*
 
-*Severity*: low
+*Severity*: medium
 
-*Risk score*: 21
+*Risk score*: 47
 
 *Runs every*: 5m
 
@@ -31,7 +31,7 @@ Identifies PowerShell scripts containing cmdlets and parameters that attackers c
 * Data Source: PowerShell Logs
 * Resources: Investigation Guide
 
-*Version*: 107
+*Version*: 108
 
 *Rule authors*: 
 
@@ -43,81 +43,113 @@ Identifies PowerShell scripts containing cmdlets and parameters that attackers c
 ==== Investigation guide
 
 
- ## Triage and analysis
+
+*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.
+> 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 Script with Windows Defender Tampering Capabilities*
 
 
-PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell to disable Windows Defender features, reducing detection risks. The detection rule identifies scripts attempting to modify Defender settings, such as disabling real-time monitoring, by analyzing script block text for specific cmdlets and parameters, while excluding legitimate processes and users.
+This alert highlights PowerShell script block activity that attempts to change Windows Defender preferences in ways that can reduce host protections. These changes are frequently used to create a window for follow-on execution (for example, staging payloads, running tools, or maintaining access with reduced scanning and response).
+
+Triage should focus on (1) what protections were targeted and how, (2) who initiated the change and on which host(s), (3) whether the change took effect and persisted, and (4) whether there is surrounding activity that suggests initial access or follow-on malicious actions.
+
+
+*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*
 
 
-- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
-- Investigate the script 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.
-- Examine the script's execution context, such as the user account, privileges, the role of the system on which it was executed, and any relevant timestamps.
-- Investigate other alerts associated with the user/host during the past 48 hours.
-- Evaluate whether the user needs to use PowerShell to complete tasks.
-- Investigate the origin of the PowerShell script, including its source, download method, and any associated URLs or IP addresses.
-- Use the Get-MpPreference cmdlet to check defender settings for the host. Revert them to the desired state if needed.
-- Check for Files written and executed after the settings were changed.
+- Review the script block content and determine the intended Defender impact:
+  - Inspect `powershell.file.script_block_text` and enumerate each `Set-MpPreference` parameter present.
+  - Capture whether the script is disabling protections (for example, real-time monitoring, script scanning, network file scanning) or changing default threat actions (low/moderate/high) to more permissive outcomes.
+  - Note whether the script changes multiple settings in one execution, repeats the changes, or includes additional logic that suggests deliberate defense impairment rather than a single configuration adjustment.
+
+- Reconstruct full script content when it is split across multiple events:
+  - If `powershell.total` is greater than 1, pivot on `powershell.file.script_block_id` and order fragments by `powershell.sequence` to rebuild the full script.
+  - Ensure you capture all fragments for the same `powershell.file.script_block_id` on the same `host.id` and `user.id` near the alert time; missing fragments can hide follow-on behavior embedded in later chunks.
+
+- Establish scope across hosts and accounts:
+  - Use `@timestamp`, `host.name` / `host.id`, and `user.name` / `user.domain` / `user.id` to determine whether the activity is isolated or distributed.
+  - Look for the same user context making similar changes across multiple hosts in a short time window (suggesting automation or compromised credentials).
+  - Look for multiple distinct user contexts making similar changes on the same host (suggesting lateral movement or multiple access paths).
+
+- Determine the execution and origin context:
+  - If `file.path` or `file.name` is populated, treat the activity as file-backed scripting and capture the location for scoping (where else this script exists, who can write to it, and when it was last introduced).
+  - If the file fields are not populated, treat the activity as potentially interactive or dynamically generated content and expand the search for adjacent script blocks from the same `user.id` on the same `host.id` around `@timestamp` to identify staging, execution flow, or repeated attempts.
+
+- Validate whether Defender settings were actually changed and whether the change persisted:
+  - Using available endpoint security telemetry and configuration auditing, validate whether the targeted preferences were applied on the affected host(s) and whether they remained in the weakened state after the alert time.
+  - Compare against your approved baseline for Defender settings and identify deviations that would materially reduce protection coverage.
+
+- Correlate with adjacent activity to identify initial access and follow-on execution:
+  - Correlate by `host.id` and time to nearby process activity to identify the PowerShell host process and its launching context (interactive use vs scheduled/automated execution vs another process initiating PowerShell).
+  - Review file and network telemetry around the same time for indicators of payload staging or execution (new files written, unusual outbound connections, or repeated attempts after the change).
+  - Check for repeated Defender preference modifications over time on the same host (suggesting persistent tampering) and for other suspicious activity tied to the same `user.id`.
 
 
 *False positive analysis*
 
 
-- Legitimate administrative scripts may trigger the rule if they use Set-MpPreference cmdlets for valid configuration changes. To handle this, review the script's purpose and source, and consider adding exceptions for trusted scripts or users.
-- Automated system management tools might use similar cmdlets for routine maintenance. Identify these tools and exclude their processes or directories from the rule to prevent unnecessary alerts.
-- Security software updates or installations could temporarily disable certain Defender features. Monitor these activities and whitelist known update processes to avoid false positives.
-- PowerShell scripts executed by system administrators for troubleshooting may appear suspicious. Verify the user ID and script content, and exclude known administrator accounts from the rule if they frequently perform such tasks.
+Legitimate activity can modify Defender preferences, but it should be explainable, consistent, and controlled.
+
+- Common benign drivers:
+  - Approved endpoint management or administrative maintenance that adjusts scanning behavior for performance or operational compatibility.
+  - Controlled troubleshooting where settings are temporarily changed and later restored.
+
+- Validation questions to reduce uncertainty:
+  - Does `user.id` map to an expected administrative or management identity for this host population?
+  - Is the activity aligned with known maintenance windows, change records, and documented procedures?
+  - Is `file.path` (when present) consistent with a known, maintained script location, and does the script content align with an approved baseline?
+
+If the activity is benign, document the owner, expected scope (hosts/users), expected recurrence, and the intended steady-state protection posture.
 
 
 *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 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.
-- Reimage the host operating system or restore the compromised files to clean versions.
-- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
-- 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.
-- 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 the activity is unauthorized or suspicious, treat it as a defense evasion attempt with potential follow-on actions.
 
+- Contain and preserve evidence:
+  - Prioritize affected endpoints identified by `host.id` / `host.name` and preserve relevant evidence, including the full reconstructed script from `powershell.file.script_block_id` and `powershell.file.script_block_text`.
+  - Capture the initiating identity context (`user.name`, `user.domain`, `user.id`) for incident scoping and credential review.
 
-==== Setup
+- Restore protections and eliminate the change source:
+  - Restore Windows Defender preferences to the approved baseline using authorized operational processes and verify protections are active.
+  - If `file.path` is present, identify the responsible script and remove or disable unauthorized automation that applies the changes.
+  - If the activity appears user-driven or interactive, investigate how the user obtained execution capability on the host and address the root cause.
 
+- Address potential account compromise and lateral movement:
+  - Review recent activity associated with the initiating account and affected hosts for signs of credential misuse, unexpected access patterns, or follow-on execution.
+  - Apply appropriate credential remediation for impacted identities and review privileged access assignments relevant to the affected endpoints.
 
+- Scope and monitor:
+  - Hunt for the same Defender-tampering parameters within `powershell.file.script_block_text` across other hosts and users to identify additional impacted systems.
+  - Continue monitoring for recurrence of similar preference changes tied to the same `user.id`, as repeated tampering may indicate persistence or an active intrusion.
 
-*Setup*
 
+==== Setup
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
 
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
 
-Steps to implement the logging policy via registry:
+*Setup*
+
 
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-share-enumeration-script.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-share-enumeration-script.asciidoc
index 243e50e504..06ced189fe 100644
--- a/docs/detections/prebuilt-rules/rule-details/powershell-share-enumeration-script.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/powershell-share-enumeration-script.asciidoc
@@ -1,7 +1,7 @@
 [[powershell-share-enumeration-script]]
 === PowerShell Share Enumeration Script
 
-Detects scripts that contain PowerShell functions, structures, or Windows API functions related to windows share enumeration activities. Attackers, mainly ransomware groups, commonly identify and inspect network shares, looking for critical information for encryption and/or exfiltration.
+Detects PowerShell scripts that uses ShareFinder functions (Invoke-ShareFinder/Invoke-ShareFinderThreaded) or Windows share enumeration APIs (shi1_netname/shi1_remark with NetShareEnum/NetApiBufferFree). Attackers use share enumeration to map accessible network shares for collection, lateral movement, or ransomware targeting.
 
 *Rule type*: query
 
@@ -37,7 +37,7 @@ Detects scripts that contain PowerShell functions, structures, or Windows API fu
 * Resources: Investigation Guide
 * Data Source: PowerShell Logs
 
-*Version*: 114
+*Version*: 115
 
 *Rule authors*: 
 
@@ -53,43 +53,98 @@ Detects scripts that contain PowerShell functions, structures, or Windows API fu
 *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 Share Enumeration Script*
 
 
-PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code.
+This alert indicates PowerShell script block content consistent with Windows network share enumeration. The matched text includes ShareFinder functions (for example, `Invoke-ShareFinder` or `Invoke-ShareFinderThreaded`) and/or native share enumeration API references (for example, `NetShareEnum` / `NetApiBufferFree` and `shi1_netname` / `shi1_remark`). Share discovery can be a normal administrative activity, but in attacks it is frequently used to map accessible shares prior to data collection, lateral movement, or impact activity.
+
+
+*Key alert fields to review*
 
-Attackers can use PowerShell to enumerate shares to search for sensitive data like documents, scripts, and other kinds of valuable data for encryption, exfiltration, and lateral movement.
+
+- `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*
 
 
-- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
-- Investigate the script 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.
-- 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.
-- Evaluate whether the user needs to use PowerShell to complete tasks.
-- Check for additional PowerShell and command line logs that indicate that imported functions were run.
-  - Evaluate which information was potentially mapped and accessed by the attacker.
+- Establish context and triage priority:
+  - Use `@timestamp` as the activity anchor and note the executing `user.name` / `user.domain` / `user.id` and affected `host.name` / `host.id`.
+  - Determine whether the account and host are expected to perform share inventory (for example, administrative workstation or management server vs. a standard user endpoint).
+  - Check whether similar share enumeration activity has occurred recently for the same `user.id` or on the same `host.id` to identify repeated scanning or automation.
+
+- Review the script block content and classify the activity:
+  - Inspect `powershell.file.script_block_text` and capture relevant excerpts for the case record (function names, API calls, and any referenced hosts/shares).
+  - Differentiate between a function definition/import and an actual invocation:
+    - Function definition or module load (lower confidence): the text contains the function name as part of a definition or import logic.
+    - Function invocation (higher confidence): the text shows parameters, target lists, or loops that initiate enumeration.
+  - Identify which pattern is present and what it implies about scope:
+    - `Invoke-ShareFinder`: share discovery logic implemented in PowerShell.
+    - `Invoke-ShareFinderThreaded`: broader or faster discovery due to concurrent enumeration.
+    - `NetShareEnum` / `NetApiBufferFree` with `shi1_netname` / `shi1_remark`: direct use of Windows share enumeration APIs and may reflect customized scripting.
+  - Extract scoping and intent details from the text when available:
+    - Target hostnames/IPs, server lists, domain-related identifiers, or UNC paths.
+    - Filters for share names and remarks, or include/exclude logic that focuses discovery on specific systems or shares.
+    - Use of alternate credentials or explicit authentication material embedded in the script (if present).
+    - Any output handling (formatting, writing results to disk, or staging).
+
+- Reconstruct full content when script blocks are split:
+  - Pivot on `powershell.file.script_block_id` to collect all related fragments for the same execution context.
+  - Use `powershell.sequence` and `powershell.total` to order fragments and identify missing pieces (if populated).
+  - Review adjacent script blocks for the same `host.id` and `user.id` near `@timestamp` to capture supporting functions or follow-on actions that may not appear in the triggering fragment.
+
+- Determine whether the activity originated from an on-disk script:
+  - If present, use `file.path` / `file.directory` / `file.name` to identify the script source.
+  - Assess whether the script location and name align with approved administrative tooling. Scripts originating from user-writable or temporary locations are higher risk than centrally managed locations.
+  - If an on-disk script is involved, preserve the file for further analysis and determine whether it appears on additional hosts (pivot on `file.name` where applicable).
+
+- Scope across users and hosts:
+  - Look for additional events containing the same discovery keywords in `powershell.file.script_block_text` to identify other affected endpoints.
+  - Check whether the same `user.id` performed similar activity from multiple `host.id` values in a short period, which can indicate automation or credential misuse.
+  - Identify whether multiple users are performing similar enumeration from the same host, which can indicate a shared jump box or a compromised administrative endpoint.
+
+- Correlate with adjacent telemetry (as available) to confirm intent and detect follow-on behavior:
+  - Process execution telemetry on the same `host.id` around `@timestamp` to determine how PowerShell was launched and whether the initiating process and execution pattern are consistent with expected activity for `user.id`.
+  - Network telemetry around `@timestamp` for access to multiple remote hosts consistent with share enumeration and subsequent SMB activity.
+  - Authentication telemetry for `user.id` around `@timestamp` for unusual access to file servers or multiple servers, especially if the behavior is new for the account.
+  - File activity telemetry (endpoint and/or file server) for unusual access patterns to shared locations following the enumeration (for example, rapid directory traversal or access to sensitive paths).
+
+- Assess risk and impact:
+  - Prioritize investigation if the script targets high-value systems (for example, file servers) or if the discovery appears broad (large target lists, threading, repeated runs).
+  - If the executing `user.id` is privileged or the host is sensitive, treat the alert as higher risk and expand scoping to additional related activity.
 
 
 *False positive analysis*
 
 
-- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+- Legitimate administrative share inventory, auditing, or documentation activity performed by IT or infrastructure teams.
+- Approved operational scripts used for backup validation, migration planning, access reviews, or troubleshooting that enumerate shares across servers.
 
 
 *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.
-- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
-- 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 the activity is unauthorized or suspicious:
+  - Contain the affected endpoint (`host.id`) following your incident response procedures to reduce the risk of further discovery and lateral movement.
+  - Preserve evidence by retaining the complete `powershell.file.script_block_text` content and all fragments linked by `powershell.file.script_block_id` (including ordered reconstruction using `powershell.sequence` / `powershell.total` when available).
+  - Identify and prioritize potential targets referenced in the script content (servers and shares) and coordinate review of access patterns to those resources.
+  - Investigate the executing account (`user.name` / `user.id`) for compromise, including recent authentication activity and unexpected resource access, and take appropriate containment actions (credential reset, privilege review, and session invalidation where applicable).
+  - Expand hunting for additional share enumeration and subsequent access attempts associated with the same `user.id` or originating from the same `host.id`.
+  - If an on-disk script was used (`file.path` / `file.name` present), remove or quarantine the artifact per your response process and check for the same file on other systems.
+
+- If the activity is confirmed benign:
+  - Document the owner, purpose, expected timing, and expected scope (accounts and endpoints) of the share enumeration.
+  - If tuning is required, scope it narrowly to stable identifiers present in the alert (for example, specific `user.id` values and known management `host.id` endpoints) and continue to monitor for deviations from the expected pattern.
+  - Consider establishing a documented allowlist of approved share inventory scripts and their expected execution locations to reduce future triage time.
 
 
 ==== Setup
@@ -99,22 +154,8 @@ Attackers can use PowerShell to enumerate shares to search for sensitive data li
 *Setup*
 
 
-The 'PowerShell Script Block Logging' logging policy must be configured (Enable).
-
-Steps to implement the logging policy with Advanced Audit Configuration:
-
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
-
-Steps to implement the logging policy via registry:
-
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-discovery-related-windows-api-functions.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-discovery-related-windows-api-functions.asciidoc
index 3b3350f648..d24574a3b2 100644
--- a/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-discovery-related-windows-api-functions.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-discovery-related-windows-api-functions.asciidoc
@@ -1,7 +1,7 @@
 [[powershell-suspicious-discovery-related-windows-api-functions]]
 === PowerShell Suspicious Discovery Related Windows API Functions
 
-This rule detects the use of discovery-related Windows API functions in PowerShell Scripts. Attackers can use these functions to perform various situational awareness related activities, like enumerating users, shares, sessions, domain trusts, groups, etc.
+Detects PowerShell scripts that references native Windows API functions commonly used for discovery of users, groups, shares, sessions, domain trusts, and service security. Attackers use these APIs for situational awareness and targeting prior to lateral movement or collection.
 
 *Rule type*: query
 
@@ -36,7 +36,7 @@ This rule detects the use of discovery-related Windows API functions in PowerShe
 * Resources: Investigation Guide
 * Data Source: PowerShell Logs
 
-*Version*: 318
+*Version*: 319
 
 *Rule authors*: 
 
@@ -52,71 +52,101 @@ This rule detects the use of discovery-related Windows API functions in PowerShe
 *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 Suspicious Discovery Related Windows API Functions*
 
 
-PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code.
+This rule flags PowerShell script block content that references Windows API functions commonly used to enumerate users, groups, shares, sessions, domain trusts, and service security. These APIs are frequently accessed via native interop patterns (for example, runtime-compiled type definitions) and can be used to build an inventory of the environment before follow-on activity such as lateral movement or collection.
+
+
+*Key alert fields to review*
+
 
-Attackers can use PowerShell to interact with the Win32 API to bypass command line based detections, using libraries like PSReflect or Get-ProcAddress Cmdlet.
+- `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*
 
 
-- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
-- Investigate the script 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.
-- Examine file or network events from the involved PowerShell process for suspicious behavior.
-- Investigate other alerts associated with the user/host during the past 48 hours.
-- Evaluate whether the user needs to use PowerShell to complete tasks.
-- Check for additional PowerShell and command-line logs that indicate that imported functions were run.
+- Establish context and expected behavior:
+  - Review `host.name`/`host.id` to understand where the activity occurred and whether the host is expected to perform administrative discovery.
+  - Review `user.name`, `user.domain`, and `user.id` to determine whether the executing identity aligns with expected administrative or automation activity for that host.
+  - Use `powershell.file.script_block_length` (when present) as a quick indicator of complexity; unusually large blocks may indicate embedded helper libraries or inline compiled source.
 
+- Review, reconstruct, and characterize the script content:
+  - Inspect `powershell.file.script_block_text` and identify which API function name(s) are present and what discovery objective they imply.
+  - If the script is fragmented, reconstruct it by grouping events on `powershell.file.script_block_id` and ordering by `powershell.sequence` until `powershell.total` is reached. Capture the complete reconstructed content for case notes.
+  - Look for indicators of native API invocation rather than standard cmdlets, such as embedded type definitions, interop attributes, or inline compiled source. This can increase confidence that the script was designed to directly call Windows APIs.
+  - Identify additional capabilities in the same script block (or neighboring fragments) that may indicate follow-on behavior, such as credential access, remote execution logic, output staging, or data access from remote resources.
 
-*False positive analysis*
+- Map API functions to likely discovery intent:
+  - Share and server discovery: `NetShareEnum`, `NetServerGetInfo`, `GetComputerNameEx`.
+  - User and group discovery: `NetUserEnum`, `NetUserGetInfo`, `NetGroupEnum`, `NetGroupGetInfo`, `NetGroupGetUsers`, `NetLocalGroupEnum`, `NetLocalGroupGetMembers`, `GetUserNameEx`, `NetUserModalsGet`.
+  - Session and workstation discovery: `NetSessionEnum`, `NetWkstaUserEnum`, `NetWkstaGetInfo`, `NetWkstaTransportEnum`, `WTSEnumerateSessionsEx`, `WTSQuerySessionInformation`, `LsaGetLogonSessionData`.
+  - Domain trust and site discovery: `DsEnumerateDomainTrusts`, `LsaEnumerateTrustedDomains`, `DsGetSiteName`.
+  - Service permission discovery: `QueryServiceObjectSecurity`.
+  - Job discovery: `NetScheduleJobEnum`.
 
+- Determine discovery scope and targets from the content:
+  - Extract any referenced hostnames, domain names, share names, or service names directly from `powershell.file.script_block_text` (when present) and record them as potential discovery targets.
+  - Look for indications of remote enumeration (for example, multiple target strings, iteration constructs, or repeated API calls with varying targets) versus single-host local discovery.
+  - Prioritize cases that include higher-impact reconnaissance (trust enumeration, session enumeration, logon session data, or service security descriptor queries), especially when the account or host context is unusual.
 
-- Discovery activities themselves are not inherently malicious if occurring in isolation, as long as the script does not contain other capabilities, and there are no other alerts related to the user or host; such alerts can be dismissed. However, analysts should keep in mind that this is not a common way of getting information, making it suspicious.
+- Validate script origin and execution source:
+  - If file context is present, review `file.path`, `file.directory`, and `file.name` to understand whether the script block originated from an on-disk script and whether that location aligns with approved tooling.
+  - Treat scripts originating from unexpected or user-writable locations, or scripts with unusual naming, as higher risk and scope for other related activity on the same host and by the same user.
 
+- Scope for related activity using alert-available pivots:
+  - Search for other script blocks with the same `powershell.file.script_block_id` to ensure no fragments are missed and to identify repeated execution.
+  - Search for additional hits of the same `file.path`/`file.name` across hosts to determine whether the script is broadly deployed or opportunistically introduced.
+  - Identify other occurrences of similar discovery content by pivoting on distinctive substrings within `powershell.file.script_block_text` (such as specific API function names) and the same `user.id` to detect a broader reconnaissance pattern.
 
-*Related rules*
+- Correlate with adjacent telemetry (as available in your environment):
+  - Process context: determine how PowerShell was started and whether the initiation method is consistent with expected activity for `user.name` on `host.name`.
+  - Authentication and remote access: look for logons or remote session activity involving the same `user.name` around the alert time, especially if the script content suggests remote enumeration of servers or sessions.
+  - Network and share access: review evidence of access to discovered targets (servers/shares) following the enumeration to identify potential collection from network shares.
+  - Persistence or privilege escalation follow-on: if service security or job enumeration is present, look for subsequent changes consistent with service or scheduled job manipulation.
 
 
-- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe
+*False positive analysis*
 
 
-*Response and remediation*
+- Benign administrative discovery can occur during routine inventory, troubleshooting, or access validation, especially from dedicated administration hosts and by well-known administrative identities.
+- False positives are more likely when the same script content appears regularly, is consistently associated with the same `file.path`/`file.name`, and is executed by expected `user.name` accounts on expected hosts.
+- Prioritize as suspicious when the activity is new for the environment, originates from an unexpected script location, is executed by a non-administrative or unusual account, or appears across multiple hosts in a short period.
 
 
-- Initiate the incident response process based on the outcome of the triage.
-- Isolate the involved hosts to prevent further post-compromise behavior.
-- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
-- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
-- 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).
+*Response and remediation*
 
 
-==== Setup
+- If the activity is confirmed or strongly suspected malicious:
+  - Contain the affected host and restrict the involved account to prevent further reconnaissance and follow-on actions.
+  - Preserve evidence from the alert, including the fully reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, and any extracted target identifiers, along with `host.id` and `user.id` for reliable correlation.
+  - Scope across the environment for additional executions using pivots on `user.id`, `host.id`, `file.path`/`file.name`, and distinctive content within `powershell.file.script_block_text`.
+  - Review the enumerated targets (hosts, shares, users/groups, trusts, services, sessions) for unauthorized access attempts and follow-on activity such as network share access, credential misuse, or lateral movement.
 
+- If the activity is determined to be legitimate but unexpected:
+  - Identify the script owner and document the business purpose, expected execution scope (hosts/users), and expected cadence.
+  - Reduce future noise by baselining approved scripts and execution contexts, and ensure logging and monitoring coverage remains sufficient to investigate future occurrences.
 
 
-*Setup*
+==== Setup
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
 
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
+*Setup*
 
-Steps to implement the logging policy via registry:
 
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
@@ -155,7 +185,8 @@ event.category:process and host.os.type:windows and
     ("DsGetSiteName" and ("DiscoverWindowsComputerProperties.ps1" and "param($SourceType, $SourceId, $ManagedEntityId, $ComputerIdentity)")) or
     ("# Copyright: (c) 2018, Ansible Project" and "#Requires -Module Ansible.ModuleUtils.AddType" and "#AnsibleRequires -CSharpUtil Ansible.Basic") or
     ("Ansible.Windows.Setup" and "Ansible.Windows.Setup" and "NativeMethods.NetWkstaGetInfo(null, 100, out netBuffer);")
-  )
+  ) and
+  not file.directory: "C:\Program Files (x86)\Automox\WDK\Win32\WinSession"
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-payload-encoded-and-compressed.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-payload-encoded-and-compressed.asciidoc
index 75c72c73ab..a49f834553 100644
--- a/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-payload-encoded-and-compressed.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-payload-encoded-and-compressed.asciidoc
@@ -1,7 +1,7 @@
 [[powershell-suspicious-payload-encoded-and-compressed]]
 === PowerShell Suspicious Payload Encoded and Compressed
 
-Identifies the use of .NET functionality for decompression and base64 decoding combined in PowerShell scripts, which malware and security tools heavily use to deobfuscate payloads and load them directly in memory to bypass defenses.
+Identifies PowerShell script block content that combines Base64 decoding with .NET decompression (Deflate/GZip). Attackers use this pattern to deobfuscate and reconstruct payloads in memory to evade defenses.
 
 *Rule type*: query
 
@@ -31,7 +31,7 @@ Identifies the use of .NET functionality for decompression and base64 decoding c
 * Resources: Investigation Guide
 * Data Source: PowerShell Logs
 
-*Version*: 317
+*Version*: 318
 
 *Rule authors*: 
 
@@ -47,72 +47,99 @@ Identifies the use of .NET functionality for decompression and base64 decoding c
 *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 Suspicious Payload Encoded and Compressed*
 
 
-PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code.
+This rule flags PowerShell script blocks that decode Base64 data and decompress it using .NET Deflate or GZip streams. This pattern is frequently used to conceal secondary script content or payloads until runtime. Focus on reconstructing the full script, recovering the decoded content, and identifying any follow-on execution on the host.
+
+
+*Key alert fields to review*
 
-Attackers can embed compressed and encoded payloads in scripts to load directly into the memory without touching the disk. This strategy can circumvent string and file-based security protections.
 
-> **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.
+- `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.
+- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
+- `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.
+- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.
+- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.
+- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.
+- `powershell.file.script_block_length`: Script block length (size) context.
 
 
 *Possible investigation steps*
 
 
-- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
-- Investigate the script 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.
-- Examine file or network events from the involved PowerShell process for suspicious behavior.
-- Investigate other alerts associated with the user/host during the past 48 hours.
-- Evaluate whether the user needs to use PowerShell to complete tasks.
-- Examine the host for derived artifacts that indicate suspicious activities:
-  - Analyze the script 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.
+- Establish scope and priority using alert context:
+  - Review `host.name` / `host.id` to identify the affected endpoint and its role (workstation, server, jump host).
+  - Review `user.name` / `user.domain` / `user.id` to determine whether the account is expected to run PowerShell on this host and whether it is privileged or widely used.
+  - Check whether this user-host pairing is common or rare in your environment to help prioritize.
 
+- Identify script provenance and how it was introduced:
+  - Review `file.path`, `file.directory`, and `file.name` to determine whether the script block was sourced from an on-disk file.
+  - If `file.path` is present, assess whether the location aligns with normal administrative or automation activity for this host, or whether it appears user-writable, temporary, or otherwise unusual for the account and system role.
+  - If `file.path` is not present or is not informative, treat the content as potentially interactive or dynamically generated and prioritize reconstructing full script content.
 
-*False positive analysis*
+- Interpret the entropy indicators to guide analysis focus:
+  - Use `powershell.file.script_block_length` with `powershell.file.script_block_entropy_bits` to understand whether the alert is driven by a large embedded blob versus smaller obfuscation fragments.
+  - Use `powershell.file.script_block_surprisal_stdev` to distinguish between:
+    - Uniformly random-looking blocks (often consistent with compressed/encrypted data).
+    - Mixed content (often consistent with a readable wrapper that transforms and then executes an embedded payload).
+  - Use `powershell.file.script_block_unique_symbols` to identify whether the content resembles a limited alphabet encoding (for example, Base64-like) versus broader character sets.
+
+- Review and reconstruct script content before making a determination:
+  - Review `powershell.file.script_block_text` to identify:
+    - Large contiguous encoded strings, byte arrays, or character arrays.
+    - Transform routines (decode, decrypt, decompress) that produce secondary content.
+    - Secondary execution patterns where transformed content is immediately evaluated or invoked.
+    - Embedded external references (URLs, domains, IPs) or instructions to write content to disk.
 
+- Rebuild full content when script blocks are split across events:
+  - Pivot on `powershell.file.script_block_id` to collect all related fragments.
+  - Order fragments using `powershell.sequence` and validate completeness using `powershell.total`.
+  - Perform content review on the reconstructed output, not on individual fragments, to avoid missing loader logic or the embedded payload boundaries.
 
-- This activity is unlikely to happen legitimately outside engineering or IT business units. As long as the analyst did not identify malware or suspicious activity related to the user or host, this alert can be dismissed.
+- Extract indicators and correlate with adjacent telemetry to confirm impact:
+  - From `powershell.file.script_block_text` (and any safely decoded or decompressed content), extract indicators such as domains, URLs, IPs, file names/paths, and distinctive strings.
+  - Correlate on the same `host.id` and approximate timeframe with available endpoint telemetry to identify the PowerShell host process and its launch source (parent process or initiating mechanism). Use that context to assess whether execution is user-initiated, automation-driven, or suspicious.
+  - Correlate on the same `host.id` and timeframe with available network, file, registry, and authentication telemetry to identify follow-on activity consistent with script execution (downloads, file writes, persistence changes, or unusual sign-ins).
 
+- Expand scope to detect related activity:
+  - Search for additional high-entropy script blocks on the same `host.id` and `user.id` before and after the alert.
+  - Identify other hosts where the same `file.name` / `file.path` appears with similar suspicious content characteristics.
+  - Look for repeated substrings or structural similarities in `powershell.file.script_block_text` across different alerts to identify shared tooling or campaigns.
 
-*Related rules*
+
+*False positive analysis*
 
 
-- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe
-- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d
-- Suspicious .NET Reflection via PowerShell - e26f042e-c590-4e82-8e05-41e81bd822ad
+- Benign activity can produce high-entropy script blocks when scripts embed packaged resources or data blobs (for example, installers, large configuration payloads, certificates, or compressed content used by administrative tooling).
+- Indicators that support a benign determination:
+  - Consistent `file.path` / `file.name` associated with a known internal automation package or vendor tool across many hosts.
+  - Stable and expected `user.name` / `user.id` usage (for example, dedicated automation accounts) with predictable host targeting.
+  - Repeated, consistent script structure over time where decoding or decompression results in recognizable administrative logic rather than staging or secondary execution.
+- If the alert is verified benign:
+  - Document the owning team/tool, expected hosts, and typical execution cadence.
+  - Suppress recurring noise by scoping on stable attributes available in the alert (for example, `user.id`, `host.id`, and `file.path`) while preserving visibility for new or unusual sources.
 
 
 *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.
-- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
-- 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 malicious or suspicious activity is confirmed:
+  - Contain the affected host to limit further execution and lateral movement.
+  - Preserve evidence from the alert, including `powershell.file.script_block_text`, reconstructed content (using `powershell.file.script_block_id` / `powershell.sequence` / `powershell.total`), and associated context (`user.*`, `host.*`, `file.*`, and entropy metrics).
+  - Use extracted indicators from the script content to hunt for related activity across the environment and to identify additional affected hosts or accounts.
+  - Remediate any identified persistence or staging artifacts associated with the activity and remove malicious content from affected systems.
+  - If account compromise is suspected, reset credentials for `user.id` / `user.name` and review access paths and recent authentication activity for that account.
+
+- If benign activity is confirmed:
+  - Record the business justification and expected behavior for the script source, including the relevant `file.path` (when present) and the associated `user.id`.
+  - Monitor for deviations from the established benign baseline, such as new script sources, new hosts, or materially different `powershell.file.script_block_text` structure or entropy characteristics.
 
 
 ==== Setup
@@ -122,21 +149,10 @@ Attackers can embed compressed and encoded payloads in scripts to load directly
 *Setup*
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
-
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
-
-Steps to implement the logging policy via registry:
+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
 
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+This rule uses the following fields that require the Windows Integration v3.3.0 and up: `powershell.file.script_block_entropy_bits`.
 
 
 ==== Rule query
@@ -145,6 +161,7 @@ reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
 [source, js]
 ----------------------------------
 event.category:process and host.os.type:windows and
+  powershell.file.script_block_entropy_bits >= 4.5 and
   powershell.file.script_block_text : (
     (
       "System.IO.Compression.DeflateStream" or
diff --git a/docs/detections/prebuilt-rules/rule-details/program-files-directory-masquerading.asciidoc b/docs/detections/prebuilt-rules/rule-details/program-files-directory-masquerading.asciidoc
index 5d3dae815b..9e75f3465d 100644
--- a/docs/detections/prebuilt-rules/rule-details/program-files-directory-masquerading.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/program-files-directory-masquerading.asciidoc
@@ -44,7 +44,7 @@ Identifies execution from a directory masquerading as the Windows Program Files
 * Data Source: Crowdstrike
 * Resources: Investigation Guide
 
-*Version*: 318
+*Version*: 319
 
 *Rule authors*: 
 
@@ -109,8 +109,8 @@ The Program Files directories in Windows are trusted locations for legitimate so
 ----------------------------------
 process where host.os.type == "windows" and event.type == "start" and
   process.executable : (
-    "C:\\*Program*Files*\\*.exe",
-    "\\Device\\HarddiskVolume*\\*Program*Files*\\*.exe"
+    "C:\\*Program Files*\\*.exe",
+    "\\Device\\HarddiskVolume*\\*Program Files*\\*.exe"
   ) and
   not process.executable : (
         "?:\\Program Files\\*.exe",
@@ -119,20 +119,14 @@ process where host.os.type == "windows" and event.type == "start" and
         "?:\\ProgramData\\*.exe",
         "?:\\Windows\\Downloaded Program Files\\*.exe",
         "?:\\Windows\\Temp\\.opera\\????????????\\CProgram?FilesOpera*\\*.exe",
-        "?:\\Windows\\Temp\\.opera\\????????????\\CProgram?Files?(x86)Opera*\\*.exe"
-  ) and
-  not (
-    /* Crowdstrike specific exclusion as it uses NT Object paths */
-    event.dataset == "crowdstrike.fdr" and
-      process.executable : (
+        "?:\\Windows\\Temp\\.opera\\????????????\\CProgram?Files?(x86)Opera*\\*.exe",
+
+        /* NT Object Paths */
         "\\Device\\HarddiskVolume*\\Program Files\\*.exe",
         "\\Device\\HarddiskVolume*\\Program Files (x86)\\*.exe",
         "\\Device\\HarddiskVolume*\\Users\\*.exe",
         "\\Device\\HarddiskVolume*\\ProgramData\\*.exe",
-        "\\Device\\HarddiskVolume*\\Windows\\Downloaded Program Files\\*.exe",
-        "\\Device\\HarddiskVolume*\\Windows\\Temp\\.opera\\????????????\\CProgram?FilesOpera*\\*.exe",
-        "\\Device\\HarddiskVolume*\\Windows\\Temp\\.opera\\????????????\\CProgram?Files?(x86)Opera*\\*.exe"
-      )
+        "\\Device\\HarddiskVolume*\\Windows\\Downloaded Program Files\\*.exe"
   )
 
 ----------------------------------
diff --git a/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-connections-made-from-a-source-ip.asciidoc b/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-connections-made-from-a-source-ip.asciidoc
index 6374673a54..9871383fc5 100644
--- a/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-connections-made-from-a-source-ip.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-connections-made-from-a-source-ip.asciidoc
@@ -32,7 +32,7 @@ A machine learning job has detected a high count of destination IPs establishing
 * Tactic: Lateral Movement
 * Resources: Investigation Guide
 
-*Version*: 7
+*Version*: 8
 
 *Rule authors*: 
 
@@ -97,6 +97,12 @@ Remote Desktop Protocol (RDP) is a common tool for remote management, but advers
 *Setup*
 
 
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
 The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-connections-made-to-a-destination-ip.asciidoc b/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-connections-made-to-a-destination-ip.asciidoc
index 3d59610a00..c083cd33cf 100644
--- a/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-connections-made-to-a-destination-ip.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-connections-made-to-a-destination-ip.asciidoc
@@ -32,7 +32,7 @@ A machine learning job has detected a high count of source IPs establishing an R
 * Tactic: Lateral Movement
 * Resources: Investigation Guide
 
-*Version*: 7
+*Version*: 8
 
 *Rule authors*: 
 
@@ -96,6 +96,12 @@ Remote Desktop Protocol (RDP) is crucial for remote management and troubleshooti
 *Setup*
 
 
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
 The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-processes-in-an-rdp-session.asciidoc b/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-processes-in-an-rdp-session.asciidoc
index 51f0aa6080..8876e03a47 100644
--- a/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-processes-in-an-rdp-session.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-processes-in-an-rdp-session.asciidoc
@@ -32,7 +32,7 @@ A machine learning job has detected unusually high number of processes started i
 * Tactic: Lateral Movement
 * Resources: Investigation Guide
 
-*Version*: 7
+*Version*: 8
 
 *Rule authors*: 
 
@@ -96,6 +96,12 @@ Remote Desktop Protocol (RDP) allows users to connect to other computers over a
 *Setup*
 
 
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
 The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/spike-in-remote-file-transfers.asciidoc b/docs/detections/prebuilt-rules/rule-details/spike-in-remote-file-transfers.asciidoc
index ef037a690f..4f71039ec6 100644
--- a/docs/detections/prebuilt-rules/rule-details/spike-in-remote-file-transfers.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/spike-in-remote-file-transfers.asciidoc
@@ -32,7 +32,7 @@ A machine learning job has detected an abnormal volume of remote files shared on
 * Tactic: Lateral Movement
 * Resources: Investigation Guide
 
-*Version*: 7
+*Version*: 8
 
 *Rule authors*: 
 
@@ -97,6 +97,12 @@ Remote file transfer technologies facilitate data sharing across networks, essen
 *Setup*
 
 
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
 The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/suspected-lateral-movement-from-compromised-host.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspected-lateral-movement-from-compromised-host.asciidoc
index ba272a8be6..b9226a5b46 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspected-lateral-movement-from-compromised-host.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspected-lateral-movement-from-compromised-host.asciidoc
@@ -25,7 +25,7 @@ Detects potential lateral movement or post-compromise activity by correlating al
 * Rule Type: Higher-Order Rule
 * Resources: Investigation Guide
 
-*Version*: 3
+*Version*: 4
 
 *Rule authors*: 
 
@@ -80,6 +80,20 @@ The detection rule uses alert data to determine when multiple alerts from differ
 - Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
 - Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.
 
+==== Setup
+
+
+
+*Setup*
+
+
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
+
 ==== Rule query
 
 
@@ -90,7 +104,9 @@ from .alerts-security.*
 // any alerts excluding deprecated, low severity and threat_match rules
 | where kibana.alert.rule.name is not null and kibana.alert.risk_score > 21 and
         kibana.alert.rule.type != "threat_match" and
-        not kibana.alert.rule.name like "Deprecated - *"
+        not kibana.alert.rule.name like "Deprecated - *" and
+        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) and
+        not kibana.alert.rule.name in ("Abnormally Large DNS Response", "Web Application Suspicious Activity: No User Agent")
 
 // alerts with existing source.ip or host.ip
 | eval alert_source_ip = CASE(source.ip is not null, source.ip, null),
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-command-prompt-network-connection.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-command-prompt-network-connection.asciidoc
new file mode 100644
index 0000000000..0e82336d2a
--- /dev/null
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-command-prompt-network-connection.asciidoc
@@ -0,0 +1,179 @@
+[[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.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* winlogbeat-*
+* logs-endpoint.events.process-*
+* logs-endpoint.events.network-*
+* logs-windows.sysmon_operational-*
+* logs-sentinel_one_cloud_funnel.*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Execution
+* Resources: Investigation Guide
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: SentinelOne
+
+*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 Command Prompt Network Connection*
+
+
+This alert identifies a Windows `cmd.exe` process start event that is quickly followed by a network connection from the same `cmd.exe` instance (`process.entity_id`). The command line indicates scripted execution (batch files), references to remote resources (URL-like strings), or execution launched by a Microsoft Office application. This pattern can be used to download payloads, stage execution, or establish command and control.
+
+
+*Triage and analysis steps*
+
+
+- Confirm the matched sequence and keep analysis tied to the correct process instance:
+  - Use the `Investigate in timeline` button in the Alerts table or pivot on `process.entity_id` to review both the process start event and the associated network event(s).
+  - Example KQL pivots:
+    - `process.entity_id:"<process_entity_id>" and event.category:process`
+    - `process.entity_id:"<process_entity_id>" and event.category:network`
+
+- Determine why `cmd.exe` matched and assess intent:
+  - Review `process.args` to confirm the interpreter switch (`/c` to execute and exit, `/k` to remain open).
+  - Identify which match condition applies:
+    - Batch script: `process.args` includes a `.bat` or `.cmd` reference.
+    - Remote resource: `process.command_line` contains `http://`, `https://`, or `ftp://`.
+    - Office parent: `process.parent.name` is one of `winword.exe`, `excel.exe`, `powerpnt.exe`, `outlook.exe`, `msaccess.exe`, or `mspub.exe`.
+  - Look for staging or obfuscation patterns in `process.command_line` (for example: `&`/`&&`/`||`, pipes `|`, redirection `>`/`>>`, escaping `^`, environment variables, or long encoded strings).
+
+- Validate the execution context and launch vector:
+  - Review `user.*` fields to determine who ran the command and whether it is expected for the host role.
+  - Review `process.parent.name` (and `process.parent.command_line` if available) to understand the initial trigger:
+    - Office parent: prioritize identifying the initiating document or message and any user interaction around `@timestamp`.
+    - Management tooling or installer parent: validate change control and whether the command line and destination are consistent with that software.
+  - If a batch script is referenced, locate the script on the host (if telemetry allows) and capture path and hash (`file.path`, `file.hash.sha256`) for scoping.
+
+- Analyze the outbound destination:
+  - Review `destination.ip` and `destination.port` for expectedness (business relationship, known vendor, or organization-owned public IP space).
+  - Note: the rule excludes common private and reserved address ranges, but it can still alert on connections to legitimate public services.
+  - Pivot on `destination.ip` to identify other hosts contacting the same destination near `@timestamp`:
+    - `destination.ip:"<destination_ip>" and event.category:network`
+  - Check whether the same `process.entity_id` generated repeated connections (potential beaconing) versus a single connection (one-time retrieval).
+
+- Reconstruct follow-on activity and potential impact:
+  - Identify child processes spawned by `cmd.exe` and look for common follow-on tooling (for example: `powershell.exe`, `mshta.exe`, `rundll32.exe`, `regsvr32.exe`, `certutil.exe`, `bitsadmin.exe`, `curl.exe`, `wget.exe`).
+  - If file telemetry is available, review file creation/modification shortly after `@timestamp` and correlate any new binaries or scripts with hashes and execution events.
+
+- Scope the activity (blast radius):
+  - Search for the same `process.command_line` (or distinctive substrings), script name, or extracted URL across endpoints.
+  - Search for other `cmd.exe` instances connecting to the same `destination.ip` or the same destination port/protocol.
+  - If the parent is Office, scope for the same parent-child relationship (`process.parent.name` -> `cmd.exe`) across users and hosts.
+
+
+*False positive analysis*
+
+
+- Software deployment, packaging, or endpoint management workflows that use `cmd.exe /c` to run batch scripts and contact vendor services.
+- Signed installer or updater activity where `cmd.exe` is used as a helper process with stable command lines.
+- Documented Office macros/add-ins/templates that legitimately spawn `cmd.exe` with consistent command lines and destinations.
+
+A benign determination is more likely when the combination of `process.parent.name`, stable `process.command_line`, and consistent `destination.ip`/`destination.port` repeats across an expected set of hosts and users and aligns to a documented workflow owner.
+
+
+*Response and remediation*
+
+
+- If the activity is suspicious or cannot be attributed to an approved workflow:
+  - Contain the affected endpoint (`host.id`) using available endpoint or network controls.
+  - Preserve evidence (at minimum):
+    - `@timestamp`, `host.*`, `user.*`
+    - `process.entity_id`, `process.command_line`, `process.args`, `process.parent.*`
+    - `destination.ip`, `destination.port`, `network.*`
+    - Any related child processes and file artifacts (paths and hashes) identified during triage
+  - Scope for related activity by searching for additional occurrences of the same destination and command-line patterns.
+  - If Office is the launch vector, identify and quarantine the initiating document or email and assess whether similar content was delivered to other users.
+  - If a script is involved, collect and review the script contents and investigate how it was introduced (downloads, email attachments, shared drives, logon scripts, scheduled tasks).
+  - If account compromise is suspected, follow established identity response procedures (credential reset, session review, and access auditing).
+
+- If the activity is confirmed benign:
+  - Document the expected parent process, command-line pattern, and destinations.
+  - Consider adding a narrowly scoped exception using stable identifiers and constrained conditions (for example, specific `process.command_line` patterns and known destinations) to reduce recurring noise.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+sequence by process.entity_id with maxspan=15s
+  [process where host.os.type == "windows" and event.type == "start" and
+    process.name : "cmd.exe" and process.args : ("/c", "/k") and
+    (
+      process.args : ("*.bat", "*.cmd") or
+      process.command_line : ("*http://*", "*https://*", "*ftp://*") or
+      process.parent.name : ("excel.exe", "msaccess.exe", "mspub.exe", "powerpnt.exe", "winword.exe", "outlook.exe")
+    )
+  ]
+  [network where host.os.type == "windows" and process.name : "cmd.exe" and
+     not 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")]
+
+----------------------------------
+
+*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: 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/rule-details/suspicious-execution-from-a-mounted-device.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-execution-from-a-mounted-device.asciidoc
index a68b2310a4..1baad2d26c 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-execution-from-a-mounted-device.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-execution-from-a-mounted-device.asciidoc
@@ -37,7 +37,7 @@ Identifies when a script interpreter or signed binary is launched via a non-stan
 * Data Source: Sysmon
 * Resources: Investigation Guide
 
-*Version*: 211
+*Version*: 212
 
 *Rule authors*: 
 
@@ -95,30 +95,21 @@ In Windows environments, script interpreters and signed binaries are essential f
 - Monitor for any recurrence of similar activities by enhancing logging and alerting mechanisms, focusing on process execution from non-standard directories.
 - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
 
-==== Setup
-
-
-
-*Setup*
-
-
-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
-
-
 ==== Rule query
 
 
 [source, js]
 ----------------------------------
 process where host.os.type == "windows" and event.type == "start" and process.executable : "C:\\*" and
-  (process.working_directory : "?:\\" and not process.working_directory: "C:\\") and
+  (
+    process.working_directory : ("D:\\*", "E:\\*", "F:\\*") or
+    ?process.Ext.device.product_id : ("Virtual DVD-ROM", "Virtual Disk")
+  ) and
   process.parent.name : "explorer.exe" and
-  process.name : ("rundll32.exe", "mshta.exe", "powershell.exe", "pwsh.exe", "cmd.exe", "regsvr32.exe",
-                  "cscript.exe", "wscript.exe")
+  process.name : (
+    "rundll32.exe", "mshta.exe", "powershell.exe", "pwsh.exe", "cmd.exe", "regsvr32.exe", "cscript.exe",
+    "wscript.exe", "certutil.exe", "bitsadmin.exe", "msiexec.exe", "wmic.exe", "schtasks.exe", "msbuild.exe"
+  )
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-net-reflection-via-powershell.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-net-reflection-via-powershell.asciidoc
index 20f846b850..74f4a605c4 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-net-reflection-via-powershell.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-net-reflection-via-powershell.asciidoc
@@ -1,7 +1,7 @@
 [[suspicious-net-reflection-via-powershell]]
 === Suspicious .NET Reflection via PowerShell
 
-Detects the use of Reflection.Assembly to load PEs and DLLs in memory in PowerShell scripts. Attackers use this method to load executables and DLLs without writing to the disk, bypassing security solutions.
+Detects PowerShell scripts that invoke Reflection.Assembly or Assembly.Load to load .NET assemblies. Attackers use this method to load executables and DLLs without writing to the disk, bypassing security solutions.
 
 *Rule type*: query
 
@@ -34,7 +34,7 @@ Detects the use of Reflection.Assembly to load PEs and DLLs in memory in PowerSh
 * Resources: Investigation Guide
 * Data Source: PowerShell Logs
 
-*Version*: 320
+*Version*: 321
 
 *Rule authors*: 
 
@@ -50,72 +50,92 @@ Detects the use of Reflection.Assembly to load PEs and DLLs in memory in PowerSh
 *Triage and analysis*
 
 
-
-*Investigating Suspicious .NET Reflection via PowerShell*
+> **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.
 
 
-PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code.
+*Investigating Suspicious .NET Reflection via PowerShell*
 
-Attackers can use .NET reflection to load PEs and DLLs in memory. These payloads are commonly embedded in the script, which can circumvent file-based security protections.
 
-> **Note**:
-> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
+This alert indicates PowerShell script block content attempted to load a .NET assembly using reflection-based APIs (for example, `[System.Reflection.Assembly]::Load` or `Assembly.Load(...)`). While this can be used for legitimate extensibility, it is also commonly used to execute .NET payloads in memory and reduce file-based artifacts.
 
 
-*Possible investigation steps*
+*Key alert fields to review*
 
 
-- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
-- Investigate the script 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.
-- Examine file or network events from the involved PowerShell process for suspicious behavior.
-- Investigate other alerts associated with the user/host during the past 48 hours.
-- Evaluate whether the user needs to use PowerShell to complete tasks.
-- Examine the host for derived artifacts that indicate suspicious activities:
-  - Analyze the script 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.
+- `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.
 
 
-*False positive analysis*
+*Possible investigation steps*
 
 
-- This activity is unlikely to happen legitimately outside engineering or IT business units. As long as the analyst did not identify malware or suspicious activity related to the user or host, this alert can be dismissed.
+- Triage the execution context:
+  - Identify the affected host and user using `host.name`, `host.id`, `user.name`, `user.domain`, and `user.id`.
+  - Prioritize alerts where the user is unexpected for the host role, or where the same user appears across multiple hosts in a short time window.
+- Analyze the assembly load behavior in `powershell.file.script_block_text`:
+  - Identify what is being passed into the load call (assembly name vs. byte array or dynamically generated content).
+  - Check for indicators of staged content within the same script block, such as long encoded blobs, dynamic string construction, or multiple transformation steps (decoding, decompression, or concatenation) that produce the assembly bytes.
+  - Look for immediate follow-on actions suggesting the loaded assembly is executed (for example, accessing types/methods and invoking them after the load).
+- Reconstruct the full script block when needed:
+  - If the content appears partial, group related events by `powershell.file.script_block_id` and order by `powershell.sequence` to `powershell.total` to rebuild the full script block before assessing intent.
+  - Use `powershell.file.script_block_length` as a signal for embedded content (large or unusually variable sizes can indicate payload staging).
+- Determine script origin and persistence indicators:
+  - If `file.path`/`file.name` are present, assess whether the script is stored in an expected location for the user and host role, or in a user-writable / temporary directory indicated by `file.directory`.
+  - If `file.path` is present, retrieve and review the corresponding script file for additional context (embedded payloads, additional functions, or execution logic not visible in a single script block event).
+  - If `file.path` is not present, treat the activity as potentially interactive or remotely delivered and rely on `powershell.file.script_block_id` and time-based pivots to gather surrounding context.
+- Scope related PowerShell activity on the same host and user:
+  - Pivot on `host.id` and `user.id` to identify additional script blocks around the alert time that may show setup, staging, or follow-on actions.
+  - Check for repeated `Assembly.Load` usage across multiple `powershell.file.script_block_id` values, which may indicate iterative execution attempts or multiple payload stages.
+- Scope across the environment:
+  - Search for the same `file.path`/`file.name` and similar `powershell.file.script_block_text` patterns on other hosts to identify propagation or reuse.
+  - Identify whether the same `user.id` is associated with similar script blocks across multiple `host.id` values to assess potential lateral movement or shared automation.
+- Correlate with adjacent telemetry (if available in your environment):
+  - Process telemetry: Determine how PowerShell was launched and by what parent process around the alert time to understand delivery (interactive use, scheduled execution, service context, or another process).
+  - Network telemetry: Review outbound activity near the alert time for signs of payload retrieval, staging infrastructure, or command-and-control.
+  - File/registry telemetry: Look for newly created or modified scripts, DLLs, or persistence-related changes temporally aligned with the script block execution.
+  - Authentication telemetry: Review logon patterns for the same user and host around the alert time to identify unusual access patterns that could explain the execution.
+- If response actions are available:
+  - Collect host DNS cache and a snapshot of running/installed services to support scoping and to identify suspicious services or recent name resolution consistent with payload staging.
 
 
-*Related rules*
+*False positive analysis*
 
 
-- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe
-- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d
-- PowerShell Suspicious Payload Encoded and Compressed - 81fe9dc6-a2d7-4192-a2d8-eed98afc766a
+- Legitimate scripts may load assemblies to support internal tooling, plugin models, packaged dependencies, or automation tasks that embed .NET functionality in PowerShell.
+- Benign activity is more likely when:
+  - `file.path`/`file.name` map to a known, owned script with a stable operational purpose.
+  - The same `user.id` consistently runs the same script on the same `host.id` as part of normal operations.
+  - `powershell.file.script_block_text` is readable and clearly loads expected assemblies without embedded blobs or multi-step content staging.
+- Suspicious activity is more likely when:
+  - The assembly is loaded from dynamically generated bytes (encoded or transformed content) and is followed by reflection-based invocation.
+  - The script originates from an unusual `file.directory` or the execution context (`user.name`/`host.name`) is inconsistent with expected administrative workflows.
+- If confirmed benign, document the owning team, expected execution pattern, and the specific script identity (`file.path`/`file.name`) to enable narrowly scoped tuning.
 
 
 *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.
-- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
-- 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 the activity is confirmed or strongly suspected to be malicious:
+  - Isolate the affected host to prevent further in-memory execution and follow-on activity.
+  - Preserve evidence from the alert:
+    - Export the full reconstructed script block content using `powershell.file.script_block_id` with `powershell.sequence`/`powershell.total`.
+    - Capture `host.id`, `host.name`, `user.id`, `user.name`, `user.domain`, and any associated `file.path`/`file.name` context.
+  - Identify and contain related activity:
+    - Hunt for additional related script blocks on the same host/user and across other hosts for similar `powershell.file.script_block_text` patterns.
+    - Contain any identified infrastructure or artifacts based on indicators found in the script content (for example, domains, IPs, or downloaded file names).
+  - Remediate:
+    - Remove persistence and stop any related malicious processes discovered during triage and correlation.
+    - Review the impacted account (`user.id`) for compromise and rotate credentials as appropriate, prioritizing privileged access.
+    - Validate the host is remediated and monitored for recurrence before returning it to service.
+- If the activity is benign but requires reduction in alert volume:
+  - Record the approved use case and expected execution context (host role, user role, and script location).
+  - Apply targeted tuning anchored to stable identifiers (for example, specific `file.path` and expected accounts) rather than broadly suppressing assembly load behavior.
+  - Review PowerShell governance and monitoring to ensure in-memory loading is limited to approved workflows.
 
 
 ==== Setup
@@ -125,21 +145,8 @@ Attackers can use .NET reflection to load PEs and DLLs in memory. These payloads
 *Setup*
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
-
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
-
-Steps to implement the logging policy via registry:
-
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
@@ -148,26 +155,17 @@ reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
 [source, js]
 ----------------------------------
 event.category:process and host.os.type:windows and
+(
   powershell.file.script_block_text : (
     "[System.Reflection.Assembly]::Load" or
     "[Reflection.Assembly]::Load" or
     "Assembly.Load("
   ) and
-  not powershell.file.script_block_text : (
-        ("CommonWorkflowParameters" or "RelatedLinksHelpInfo") and
-        "HelpDisplayStrings"
-  ) and
-  not (powershell.file.script_block_text :
-        ("Get-SolutionFiles" or "Get-VisualStudio" or "Select-MSBuildPath") and
-        file.name : "PathFunctions.ps1"
-  ) and
-  not powershell.file.script_block_text : (
-        "Microsoft.PowerShell.Workflow.ServiceCore" and "ExtractPluginProperties([string]$pluginDir"
-  ) and 
-  
-  not powershell.file.script_block_text : ("reflection.assembly]::Load('System." or "LoadWithPartialName('Microsoft." or "::Load(\"Microsoft." or "Microsoft.Build.Utilities.Core.dll") and 
-  
-  not user.id : "S-1-5-18"
+  powershell.file.script_block_text : (
+      "FromBase64String" or "GzipStream" or "DeflateStream" or "IO.Compression" or
+      "MemoryStream" or "DownloadData" or "WebClient" or "ReadAllBytes"
+  )
+)
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-portable-executable-encoded-in-powershell-script.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-portable-executable-encoded-in-powershell-script.asciidoc
index 8677eb6975..2932f58ec7 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-portable-executable-encoded-in-powershell-script.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-portable-executable-encoded-in-powershell-script.asciidoc
@@ -1,7 +1,7 @@
 [[suspicious-portable-executable-encoded-in-powershell-script]]
 === Suspicious Portable Executable Encoded in Powershell Script
 
-Detects the presence of a portable executable (PE) in a PowerShell script by looking for its encoded header. Attackers embed PEs into PowerShell scripts to inject them into memory, avoiding defences by not writing to disk.
+Detects PowerShell scripts that includes a base64-encoded portable executable (PE) header, indicating an embedded binary payload. Attackers embed PEs in scripts to load payloads in memory and avoid writing executables to disk.
 
 *Rule type*: query
 
@@ -34,7 +34,7 @@ Detects the presence of a portable executable (PE) in a PowerShell script by loo
 * Resources: Investigation Guide
 * Data Source: PowerShell Logs
 
-*Version*: 215
+*Version*: 216
 
 *Rule authors*: 
 
@@ -50,71 +50,83 @@ Detects the presence of a portable executable (PE) in a PowerShell script by loo
 *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 Suspicious Portable Executable Encoded in Powershell Script*
 
+*Investigating Suspicious Portable Executable Encoded in Powershell Script*
 
-PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code.
 
-Attackers can abuse PowerShell in-memory capabilities to inject executables into memory without touching the disk, bypassing file-based security protections. These executables are generally base64 encoded.
+This alert indicates PowerShell Script Block Logging captured script content that contains a base64-encoded Portable Executable (PE) header pattern, suggesting an embedded Windows binary payload. This technique is commonly used to stage executables for in-memory loading or later execution while minimizing on-disk artifacts.
 
-> **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.
 
+*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.
 
-- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
-- Investigate the script 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.
-- Evaluate whether the user needs to use PowerShell to complete tasks.
-- Examine the host for derived artifacts that indicate suspicious activities:
-  - Analyze the script 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*
+*Possible investigation steps*
 
 
-- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
+- Capture and reconstruct the full script content:
+  - Review `powershell.file.script_block_text` in full to identify the encoded blob boundaries and any surrounding helper logic (string concatenation, chunking, decryption, decompression, or obfuscation).
+  - If `powershell.file.script_block_id` is present, collect all related events for that ID and use `powershell.sequence` and `powershell.total` to reconstruct the complete script when content is split across multiple records.
+  - Confirm reconstruction completeness by ensuring the sequence range is consistent with `powershell.total` and that the combined content is coherent.
+  - Use `powershell.file.script_block_length` to help prioritize unusually large script blocks that are more likely to contain full payloads or staged components.
+- Determine the script origin and execution context:
+  - Use `user.name`, `user.domain`, and `user.id` to identify the initiating account and whether this activity is expected for that user (approved automation vs. unusual interactive activity).
+  - Use `host.name` and `host.id` to identify the affected asset, its owner/role, and whether PowerShell automation is typical for this host.
+  - If `file.path`, `file.directory`, or `file.name` are present, treat the alert as file-sourced script execution:
+    - Validate whether the path and name align with approved administrative tooling and distribution locations.
+    - Prioritize investigation when scripts are sourced from user-writable locations, temporary directories, or uncommon paths for your environment.
+- Identify likely payload handling behavior within the script:
+  - Look for logic that transforms the encoded content into executable bytes and how it is consumed (written to disk, loaded as an assembly, reflectively invoked, or mapped into memory).
+  - Note any secondary behaviors in the same script block that increase risk, such as staged downloads, persistence-related actions, or attempts to reduce visibility.
+  - Identify whether the script constructs multiple encoded blobs, and document which blob is ultimately used for execution.
+- Scope the activity using alert pivots:
+  - Search for additional script block events for the same `host.id` and `user.id` around `@timestamp` to identify lead-up actions and follow-on behavior.
+  - Search across hosts for the same `powershell.file.script_block_text` patterns (the encoded header and any unique strings nearby) to identify other potentially affected systems.
+  - If a script file is indicated by `file.path`/`file.name`, search for the same path/name across your environment to determine distribution and reuse.
+- Correlate with adjacent telemetry (if available):
+  - Pivot on `host.id`/`host.name` and `@timestamp` into process telemetry to identify the PowerShell session and any processes that appear shortly after the script ran, which may indicate payload execution outcomes.
+  - Pivot on `host.id`/`host.name` and `@timestamp` into network telemetry to identify outbound connections that could indicate payload retrieval or command-and-control activity shortly before or after script execution.
+  - Review authentication activity for the same `user.id` around the alert time to identify unusual logons (unexpected host, timing, or access pattern) that could explain how the execution context was obtained.
+- Analyze the embedded payload in an isolated workflow (when permitted):
+  - Decode the base64 content and validate whether it forms a legitimate PE.
+  - Derive stable indicators (hashes, unique strings, and high-level metadata) and use them to widen the scope across endpoints and historical telemetry.
+  - Preserve decoded artifacts and analysis notes according to your incident handling and evidence retention procedures.
 
 
-*Related rules*
+*False positive analysis*
 
 
-- Suspicious .NET Reflection via PowerShell - e26f042e-c590-4e82-8e05-41e81bd822ad
-- PowerShell Suspicious Payload Encoded and Compressed - 81fe9dc6-a2d7-4192-a2d8-eed98afc766a
-- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe
+- Approved administrative or deployment automation that embeds executables in PowerShell scripts for distribution in tightly controlled environments.
+- Vendor-provided installers, updaters, or management tooling that stages binaries through PowerShell as part of legitimate maintenance activity.
+- Authorized security testing or adversary emulation that intentionally uses embedded payloads or in-memory loading techniques.
+- False positives are more likely when `file.path` points to known software distribution locations and the executing `user.id` is an approved automation account; validate against change records and expected tooling.
 
 
 *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.
-- Reimage the host operating system or restore the compromised files to clean versions.
-- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
-- 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 the activity is unexpected or malicious:
+  - Contain the affected host(s) based on criticality to prevent further execution or lateral movement.
+  - Preserve evidence by saving the full reconstructed script content (using `powershell.file.script_block_id` plus all fragments, if split) and recording the associated `@timestamp`, `host.id`, `host.name`, and `user.id` for timeline reconstruction.
+- Assess scope and impact:
+  - Hunt for the same script patterns across other hosts and users, and expand scoping using any indicators derived from payload analysis.
+  - Review the initiating account for signs of compromise; apply credential hygiene actions per policy (reset credentials, revoke sessions, and review access).
+- Eradicate and recover:
+  - Remove or remediate the script source indicated by `file.path` (if present) and any persistence mechanisms identified during triage (for example, suspicious or newly introduced services).
+  - If a PE payload is confirmed, follow malware incident procedures to determine whether host reimaging or deeper forensic review is required.
+- Post-incident improvements:
+  - Review PowerShell governance for the affected population (script approval processes, least privilege, and monitoring of script block content) to reduce recurrence.
+  - Document validated benign patterns and trusted automation paths to streamline future triage and reduce alert fatigue.
 
 
 ==== Setup
@@ -124,21 +136,8 @@ Attackers can abuse PowerShell in-memory capabilities to inject executables into
 *Setup*
 
 
-The 'PowerShell Script Block Logging' logging policy must be enabled.
-Steps to implement the logging policy with Advanced Audit Configuration:
-
-```
-Computer Configuration >
-Administrative Templates >
-Windows PowerShell >
-Turn on PowerShell Script Block Logging (Enable)
-```
-
-Steps to implement the logging policy via registry:
-
-```
-reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
-```
+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
diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-windows-powershell-arguments.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-windows-powershell-arguments.asciidoc
index 1ab86e2f4b..e056abf4dc 100644
--- a/docs/detections/prebuilt-rules/rule-details/suspicious-windows-powershell-arguments.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/suspicious-windows-powershell-arguments.asciidoc
@@ -44,7 +44,7 @@ Identifies the execution of PowerShell with suspicious argument values. This beh
 * Data Source: Elastic Endgame
 * Resources: Investigation Guide
 
-*Version*: 210
+*Version*: 211
 
 *Rule authors*: 
 
@@ -116,6 +116,11 @@ process where host.os.type == "windows" and event.type == "start" and
     not event.dataset : ("windows.sysmon_operational", "windows.sysmon")
   ) and
 
+  not process.parent.executable : (
+        "?:\\Program Files\\*.exe",
+        "?:\\Program Files (x86)\\*.exe"
+  ) and
+
   (
     process.command_line : (
           "*^*^*^*^*^*^*^*^*^*",
@@ -197,6 +202,10 @@ process where host.os.type == "windows" and event.type == "start" and
     (
       process.parent.name : ("explorer.exe", "cmd.exe") and
       process.command_line : ("*-encodedCommand*", "*Invoke-webrequest*", "*WebClient*", "*Reflection.Assembly*"))
+    ) and
+    not process.command_line : (
+      "*Use-Icinga -Minimal*",
+      "*& {$j = sajb {Add-Type -AssemblyName*"
     )
 
 ----------------------------------
diff --git a/docs/detections/prebuilt-rules/rule-details/system-information-discovery-via-dmidecode-from-parent-shell.asciidoc b/docs/detections/prebuilt-rules/rule-details/system-information-discovery-via-dmidecode-from-parent-shell.asciidoc
index dbbd10c92a..062b21624a 100644
--- a/docs/detections/prebuilt-rules/rule-details/system-information-discovery-via-dmidecode-from-parent-shell.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/system-information-discovery-via-dmidecode-from-parent-shell.asciidoc
@@ -36,7 +36,7 @@ This rule detects the use of dmidecode to gather system information from a Linux
 * Data Source: SentinelOne
 * Resources: Investigation Guide
 
-*Version*: 1
+*Version*: 2
 
 *Rule authors*: 
 
@@ -148,7 +148,16 @@ Auditbeat is a lightweight shipper that you can install on your servers to audit
 ----------------------------------
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and
 process.name == "dmidecode" and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
-process.parent.args == "-c"
+process.parent.args == "-c" and not (
+  process.parent.command_line in (
+    "/bin/sh -c /usr/sbin/dmidecode | /bin/grep VMware", "sh -c dmidecode -s system-manufacturer"
+  ) or
+  ?process.working_directory in (
+    "/data/oem_agent/agent_inst/sysman/emd", "/opt/rapid7/ir_agent/components/insight_agent/common", "/opt/veeam/transport",
+    "/data/app/oracle/agent/agent_inst/sysman/emd", "/home/nessus", "/opt/commvault", "/opt/nessus_agent/var/nessus/mod/com.tenable.nessus_agent/data"
+  ) or
+  process.parent.args like "printf*"
+)
 
 ----------------------------------
 
diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-directory.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-directory.asciidoc
index ec3bbc3a40..cda59793f6 100644
--- a/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-directory.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-directory.asciidoc
@@ -32,7 +32,7 @@ An anomaly detection job has detected a remote file transfer on an unusual direc
 * Tactic: Lateral Movement
 * Resources: Investigation Guide
 
-*Version*: 7
+*Version*: 8
 
 *Rule authors*: 
 
@@ -97,6 +97,12 @@ The 'Unusual Remote File Directory' detection leverages machine learning to iden
 *Setup*
 
 
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
 The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-extension.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-extension.asciidoc
index 01a643f173..d4f7b5f910 100644
--- a/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-extension.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-extension.asciidoc
@@ -32,7 +32,7 @@ An anomaly detection job has detected a remote file transfer with a rare extensi
 * Tactic: Lateral Movement
 * Resources: Investigation Guide
 
-*Version*: 7
+*Version*: 8
 
 *Rule authors*: 
 
@@ -97,6 +97,12 @@ The detection of unusual remote file extensions leverages machine learning to id
 *Setup*
 
 
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
 The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-size.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-size.asciidoc
index a6084b1277..389a909e31 100644
--- a/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-size.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-size.asciidoc
@@ -32,7 +32,7 @@ A machine learning job has detected an unusually high file size shared by a remo
 * Tactic: Lateral Movement
 * Resources: Investigation Guide
 
-*Version*: 7
+*Version*: 8
 
 *Rule authors*: 
 
@@ -96,6 +96,12 @@ Machine learning models in security environments analyze file transfer patterns
 *Setup*
 
 
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
 The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 
diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-time-or-day-for-an-rdp-session.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-time-or-day-for-an-rdp-session.asciidoc
index 143c4631ab..d621869fc4 100644
--- a/docs/detections/prebuilt-rules/rule-details/unusual-time-or-day-for-an-rdp-session.asciidoc
+++ b/docs/detections/prebuilt-rules/rule-details/unusual-time-or-day-for-an-rdp-session.asciidoc
@@ -32,7 +32,7 @@ A machine learning job has detected an RDP session started at an usual time or w
 * Tactic: Lateral Movement
 * Resources: Investigation Guide
 
-*Version*: 7
+*Version*: 8
 
 *Rule authors*: 
 
@@ -97,6 +97,12 @@ Remote Desktop Protocol (RDP) enables remote access to systems, crucial for IT m
 *Setup*
 
 
+This rule requires the `host.ip` field to be populated.
+For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
+
+If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
+https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide].
+
 The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 
diff --git a/docs/index.asciidoc b/docs/index.asciidoc
index 0eec94849b..ee24a389a8 100644
--- a/docs/index.asciidoc
+++ b/docs/index.asciidoc
@@ -113,3 +113,5 @@ include::detections/prebuilt-rules/downloadable-packages/8-19-13/prebuilt-rules-
 include::detections/prebuilt-rules/downloadable-packages/8-19-14/prebuilt-rules-8-19-14-appendix.asciidoc[]
 
 include::detections/prebuilt-rules/downloadable-packages/8-19-15/prebuilt-rules-8-19-15-appendix.asciidoc[]
+
+include::detections/prebuilt-rules/downloadable-packages/8-19-16/prebuilt-rules-8-19-16-appendix.asciidoc[]